Re: i386 version for chrome
Hi.
On Sun, Oct 28, 2018 at 12:56:13PM -0400, The Wanderer wrote:
> On 2018-10-28 at 12:23, Reco wrote:
>
> > Hi.
> >
> > On Sun, Oct 28, 2018 at 12:04:54PM -0400, Gene Heskett wrote:
>
> [that in a previous message, Reco wrote:]
>
> >>> interfaces(5), the usual place.
> >>
> >> I just checked that man page on wheezy, jessie and stretch, and no
> >> examples are found using "netmask 24"
> >
> > You asked for 'format', not 'example'.
> > The 'format' is defined at netmask under INET ADDRESS FAMILY.
>
> In interfaces(5), you mean?
Sure. It's the context of this part of the discussion.
> The definition for netmask I find in that section is
> netmask mask
> Netmask (dotted quad or CIDR)
>
> which at a glance would lead me to expect a full CIDR-format address
> (e.g., 192.168.1.1/24) here. That would clearly seem redundant with the
> address field immediately above, but I don't know of anything else
> that's consistent with CIDR notation.
I agree that this part of the manpage is in dire need of good wording.
I'd replace it with "Netmask (dotted quad or number of bits, eg 24)",
because that's how it actually works.
> I'm not saying that using just the bit count in that field doesn't work;
> I haven't tested it, and I have no particular reason to doubt your
> testimony on the subject. But I don't see anything in the documentation
> which would lead me to expect it to work.
>
> Is there something I'm missing which should lead me to that expectation?
No, you're correct. This part of a manpage is a subject to
interpretation, someone may even call it 'obscure'.
> >>>>> ifdown eth0 ifup -v eth0
> >>
> >> Will have to be done from its own keyboard unless a ; to separate
> >> them.
> >
> > Gene, if I needed a *normal* result of this sequence I'd asked for
> > one. What I've asked was a *broken* one, which does not get a default
> > route as a result.
>
> If I'm understanding what I've read in this thread to date correctly,
> he's said that the problem *only* happens at boot time, not when he
> issues commands manually.
I had and I have a different impression that the problem is a persistent
one. But I may be wrong.
> If correct, that would be a reason why he wanted to know how to make the
> boot-time invocations go into the system log, so that he can review what
> they report in appropriate detail (and/or share it, for others to
> review). It would also be a reason for making the boot-time invocations
> fully verbose, at least temporarily.
If that's true, then there's no need for such drastic measures. Good old
bootlogd should cover it.
Reco
Reply to: