Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #201736 > unrolled thread
| Started by | Pierre Frenkiel <pierre.frenkiel@gmail.com> |
|---|---|
| First post | 2018-10-27 10:30 +0200 |
| Last post | 2018-10-27 14:50 +0200 |
| Articles | 20 on this page of 73 — 17 participants |
Back to article view | Back to linux.debian.user
i386 version for chrome Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-27 10:30 +0200
Re: i386 version for chrome Andrew Wood <andrewjameswood@ymail.com> - 2018-10-27 10:40 +0200
Re: i386 version for chrome Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-27 12:40 +0200
Re: i386 version for chrome Roberto C. Sánchez <roberto@debian.org> - 2018-10-27 13:10 +0200
Re: i386 version for chrome Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-27 13:30 +0200
Re: i386 version for chrome Curt <curty@free.fr> - 2018-10-27 14:10 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-27 15:10 +0200
Re: i386 version for chrome Curt <curty@free.fr> - 2018-10-27 16:10 +0200
Re: i386 version for chrome Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-27 17:00 +0200
Re: i386 version for chrome Curt <curty@free.fr> - 2018-10-27 18:00 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-27 17:00 +0200
Re: i386 version for chrome Steve McIntyre <steve@einval.com> - 2018-10-27 17:20 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-27 19:20 +0200
Re: i386 version for chrome Steve McIntyre <steve@einval.com> - 2018-10-27 20:30 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-27 23:30 +0200
Re: i386 version for chrome Brian <ad44@cityscape.co.uk> - 2018-10-28 00:50 +0200
Re: i386 version for chrome David <bouncingcats@gmail.com> - 2018-10-28 00:30 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 01:00 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 01:00 +0200
Re: i386 version for chrome David <bouncingcats@gmail.com> - 2018-10-28 23:00 +0100
Re: i386 version for chrome Curt <curty@free.fr> - 2018-10-28 10:10 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 12:00 +0100
Re: i386 version for chrome Curt <curty@free.fr> - 2018-10-29 12:00 +0100
resolv.conf (was i386 version for chrome) Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-28 13:00 +0100
Re: resolv.conf (was i386 version for chrome) Reco <recoverym4n@enotuniq.net> - 2018-10-28 13:50 +0100
Re: resolv.conf (was i386 version for chrome) Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-28 14:20 +0100
Re: resolv.conf (was i386 version for chrome) Reco <recoverym4n@enotuniq.net> - 2018-10-28 14:20 +0100
Re: resolv.conf (was i386 version for chrome) Reco <recoverym4n@enotuniq.net> - 2018-10-28 14:50 +0100
Re: resolv.conf (was i386 version for chrome) Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-28 16:40 +0100
Re: i386 version for chrome Steve McIntyre <steve@einval.com> - 2018-10-28 01:00 +0200
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-28 16:00 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 17:20 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 11:30 +0100
Re: i386 version for chrome Reco <recoverym4n@enotuniq.net> - 2018-10-27 20:40 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-27 23:40 +0200
Re: i386 version for chrome Reco <recoverym4n@enotuniq.net> - 2018-10-28 08:00 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 11:10 +0100
Re: i386 version for chrome Reco <recoverym4n@enotuniq.net> - 2018-10-28 11:40 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 12:10 +0100
Re: i386 version for chrome Reco <recoverym4n@enotuniq.net> - 2018-10-28 13:50 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 17:10 +0100
Re: i386 version for chrome Reco <recoverym4n@enotuniq.net> - 2018-10-28 17:30 +0100
Re: i386 version for chrome The Wanderer <wanderer@fastmail.fm> - 2018-10-28 18:00 +0100
Re: i386 version for chrome john doe <johndoe65534@mail.com> - 2018-10-28 18:10 +0100
Re: i386 version for chrome Reco <recoverym4n@enotuniq.net> - 2018-10-28 18:20 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 12:20 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-29 13:30 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 13:40 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 14:00 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-29 15:50 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-29 15:50 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 16:10 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 21:20 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-29 21:20 +0100
Re: i386 version for chrome John Hasler <jhasler@newsguy.com> - 2018-10-29 21:30 +0100
Re: i386 version for chrome Brian <ad44@cityscape.co.uk> - 2018-10-29 21:40 +0100
Re: i386 version for chrome Brian <ad44@cityscape.co.uk> - 2018-10-29 21:50 +0100
Re: i386 version for chrome Brian <ad44@cityscape.co.uk> - 2018-10-28 20:00 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 20:10 +0100
Re: i386 version for chrome Brian <ad44@cityscape.co.uk> - 2018-10-28 20:30 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-29 00:40 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-29 12:20 +0100
Re: i386 version for chrome Thomas D Dial <tdial@acm.org> - 2018-10-28 04:10 +0100
Re: i386 version for chrome Michael Stone <mstone@debian.org> - 2018-10-28 15:50 +0100
Re: i386 version for chrome Matthew Crews <mailinglists@mattcrews.com> - 2018-10-27 17:10 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-27 17:40 +0200
Re: i386 version for chrome Matthew Crews <mailinglists@mattcrews.com> - 2018-10-27 22:00 +0200
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-10-28 00:10 +0200
Re: i386 version for chrome David Wright <deblis@lionunicorn.co.uk> - 2018-11-03 04:10 +0100
Re: i386 version for chrome Gene Heskett <gheskett@shentel.net> - 2018-11-03 04:40 +0100
Re: i386 version for chrome tony <lists@vanderhoff.org> - 2018-10-27 15:10 +0200
Re: i386 version for chrome Matthew Crews <mailinglists@mattcrews.com> - 2018-10-27 13:50 +0200
Re: i386 version for chrome Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2018-10-27 14:50 +0200
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-10-28 17:10 +0100 |
| Message-ID | <wNVNw-7WV-23@gated-at.bofh.it> |
| In reply to | #201789 |
On Sunday 28 October 2018 08:43:33 Reco wrote: > Hi. > > On Sun, Oct 28, 2018 at 07:04:02AM -0400, Gene Heskett wrote: > > > Ever consider you're doing it the wrong way? > > > This will work: > > > > > > iface eth0 inet static > > > address 192.168.NN.12 > > > netmask 24 > > > gateway 192.168.NN.1 > > > > in 20 years, I have never seen that syntax used. What man page do I > > find that format in. > > interfaces(5), the usual place. I just checked that man page on wheezy, jessie and stretch, and no examples are found using "netmask 24" address 192.168.##.##/24 is supposed to be understood as netmask 255.255.255.0, and has worked here forever. And remains in the man 5 interfaces page. And has Just Worked, until now with stretch. > > > -vvv is not documented, and I'm too lazy to dig into the source to > > > see if it does something at all. Normally used to expand the verbosity. Not all of these utility's understand multiples means noisier. And it does not cause the called functions to inherit the -v, so you get no feedback from them. IMO thats wrong, and the -vv SHOULD cause the listed subcalls to get a -v invocation. But I'm not steering this ship called Linux, so my voice is carried away by the wind. Also, I haven't ever seen an official definition of "CIDR", so its possible I need tutoring on that. IMO any man page that uses an acronym, needs to include its definition. > > > ifdown eth0 > > > ifup -v eth0 Will have to be done from its own keyboard unless a ; to separate them. That gets me: =========== root@rock64:~# ifdown eth0;ifup -v eth0 ifup: parsing file /etc/network/interfaces.d/eth0 ifup: configuring interface eth0=eth0 (inet) /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge run-parts: executing /etc/network/if-pre-up.d/ethtool run-parts: executing /etc/network/if-pre-up.d/hostapd run-parts: executing /etc/network/if-pre-up.d/ifenslave + [ inet = meta ] + IF_BOND_SLAVES= + [ ] + [ ] + [ -z ] + exit run-parts: executing /etc/network/if-pre-up.d/vlan run-parts: executing /etc/network/if-pre-up.d/wireless-tools run-parts: executing /etc/network/if-pre-up.d/wpasupplicant /bin/ip addr add 192.168.##.2/255.255.255.0 broadcast 192.168.##.255 dev eth0 label eth0 /bin/ip link set dev eth0 up /bin/ip route add default via 192.168.##.1 dev eth0 onlink /bin/run-parts --exit-on-error --verbose /etc/network/if-up.d run-parts: executing /etc/network/if-up.d/000resolvconf run-parts: executing /etc/network/if-up.d/avahi-autoipd run-parts: executing /etc/network/if-up.d/avahi-daemon run-parts: executing /etc/network/if-up.d/ethtool run-parts: executing /etc/network/if-up.d/ifenslave + [ inet = meta ] + [ ] run-parts: executing /etc/network/if-up.d/ip run-parts: executing /etc/network/if-up.d/openssh-server run-parts: executing /etc/network/if-up.d/openvpn run-parts: executing /etc/network/if-up.d/upstart run-parts: executing /etc/network/if-up.d/wpasupplicant ======== and it all works again, with: route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.##.1 0.0.0.0 UG 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 192.168.##.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 Thats from stretch on arm64/rock64. While booting to the armbian image only, debian-arm fails to set a gateway, and so does raspian. I half expected it not to boot raspian since the architecture was so different from the raspi 3b. > > > > What log file, on stretch, would I find that trace data in? > > > > > > Stdout/stderr, as documented by ifup(8). > > > > Too volatile, scrolled off screen by the remainder of the boot. I > > want a log file I can insert into an email. Then we'll all see whats > > happening. > > Er, Gene, -v is there for user invocations, not for init scripts. > /etc/init.d/networking uses ordinary ifup, as nobody will want seeing > all those gory implementation details at each boot. And they do seem to be gory, almost looks as if its looping, but not quite. > > > > Theres not anything in /v/l/syslog w/o the -v. > > > > > > And there should not be anything about ifupdown, unless someone > > > redirects stdout/stderr of /etc/init.d/networking to syslog. > > > > Howto? > > Don't. Simply don't. It requires wrapping with '| logger' every > ifup/ifdown at /etc/init.d/networking. > > Reco Maybe its time we let this thread die, it is working now, as I have other hardware problems to deal with ATM. With shipping delays delays from the Chinglish writers, till around thanksgiving here in the yuuh ess aye. Needless to say I've ordered spares. Thanks Reco. -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2018-10-28 17:30 +0100 |
| Message-ID | <wNW6R-83u-15@gated-at.bofh.it> |
| In reply to | #201802 |
Hi. On Sun, Oct 28, 2018 at 12:04:54PM -0400, Gene Heskett wrote: > > On Sun, Oct 28, 2018 at 07:04:02AM -0400, Gene Heskett wrote: > > > > Ever consider you're doing it the wrong way? > > > > This will work: > > > > > > > > iface eth0 inet static > > > > address 192.168.NN.12 > > > > netmask 24 > > > > gateway 192.168.NN.1 > > > > > > in 20 years, I have never seen that syntax used. What man page do I > > > find that format in. > > > > 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. > address 192.168.##.##/24 is supposed to be understood as netmask > 255.255.255.0, and has worked here forever. And remains in the man 5 > interfaces page. True. > And has Just Worked, until now with stretch. And it does now. > Also, I haven't ever seen an official definition of "CIDR", so its > possible I need tutoring on that. IMO any man page that uses an acronym, > needs to include its definition. RFC 4632. As official as it gets. > > > > 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. So, either it did not happen, or ...? Reco
[toc] | [prev] | [next] | [standalone]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2018-10-28 18:00 +0100 |
| Message-ID | <wNWzT-8cS-3@gated-at.bofh.it> |
| In reply to | #201804 |
[Multipart message — attachments visible in raw view] — view raw
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?
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'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?
>>>>> 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.
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.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
[toc] | [prev] | [next] | [standalone]
| From | john doe <johndoe65534@mail.com> |
|---|---|
| Date | 2018-10-28 18:10 +0100 |
| Message-ID | <wNWJA-8vh-9@gated-at.bofh.it> |
| In reply to | #201807 |
On 10/28/2018 5:56 PM, 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? > > 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 TL-DR. Don't you mean '192.168.1.0/24'? -- John Doe
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2018-10-28 18:20 +0100 |
| Message-ID | <wNWTg-6H-3@gated-at.bofh.it> |
| In reply to | #201807 |
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
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2018-10-29 12:20 +0100 |
| Message-ID | <wOdKp-1EB-1@gated-at.bofh.it> |
| In reply to | #201809 |
On Sun, Oct 28, 2018 at 08:18:44PM +0300, Reco wrote: >On Sun, Oct 28, 2018 at 12:56:13PM -0400, The Wanderer wrote: >> 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. Mostly the netmask field should be considered a legacy interface. Historically, the address was only the address, and the netmask was the dotted-quad formatted netmask for that address. When ifupdown gained the ability to specify the address field in address/bits format (in wheezy), the netmask field was extended to also recognize cidr bits in addition to dotted quad. (This also provides symmetry with the ipv6 representation, where dotted quad doesn't make sense.) With the new address syntax the netmask field is fully redundant, but remains for upgrades and compatibility with old scripts/etc.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-10-29 13:30 +0100 |
| Message-ID | <wOeQ9-2fM-1@gated-at.bofh.it> |
| In reply to | #201836 |
On Monday 29 October 2018 07:18:44 Michael Stone wrote: > On Sun, Oct 28, 2018 at 08:18:44PM +0300, Reco wrote: > >On Sun, Oct 28, 2018 at 12:56:13PM -0400, The Wanderer wrote: > >> 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. Absolutely. Where I may have gone aglay is in assumeing the slash was part of it, perhaps as a switch to tell that 24 valid bits were assumed. And amazingly to me, I read that RFC, and did not encounter the "netmask 24" syntax anyplace in it. In any event I think all my machines use the dotted quad representations. Because of network managers love for tearing down a working network, and leaving the scene w/o building a new working linkage, I have always: composed my own eth0 stanza's in /e/n/i made them immutable so nm is powerless to tear it down composed my own resolv.conf as a real file this machine for instance: nameserver 192.168.##.1 search coyote.den nameserver and made it immutable so nm can't attempt to change it. With a hosts file based local net, I need no local dns setups at all. > Mostly the netmask field should be considered a legacy interface. > Historically, the address was only the address, and the netmask was > the dotted-quad formatted netmask for that address. When ifupdown > gained the ability to specify the address field in address/bits format > (in wheezy), the netmask field was extended to also recognize cidr > bits in addition to dotted quad. (This also provides symmetry with > the ipv6 > representation, where dotted quad doesn't make sense.) With the new > address syntax the netmask field is fully redundant, but remains for > upgrades and compatibility with old scripts/etc. And you insist it can't work, and it has been here for years. All the immutable bits were required because years ago, nm was so intertwined with everything that it could only be removed with a root session of rm. More recently it can be removed w/o destroying the OS. I'd offer thanks and a cold one to whomever fixed it so it could be removed. What you need to learn, instead of insisting it can't work, is that theres more than one way to skin a cat. My recommendation is that the first step is to make sure its dead. -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2018-10-29 13:40 +0100 |
| Message-ID | <wOeZP-2iL-5@gated-at.bofh.it> |
| In reply to | #201837 |
On Mon, Oct 29, 2018 at 08:19:54AM -0400, Gene Heskett wrote: >And amazingly to me, I read that RFC, and did not encounter the >"netmask 24" syntax anyplace in it. In any event I think all my machines >use the dotted quad representations. It should be unsurprising that an internet RFC fails to include debian-specific configuration syntax. >Because of network managers love for tearing down a working network, and >leaving the scene w/o building a new working linkage, I have always: >composed my own eth0 stanza's in /e/n/i >made them immutable so nm is powerless to tear it down network manager doesn't do that, but if making it immutable makes you happy, carry on. For others reading this: it's another example of strange things gene does on his machine that you're best off not copying. If you really hate network manager, just remove it. If you don't, it will simply ignore interfaces which have entries in /etc/network/interfaces.
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2018-10-29 14:00 +0100 |
| Message-ID | <wOfjc-2pm-11@gated-at.bofh.it> |
| In reply to | #201809 |
On Sun, Oct 28, 2018 at 08:18:44PM +0300, Reco wrote: >On Sun, Oct 28, 2018 at 12:56:13PM -0400, The Wanderer wrote: >> 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 opened https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912220 to clarify this section. If anyone has other suggestions, please add them to the bug. Mike Stone
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-10-29 15:50 +0100 |
| Message-ID | <wOh1E-3so-5@gated-at.bofh.it> |
| In reply to | #201839 |
On Monday 29 October 2018 08:53:35 Michael Stone wrote: > On Sun, Oct 28, 2018 at 08:18:44PM +0300, Reco wrote: > >On Sun, Oct 28, 2018 at 12:56:13PM -0400, The Wanderer wrote: > >> 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 opened https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912220 to > clarify this section. If anyone has other suggestions, please add them > to the bug. > > Mike Stone Is it a separate bug to fuss about the near total lack of meaning to the man pages for ip and its children. -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-10-29 15:50 +0100 |
| Message-ID | <wOh1E-3so-3@gated-at.bofh.it> |
| In reply to | #201841 |
On Monday 29 October 2018 10:45:50 Gene Heskett wrote: > On Monday 29 October 2018 08:53:35 Michael Stone wrote: > > On Sun, Oct 28, 2018 at 08:18:44PM +0300, Reco wrote: > > >On Sun, Oct 28, 2018 at 12:56:13PM -0400, The Wanderer wrote: > > >> 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 opened https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912220 to > > clarify this section. If anyone has other suggestions, please add > > them to the bug. > > > > Mike Stone > > Is it a separate bug to fuss about the near total lack of meaning to > the man pages for ip and its children? added question mark -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2018-10-29 16:10 +0100 |
| Message-ID | <wOhl0-3O7-15@gated-at.bofh.it> |
| In reply to | #201841 |
On Mon, Oct 29, 2018 at 10:45:50AM -0400, Gene Heskett wrote: >Is it a separate bug to fuss about the near total lack of meaning to the >man pages for ip and its children. Assuming you have no substantive suggestions, it's not a bug report at all, it's just complaining.
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2018-10-29 21:20 +0100 |
| Message-ID | <wOmb0-6Fm-7@gated-at.bofh.it> |
| In reply to | #201843 |
On Mon, Oct 29, 2018 at 04:11:01PM -0400, Gene Heskett wrote: >Hmmf. If I could make an educated suggestion, but I've not got a clue as >to how it is supposed to work, those pages aren't a how-to, so I'd be >pinning the tail on the donkey just as if I was blindfolded. But this >isn't a party. > >If printed on Northern's TP stock, then they might be good for something. So you're basically just wasting our time. Got it.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-10-29 21:20 +0100 |
| Message-ID | <wOmb0-6Fm-9@gated-at.bofh.it> |
| In reply to | #201843 |
On Monday 29 October 2018 11:05:32 Michael Stone wrote: > On Mon, Oct 29, 2018 at 10:45:50AM -0400, Gene Heskett wrote: > >Is it a separate bug to fuss about the near total lack of meaning to > > the man pages for ip and its children. > > Assuming you have no substantive suggestions, it's not a bug report at > all, it's just complaining. Hmmf. If I could make an educated suggestion, but I've not got a clue as to how it is supposed to work, those pages aren't a how-to, so I'd be pinning the tail on the donkey just as if I was blindfolded. But this isn't a party. If printed on Northern's TP stock, then they might be good for something. So how does one lodge a complaint that might actually be acted on? You've read here, and have noted that they have not been defended by anyone, and a couple posts have agreed with my assessment. Sigh... -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2018-10-29 21:30 +0100 |
| Message-ID | <wOmkF-6IB-11@gated-at.bofh.it> |
| In reply to | #201850 |
Just file a bug report describing what you did, what you expected to happen, what did happen, and why you believe that the difference constitutes a bug. No need to include a patch. -- John Hasler jhasler@newsguy.com Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2018-10-29 21:40 +0100 |
| Message-ID | <wOmul-6Ly-5@gated-at.bofh.it> |
| In reply to | #201850 |
On Mon 29 Oct 2018 at 16:11:01 -0400, Gene Heskett wrote: > On Monday 29 October 2018 11:05:32 Michael Stone wrote: > > > On Mon, Oct 29, 2018 at 10:45:50AM -0400, Gene Heskett wrote: > > >Is it a separate bug to fuss about the near total lack of meaning to > > > the man pages for ip and its children. > > > > Assuming you have no substantive suggestions, it's not a bug report at > > all, it's just complaining. > > Hmmf. If I could make an educated suggestion, but I've not got a clue as > to how it is supposed to work, those pages aren't a how-to, so I'd be > pinning the tail on the donkey just as if I was blindfolded. But this > isn't a party. > > If printed on Northern's TP stock, then they might be good for something. > > So how does one lodge a complaint that might actually be acted on? You don't want to do that. Complaints get filed in /dev/null by Linux Central. Now - if you completely rewrote the man page you complain about, the rewrite could be considered. Baited breath and all that. > You've read here, and have noted that they have not been defended by > anyone, and a couple posts have agreed with my assessment. The documentation issue is a sideshow to distract from your destruction of a sane stretch network setup. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2018-10-29 21:50 +0100 |
| Message-ID | <wOmE1-6P4-13@gated-at.bofh.it> |
| In reply to | #201853 |
On Mon 29 Oct 2018 at 20:37:18 +0000, Brian wrote: > about, the rewrite could be considered. Baited breath and all that. "Bated", if preferred. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2018-10-28 20:00 +0100 |
| Message-ID | <wNYs2-Sp-1@gated-at.bofh.it> |
| In reply to | #201807 |
On Sun 28 Oct 2018 at 12:56:13 -0400, The Wanderer wrote: > On 2018-10-28 at 12:23, Reco wrote: > > > > 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. What we know for sure is that "I installed stretch". That's like saying "I made a curry". Someone following in the footsteps of both cookers would have to know what the ingredients were and and whether the outcome was a success initially. Not much point in carrying on if it wasn't. I'd suggest that any adjustments after first installation/cooking are, for some chefs, just as likely to degrade as to enhance the dish. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2018-10-28 20:10 +0100 |
| Message-ID | <wNYBH-1aU-3@gated-at.bofh.it> |
| In reply to | #201804 |
On Sunday 28 October 2018 12:23:35 Reco wrote: > Hi. > > On Sun, Oct 28, 2018 at 12:04:54PM -0400, Gene Heskett wrote: > > > On Sun, Oct 28, 2018 at 07:04:02AM -0400, Gene Heskett wrote: > > > > > Ever consider you're doing it the wrong way? > > > > > This will work: > > > > > > > > > > iface eth0 inet static > > > > > address 192.168.NN.12 > > > > > netmask 24 > > > > > gateway 192.168.NN.1 > > > > > > > > in 20 years, I have never seen that syntax used. What man page > > > > do I find that format in. > > > > > > 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. > > > address 192.168.##.##/24 is supposed to be understood as netmask > > 255.255.255.0, and has worked here forever. And remains in the man 5 > > interfaces page. > > True. > > > And has Just Worked, until now with stretch. > > And it does now. > > > Also, I haven't ever seen an official definition of "CIDR", so its > > possible I need tutoring on that. IMO any man page that uses an > > acronym, needs to include its definition. > > RFC 4632. As official as it gets. > So I read it. At no place in that document is netmask stated in the "netmask 24" format, its always as address/24 or dotted quad. Next argument? > > > > > 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. > > So, either it did not happen, or ...? > > Reco -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2018-10-28 20:30 +0100 |
| Message-ID | <wNYV4-1hm-39@gated-at.bofh.it> |
| In reply to | #201802 |
On Sun 28 Oct 2018 at 12:04:54 -0400, Gene Heskett wrote: > Maybe its time we let this thread die, it is working now, as I have other > hardware problems to deal with ATM. With shipping delays delays from the > Chinglish writers, till around thanksgiving here in the yuuh ess aye. > Needless to say I've ordered spares. I am having difficulty in understanding the first part of the second sentence (up to the comma). Is there a derogatory aspect to it? -- Brian.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web