Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #199383 > unrolled thread

My wired connection doesn't work suddenly (Debian sid)

Back to article view | Back to linux.debian.user

Contents

  My wired connection doesn't work suddenly (Debian sid) Vinícius Couto <vimcless@gmail.com> - 2018-08-26 13:10 +0200
    Re: My wired connection doesn't work suddenly (Debian sid) Reco <recoverym4n@gmail.com> - 2018-08-26 15:00 +0200
      Re: My wired connection doesn't work suddenly (Debian sid) Gene Heskett <gheskett@shentel.net> - 2018-08-26 15:50 +0200
        iproute, NM and ifupdown (was: My wired connection doesn't work  suddenly (Debian sid)) Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-08-26 16:30 +0200
          Re: iproute, NM and ifupdown (was: My wired connection doesn't work suddenly (Debian sid)) Gene Heskett <gheskett@shentel.net> - 2018-08-26 17:30 +0200
            Re: iproute, NM and ifupdown Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-08-26 19:40 +0200
              Re: iproute, NM and ifupdown Gene Heskett <gheskett@shentel.net> - 2018-08-26 20:30 +0200
                Re: iproute, NM and ifupdown David Wright <deblis@lionunicorn.co.uk> - 2018-08-27 22:00 +0200
                  Re: iproute, NM and ifupdown Gene Heskett <gheskett@shentel.net> - 2018-08-28 01:30 +0200
                    Re: iproute, NM and ifupdown David Wright <deblis@lionunicorn.co.uk> - 2018-08-28 20:20 +0200
                      Re: iproute, NM and ifupdown Gene Heskett <gheskett@shentel.net> - 2018-08-28 21:00 +0200
                        Re: iproute, NM and ifupdown Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2018-08-28 21:10 +0200
                        Re: iproute, NM and ifupdown David Wright <deblis@lionunicorn.co.uk> - 2018-08-28 22:00 +0200

#199383 — My wired connection doesn't work suddenly (Debian sid)

[Multipart message — attachments visible in raw view] — view raw

Hi,

I use Debian sid and some weeks ago, a upgrade in some package caused a
strange thing.

I use my computer, when my wired connection down. Sometimes only the IPv4,
sometimes all the connections.
The symbol of the wired connection says that the connection is working.
When i disable to use a wireless connection in the same network, it works.


When i use dmesg | grep r8169
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:02:00.0 eth0: RTL8168evl/8111evl at 0x        (ptrval), ..., XID
... IRQ ..
r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx
checksumming: ko]
r8169 0000:02:00.0 enp2s0: renamed from eth0
r8169 0000:02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168e-3.fw

dmesg | grep enp2s0
TCP: enp2s0: Driver has suspect GRO implementation, TCP performance may be
compromised.

What is happening to my computer?

Reggard,

[toc] | [next] | [standalone]

#199385

	Hi.

On Sun, Aug 26, 2018 at 07:42:31AM -0300, Vinícius Couto wrote:
> Hi,
> 
> I use Debian sid and some weeks ago, a upgrade in some package caused a
> strange thing.
> 
> I use my computer, when my wired connection down. Sometimes only the IPv4,
> sometimes all the connections.

Yet another NetworkManager fault, most likely. The thing lives to its
reputation once more.


> The symbol of the wired connection says that the connection is working.
> When i disable to use a wireless connection in the same network, it works.

Of all the ways to test network connection you just used the least
informative one. Please share the output of "ip a l" and "ip ro l" next
time this happens.


> When i use dmesg | grep r8169
> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> r8169 0000:02:00.0 eth0: RTL8168evl/8111evl at 0x        (ptrval), ..., XID
> ... IRQ ..
> r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx
> checksumming: ko]

Pretty normal.

> r8169 0000:02:00.0 enp2s0: renamed from eth0

That's systemd thing.

> r8169 0000:02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168e-3.fw

And here you've used non-free blob, which is most likely completely
unnecessary. But it's unlikely that any of these are somehow related to
your problem.


> dmesg | grep enp2s0
> TCP: enp2s0: Driver has suspect GRO implementation, TCP performance may be
> compromised.

And that says that your NIC has problematic Generic Receive Offload
implementation, yet kernel enabled it.
Try "ethtool -K enp2s0 gro off" if it bothers you, but it'll unlikely
will have any visible effect.

> What is happening to my computer?

Network Manager. See above.

Reco

[toc] | [prev] | [next] | [standalone]

#199387

On Sunday 26 August 2018 08:55:55 Reco wrote:

> 	Hi.
>
> On Sun, Aug 26, 2018 at 07:42:31AM -0300, Vinícius Couto wrote:
> > Hi,
> >
> > I use Debian sid and some weeks ago, a upgrade in some package
> > caused a strange thing.
> >
> > I use my computer, when my wired connection down. Sometimes only the
> > IPv4, sometimes all the connections.
>
> Yet another NetworkManager fault, most likely. The thing lives to its
> reputation once more.
>
> > The symbol of the wired connection says that the connection is
> > working. When i disable to use a wireless connection in the same
> > network, it works.
>
> Of all the ways to test network connection you just used the least
> informative one. Please share the output of "ip a l" and "ip ro l"
> next time this happens.
>
Why do I have to read a mailing list to learn how to use these  new ip 
tools. Those two examples tell me more than than 20 readings of the man 
page, thank you Reco.

> > When i use dmesg | grep r8169
> > r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> > r8169 0000:02:00.0 eth0: RTL8168evl/8111evl at 0x        (ptrval),
> > ..., XID ... IRQ ..
> > r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx
> > checksumming: ko]
>
> Pretty normal.
>
> > r8169 0000:02:00.0 enp2s0: renamed from eth0
>
> That's systemd thing.
>
> > r8169 0000:02:00.0: firmware: direct-loading firmware
> > rtl_nic/rtl8168e-3.fw
>
> And here you've used non-free blob, which is most likely completely
> unnecessary. But it's unlikely that any of these are somehow related
> to your problem.
>
> > dmesg | grep enp2s0
> > TCP: enp2s0: Driver has suspect GRO implementation, TCP performance
> > may be compromised.
>
> And that says that your NIC has problematic Generic Receive Offload
> implementation, yet kernel enabled it.
> Try "ethtool -K enp2s0 gro off" if it bothers you, but it'll unlikely
> will have any visible effect.
>
> > What is happening to my computer?
>
> Network Manager. See above.
>
> Reco

Rant mode ON

What I have never understood about N-M is why it tears down a perfectly 
good, working connection, and spends 5 minutes trying to establish a new 
one, and failing, leaving the poor user no way to ask a mailing list for 
help. Thats unforgivable and unforgiven here. Theres some keywords 
(mentioned in the man page in obtuse language IIRC) to use in e-n-i to 
tell N_M to keep its malicious hands off a given interface, but you have 
to read between the lines with your logical superpowers to detect them. 
There now, but for the longest time removing its starter script via 
chkconfig or removing N-M with the package manager, not possible a 
decade ago without its dependencies tearing down the system so I used mc 
for that, nuking the binaries. So its getting better, but as can be seen 
above its not perfect yet for folks needing portability. And I've used 
WICD for that in past years when I needed my old lappy to give me email 
and browsing from a motel room 950 miles from home while I was out 
playing visiting tv engineer. But my old lappy has a busted bcm4318 
based radio that not even the windows xp drivers could make work, so I'm 
glad the motel had radios I could plug into its net port.

Thanks for reading this far.

/Rant mode OFF

-- 
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]

#199389 — iproute, NM and ifupdown (was: My wired connection doesn't work suddenly (Debian sid))

Le 26/08/2018 à 15:40, Gene Heskett a écrit :
>>
> Why do I have to read a mailing list to learn how to use these  new ip
> tools.

"New" ? iproute has been around for more that 20 years !

> Theres some keywords
> (mentioned in the man page in obtuse language IIRC) to use in e-n-i to
> tell N_M to keep its malicious hands off a given interface, but you have
> to read between the lines with your logical superpowers to detect them.

No, there is no obscure keyword and nothing between the lines.
By default, NM does not manage any interface configured in 
/etc/network/interfaces. So all you have to do is configure your 
interface with an "iface" stanza in /etc/network/interfaces as usual so 
that it is managed by ifupdown and not by NM.

[toc] | [prev] | [next] | [standalone]

#199393 — Re: iproute, NM and ifupdown (was: My wired connection doesn't work suddenly (Debian sid))

On Sunday 26 August 2018 10:24:35 Pascal Hambourg wrote:

> Le 26/08/2018 à 15:40, Gene Heskett a écrit :
> > Why do I have to read a mailing list to learn how to use these  new
> > ip tools.
>
> "New" ? iproute has been around for more that 20 years !
>
> > Theres some keywords
> > (mentioned in the man page in obtuse language IIRC) to use in e-n-i
> > to tell N_M to keep its malicious hands off a given interface, but
> > you have to read between the lines with your logical superpowers to
> > detect them.
>
> No, there is no obscure keyword and nothing between the lines.

Oh? And you wrote that manpage I suppose, and you don't make mistakes...

You may be able to read it, knowing what you "intended" to write. But 
others aren't mind readers.

But we can add 2+2 and get a quite precisely defined 4.0000000000.

> By default, NM does not manage any interface configured in
> /etc/network/interfaces. So all you have to do is configure your
> interface with an "iface" stanza in /etc/network/interfaces as usual
> so that it is managed by ifupdown and not by NM.

I have had N-M tear down a well configured staticly defined eth0 on 
dozens of occasions, despite using the iface designation in my e-n-i's. 
Most recently on a stretch install on a rock64 I had to erect immutable 
attributes to resolv.conf after making it a real file, and e-n-i to make 
networking Just Work.

It may not do it today, things do get improved but my linux experience 
dates to RH5.0 and 1998 and its been something I've had to edit e-n-i 
and then quickly make it immutable, ditto for making /etc/resolv.conf a 
real file and immutable ever since N-M was made virtually mandatory. My 
networking is not portable and with the exception of my ancient lappy 
will never be.

Theres a reason my /etc/hosts files are 20+ lines long, and my 
resolv.conf has a "search hosts nameserver" line in it, which N-M always 
removes if it can. The real file, made immutable fixes that too

N-M is helpless when there is not a dhcp server or a dhcp server that 
only recognizes the MAC of one machine for security reasons.

Based on my experience at making N-M work, you might want to get a 
shorter horse.

-- 
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]

#199398 — Re: iproute, NM and ifupdown

Le 26/08/2018 à 17:24, Gene Heskett a écrit :
> On Sunday 26 August 2018 10:24:35 Pascal Hambourg wrote:
> 
>> Le 26/08/2018 à 15:40, Gene Heskett a écrit :
>>
>>> Theres some keywords
>>> (mentioned in the man page in obtuse language IIRC) to use in e-n-i
>>> to tell N_M to keep its malicious hands off a given interface, but
>>> you have to read between the lines with your logical superpowers to
>>> detect them.
>>
>> No, there is no obscure keyword and nothing between the lines.
> 
> Oh? And you wrote that manpage I suppose, and you don't make mistakes...

Irrelevant.

> You may be able to read it, knowing what you "intended" to write. But
> others aren't mind readers.

Maybe I was not clear enough. Let me rephrase a bit.

Contrary to what you wrote, there is no obscure keyword to use in 
/etc/network/interfaces to tell NetworkManager to keep its hands off a 
given interface.

>> By default, NM does not manage any interface configured in
>> /etc/network/interfaces. So all you have to do is configure your
>> interface with an "iface" stanza in /etc/network/interfaces as usual
>> so that it is managed by ifupdown and not by NM.
> 
> I have had N-M tear down a well configured staticly defined eth0 on
> dozens of occasions, despite using the iface designation in my e-n-i's.
Then it is a bug which should be reported and fixed. It is not intended 
behaviour.

> Most recently on a stretch install on a rock64 I had to erect immutable
> attributes to resolv.conf after making it a real file, and e-n-i to make
> networking Just Work.

/etc/resolv.conf is a rather different topic, because it is not related 
to a specific interface and may be written by several pieces of 
software, including but not limited to NetworkManager when configuring 
*any* interface. I would suggest using resolvconf but I suspect you 
would not like it either.

[toc] | [prev] | [next] | [standalone]

#199399 — Re: iproute, NM and ifupdown

On Sunday 26 August 2018 13:36:41 Pascal Hambourg wrote:

> Le 26/08/2018 à 17:24, Gene Heskett a écrit :
> > On Sunday 26 August 2018 10:24:35 Pascal Hambourg wrote:
> >> Le 26/08/2018 à 15:40, Gene Heskett a écrit :
> >>> Theres some keywords
> >>> (mentioned in the man page in obtuse language IIRC) to use in
> >>> e-n-i to tell N_M to keep its malicious hands off a given
> >>> interface, but you have to read between the lines with your
> >>> logical superpowers to detect them.
> >>
> >> No, there is no obscure keyword and nothing between the lines.
> >
> > Oh? And you wrote that manpage I suppose, and you don't make
> > mistakes...
>
> Irrelevant.

If you didn't write it, I apologize for venting at the wrong person.
>
> > You may be able to read it, knowing what you "intended" to write.
> > But others aren't mind readers.
>
> Maybe I was not clear enough. Let me rephrase a bit.
>
> Contrary to what you wrote, there is no obscure keyword to use in
> /etc/network/interfaces to tell NetworkManager to keep its hands off a
> given interface.
>
> >> By default, NM does not manage any interface configured in
> >> /etc/network/interfaces. So all you have to do is configure your
> >> interface with an "iface" stanza in /etc/network/interfaces as
> >> usual so that it is managed by ifupdown and not by NM.
> >
> > I have had N-M tear down a well configured staticly defined eth0 on
> > dozens of occasions, despite using the iface designation in my
> > e-n-i's.
>
> Then it is a bug which should be reported and fixed. It is not
> intended behaviour.
>
Any fusses I have posted to bugzilla have all been "won't fix" in just a 
few minutes. You'd think its tailor was Dupont. Teflon suits IOW.
> > Most recently on a stretch install on a rock64 I had to erect
> > immutable attributes to resolv.conf after making it a real file, and
> > e-n-i to make networking Just Work.
>
> /etc/resolv.conf is a rather different topic, because it is not
> related to a specific interface and may be written by several pieces
> of software, including but not limited to NetworkManager when
> configuring *any* interface. I would suggest using resolvconf but I
> suspect you would not like it either.
Ohkaay, but where's the docs on this mysterious resolvconf?

What we do have is missing (wheezy) or horribly incomplete (jessie). 

But I'll have to take that back, my apologies. I just read the stretch 
version on that rock64.  And as man pages go, its decent. And I'll have 
to do some experimenting as its possible I can train it to behave.

And curious I blink compared the jessie vs stretch versions, stretch's is 
both longer AND more complete, and two different authors and formatted 
completely different. And wheezy doesn't even have the man page. I don't 
even know if it should, maybe not for wheezy, lots of water has been 
recycled since those installs were made, so I'll plead oldtimers.

-- 
Cheers Pascal, 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]

#199457 — Re: iproute, NM and ifupdown

On Sun 26 Aug 2018 at 14:24:23 (-0400), Gene Heskett wrote:
> On Sunday 26 August 2018 13:36:41 Pascal Hambourg wrote:
> > Le 26/08/2018 à 17:24, Gene Heskett a écrit :
> > > Most recently on a stretch install on a rock64 I had to erect
> > > immutable attributes to resolv.conf after making it a real file, and
> > > e-n-i to make networking Just Work.
> >
> > /etc/resolv.conf is a rather different topic, because it is not
> > related to a specific interface and may be written by several pieces
> > of software, including but not limited to NetworkManager when
> > configuring *any* interface. I would suggest using resolvconf but I
> > suspect you would not like it either.
> Ohkaay, but where's the docs on this mysterious resolvconf?
> 
> What we do have is missing (wheezy) or horribly incomplete (jessie). 
> 
> But I'll have to take that back, my apologies. I just read the stretch 
> version on that rock64.  And as man pages go, its decent. And I'll have 
> to do some experimenting as its possible I can train it to behave.
> 
> And curious I blink compared the jessie vs stretch versions, stretch's is 
> both longer AND more complete, and two different authors and formatted 
> completely different. And wheezy doesn't even have the man page. I don't 
> even know if it should, maybe not for wheezy, lots of water has been 
> recycled since those installs were made, so I'll plead oldtimers.

This is very strange. I just did (in 80 column xterms):

$ man resolvconf > /tmp/resolvconf-stretch

and the same for jessie and wheezy on the appropriate computers.

$ diff /tmp/resolvconf-[sj]*
3,4d2
< 
< 
278d275
< 
295,296d291
< 
< 
$ 

so a few blank lines have been removed between jessie and stretch.
As for wheezy not having a man page:

$ wc /tmp/resolvconf-wheezy 
  301  1748 14876 /tmp/resolvconf-wheezy
$ cat /etc/debian_version 
7.11
$ dpkg -l resolvconf
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                Version        Architecture   Description
+++-===================-==============-==============-===========================================
ii  resolvconf          1.67           all            name server information handler
$ dpkg -L resolvconf | grep /man./
/usr/share/man/man8/resolvconf.8.gz
/usr/share/man/man5/interface-order.5.gz
$ 

So one can't help wondering exactly what is installed on your machines
if things don't match. Note that there are significant differences
between the different versions, so following the stretch/jessie man
page could give you problems on a wheezy machine. (I haven't checked
out backports.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#199465 — Re: iproute, NM and ifupdown

On Monday 27 August 2018 15:59:09 David Wright wrote:

> On Sun 26 Aug 2018 at 14:24:23 (-0400), Gene Heskett wrote:
> > On Sunday 26 August 2018 13:36:41 Pascal Hambourg wrote:
> > > Le 26/08/2018 à 17:24, Gene Heskett a écrit :
> > > > Most recently on a stretch install on a rock64 I had to erect
> > > > immutable attributes to resolv.conf after making it a real file,
> > > > and e-n-i to make networking Just Work.
> > >
> > > /etc/resolv.conf is a rather different topic, because it is not
> > > related to a specific interface and may be written by several
> > > pieces of software, including but not limited to NetworkManager
> > > when configuring *any* interface. I would suggest using resolvconf
> > > but I suspect you would not like it either.
> >
> > Ohkaay, but where's the docs on this mysterious resolvconf?
> >
> > What we do have is missing (wheezy) or horribly incomplete (jessie).
> >
> > But I'll have to take that back, my apologies. I just read the
> > stretch version on that rock64.  And as man pages go, its decent.
> > And I'll have to do some experimenting as its possible I can train
> > it to behave.
> >
> > And curious I blink compared the jessie vs stretch versions,
> > stretch's is both longer AND more complete, and two different
> > authors and formatted completely different. And wheezy doesn't even
> > have the man page. I don't even know if it should, maybe not for
> > wheezy, lots of water has been recycled since those installs were
> > made, so I'll plead oldtimers.
>
> This is very strange. I just did (in 80 column xterms):
>
> $ man resolvconf > /tmp/resolvconf-stretch
>
> and the same for jessie and wheezy on the appropriate computers.
>
> $ diff /tmp/resolvconf-[sj]*
> 3,4d2
> <
> <
> 278d275
> <
> 295,296d291
> <
> <
> $
>
> so a few blank lines have been removed between jessie and stretch.
> As for wheezy not having a man page:
>
> $ wc /tmp/resolvconf-wheezy
>   301  1748 14876 /tmp/resolvconf-wheezy
> $ cat /etc/debian_version
> 7.11
> $ dpkg -l resolvconf
> Desired=Unknown/Install/Remove/Purge/Hold
>
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/T
> |rig-pend / Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> |
> ||/ Name                Version        Architecture   Description
>
> +++-===================-==============-==============-================
>=========================== ii  resolvconf          1.67           all 
>           name server information handler $ dpkg -L resolvconf | grep
> /man./
> /usr/share/man/man8/resolvconf.8.gz
> /usr/share/man/man5/interface-order.5.gz
> $
>
> So one can't help wondering exactly what is installed on your machines
> if things don't match. Note that there are significant differences
> between the different versions, so following the stretch/jessie man
> page could give you problems on a wheezy machine. (I haven't checked
> out backports.)
>
> Cheers,
> David.

What is installed on 4 of the 6 boxes here, is a wheezy install thats 
been tweaked to A: put a realtime kernel on it so it can run linuxcnc on 
real hardware. The stretch I'll install here after my new drive cage 
arrives, and I found today that newegg's fedex is a week for delivery, 
its not expected to arrive here before Thursday evening, has also been 
tweaked to run LinuxCNC, probably by a real time kernel replacement..

Thanks David, gotta run the mussus just called on the intercom.  Later.

-- 
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]

#199514 — Re: iproute, NM and ifupdown

On Mon 27 Aug 2018 at 19:21:00 (-0400), Gene Heskett wrote:
> On Monday 27 August 2018 15:59:09 David Wright wrote:
> > On Sun 26 Aug 2018 at 14:24:23 (-0400), Gene Heskett wrote:
> > > On Sunday 26 August 2018 13:36:41 Pascal Hambourg wrote:
> > > > Le 26/08/2018 à 17:24, Gene Heskett a écrit :
> > > > > Most recently on a stretch install on a rock64 I had to erect
> > > > > immutable attributes to resolv.conf after making it a real file,
> > > > > and e-n-i to make networking Just Work.
> > > >
> > > > /etc/resolv.conf is a rather different topic, because it is not
> > > > related to a specific interface and may be written by several
> > > > pieces of software, including but not limited to NetworkManager
> > > > when configuring *any* interface. I would suggest using resolvconf
> > > > but I suspect you would not like it either.
> > >
> > > Ohkaay, but where's the docs on this mysterious resolvconf?
> > >
> > > What we do have is missing (wheezy) or horribly incomplete (jessie).
> > >
> > > But I'll have to take that back, my apologies. I just read the
> > > stretch version on that rock64.  And as man pages go, its decent.
> > > And I'll have to do some experimenting as its possible I can train
> > > it to behave.
> > >
> > > And curious I blink compared the jessie vs stretch versions,
> > > stretch's is both longer AND more complete, and two different
> > > authors and formatted completely different. And wheezy doesn't even
> > > have the man page. I don't even know if it should, maybe not for
> > > wheezy, lots of water has been recycled since those installs were
> > > made, so I'll plead oldtimers.
> >
> > This is very strange. I just did (in 80 column xterms):

[snipped various properties of resolvconf's man page on wheezy/jessie/stretch.]

> > So one can't help wondering exactly what is installed on your machines
> > if things don't match. Note that there are significant differences
> > between the different versions, so following the stretch/jessie man
> > page could give you problems on a wheezy machine. (I haven't checked
> > out backports.)
> 
> What is installed on 4 of the 6 boxes here, is a wheezy install thats 
> been tweaked to A: put a realtime kernel on it so it can run linuxcnc on 
> real hardware. The stretch I'll install here after my new drive cage 
> arrives, and I found today that newegg's fedex is a week for delivery, 
> its not expected to arrive here before Thursday evening, has also been 
> tweaked to run LinuxCNC, probably by a real time kernel replacement..

Which kernel you run should have no connection with the contents of
Debian's resolvconf packages. You should still have these three:

 4575 Jun 19  2012 /usr/share/man/man8/resolvconf.8.gz
 4500 Jan 27  2015 /usr/share/man/man8/resolvconf.8.gz
 4500 May 19  2016 /usr/share/man/man8/resolvconf.8.gz

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#199521 — Re: iproute, NM and ifupdown

On Tuesday 28 August 2018 14:16:15 David Wright wrote:

> On Mon 27 Aug 2018 at 19:21:00 (-0400), Gene Heskett wrote:
> > On Monday 27 August 2018 15:59:09 David Wright wrote:
> > > On Sun 26 Aug 2018 at 14:24:23 (-0400), Gene Heskett wrote:
> > > > On Sunday 26 August 2018 13:36:41 Pascal Hambourg wrote:
> > > > > Le 26/08/2018 à 17:24, Gene Heskett a écrit :
> > > > > > Most recently on a stretch install on a rock64 I had to
> > > > > > erect immutable attributes to resolv.conf after making it a
> > > > > > real file, and e-n-i to make networking Just Work.
> > > > >
> > > > > /etc/resolv.conf is a rather different topic, because it is
> > > > > not related to a specific interface and may be written by
> > > > > several pieces of software, including but not limited to
> > > > > NetworkManager when configuring *any* interface. I would
> > > > > suggest using resolvconf but I suspect you would not like it
> > > > > either.
> > > >
> > > > Ohkaay, but where's the docs on this mysterious resolvconf?
> > > >
> > > > What we do have is missing (wheezy) or horribly incomplete
> > > > (jessie).
> > > >
> > > > But I'll have to take that back, my apologies. I just read the
> > > > stretch version on that rock64.  And as man pages go, its
> > > > decent. And I'll have to do some experimenting as its possible I
> > > > can train it to behave.
> > > >
> > > > And curious I blink compared the jessie vs stretch versions,
> > > > stretch's is both longer AND more complete, and two different
> > > > authors and formatted completely different. And wheezy doesn't
> > > > even have the man page. I don't even know if it should, maybe
> > > > not for wheezy, lots of water has been recycled since those
> > > > installs were made, so I'll plead oldtimers.
> > >
> > > This is very strange. I just did (in 80 column xterms):
>
> [snipped various properties of resolvconf's man page on
> wheezy/jessie/stretch.]
>
> > > So one can't help wondering exactly what is installed on your
> > > machines if things don't match. Note that there are significant
> > > differences between the different versions, so following the
> > > stretch/jessie man page could give you problems on a wheezy
> > > machine. (I haven't checked out backports.)
> >
> > What is installed on 4 of the 6 boxes here, is a wheezy install
> > thats been tweaked to A: put a realtime kernel on it so it can run
> > linuxcnc on real hardware. The stretch I'll install here after my
> > new drive cage arrives, and I found today that newegg's fedex is a
> > week for delivery, its not expected to arrive here before Thursday
> > evening, has also been tweaked to run LinuxCNC, probably by a real
> > time kernel replacement..
>
> Which kernel you run should have no connection with the contents of
> Debian's resolvconf packages. You should still have these three:
>
>  4575 Jun 19  2012 /usr/share/man/man8/resolvconf.8.gz
>  4500 Jan 27  2015 /usr/share/man/man8/resolvconf.8.gz
>  4500 May 19  2016 /usr/share/man/man8/resolvconf.8.gz
>
not on any wheezy sourced from the linuxcnc install iso, David

My /etc/resolv.conf is a real file and looks something like this:

nameserver 192.168.71.1
search hosts nameserver

And it Just Works.

> Cheers,
> David.



-- 
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]

#199522 — Re: iproute, NM and ifupdown

On 8/28/18, Gene Heskett <gheskett@shentel.net> wrote:
> On Tuesday 28 August 2018 14:16:15 David Wright wrote:
>
>> On Mon 27 Aug 2018 at 19:21:00 (-0400), Gene Heskett wrote:
>> > On Monday 27 August 2018 15:59:09 David Wright wrote:
>> > > On Sun 26 Aug 2018 at 14:24:23 (-0400), Gene Heskett wrote:
>> > > > On Sunday 26 August 2018 13:36:41 Pascal Hambourg wrote:
>> > > > > Le 26/08/2018 à 17:24, Gene Heskett a écrit :
>> > > > > > Most recently on a stretch install on a rock64 I had to
>> > > > > > erect immutable attributes to resolv.conf after making it a
>> > > > > > real file, and e-n-i to make networking Just Work.
>> > > > >
>> > > > > /etc/resolv.conf is a rather different topic, because it is
>> > > > > not related to a specific interface and may be written by
>> > > > > several pieces of software, including but not limited to
>> > > > > NetworkManager when configuring *any* interface. I would
>> > > > > suggest using resolvconf but I suspect you would not like it
>> > > > > either.
>> > > >
>> > > > Ohkaay, but where's the docs on this mysterious resolvconf?
>> > > >
>> > > > What we do have is missing (wheezy) or horribly incomplete
>> > > > (jessie).
>> > > >
>> > > > But I'll have to take that back, my apologies. I just read the
>> > > > stretch version on that rock64.  And as man pages go, its
>> > > > decent. And I'll have to do some experimenting as its possible I
>> > > > can train it to behave.
>> > > >
>> > > > And curious I blink compared the jessie vs stretch versions,
>> > > > stretch's is both longer AND more complete, and two different
>> > > > authors and formatted completely different. And wheezy doesn't
>> > > > even have the man page. I don't even know if it should, maybe
>> > > > not for wheezy, lots of water has been recycled since those
>> > > > installs were made, so I'll plead oldtimers.
>> > >
>> > > This is very strange. I just did (in 80 column xterms):
>>
>> [snipped various properties of resolvconf's man page on
>> wheezy/jessie/stretch.]
>>
>> > > So one can't help wondering exactly what is installed on your
>> > > machines if things don't match. Note that there are significant
>> > > differences between the different versions, so following the
>> > > stretch/jessie man page could give you problems on a wheezy
>> > > machine. (I haven't checked out backports.)
>> >
>> > What is installed on 4 of the 6 boxes here, is a wheezy install
>> > thats been tweaked to A: put a realtime kernel on it so it can run
>> > linuxcnc on real hardware. The stretch I'll install here after my
>> > new drive cage arrives, and I found today that newegg's fedex is a
>> > week for delivery, its not expected to arrive here before Thursday
>> > evening, has also been tweaked to run LinuxCNC, probably by a real
>> > time kernel replacement..
>>
>> Which kernel you run should have no connection with the contents of
>> Debian's resolvconf packages. You should still have these three:
>>
>>  4575 Jun 19  2012 /usr/share/man/man8/resolvconf.8.gz
>>  4500 Jan 27  2015 /usr/share/man/man8/resolvconf.8.gz
>>  4500 May 19  2016 /usr/share/man/man8/resolvconf.8.gz
>>
> not on any wheezy sourced from the linuxcnc install iso, David
>
> My /etc/resolv.conf is a real file and looks something like this:
>
> nameserver 192.168.71.1
> search hosts nameserver
>
> And it Just Works.
>
>> Cheers,
>> David.
>
>
>
> --
> 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>
>
>

Mine is immutable as well. I have Google DNS Configured.

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4888:3b:ff00:3c2:d::
nameserver 2001:4888:32:ff00:3c1:d::

[toc] | [prev] | [next] | [standalone]

#199524 — Re: iproute, NM and ifupdown

On Tue 28 Aug 2018 at 14:57:58 (-0400), Gene Heskett wrote:
> On Tuesday 28 August 2018 14:16:15 David Wright wrote:
> 
> > On Mon 27 Aug 2018 at 19:21:00 (-0400), Gene Heskett wrote:
> > > On Monday 27 August 2018 15:59:09 David Wright wrote:
> > > > On Sun 26 Aug 2018 at 14:24:23 (-0400), Gene Heskett wrote:
> > > > > On Sunday 26 August 2018 13:36:41 Pascal Hambourg wrote:
> > > > > > Le 26/08/2018 à 17:24, Gene Heskett a écrit :
> > > > > > > Most recently on a stretch install on a rock64 I had to
> > > > > > > erect immutable attributes to resolv.conf after making it a
> > > > > > > real file, and e-n-i to make networking Just Work.
> > > > > >
> > > > > > /etc/resolv.conf is a rather different topic, because it is
> > > > > > not related to a specific interface and may be written by
> > > > > > several pieces of software, including but not limited to
> > > > > > NetworkManager when configuring *any* interface. I would
> > > > > > suggest using resolvconf but I suspect you would not like it
> > > > > > either.

Reread what you wrote:

> > > > > Ohkaay, but where's the docs on this mysterious resolvconf?
> > > > >
> > > > > What we do have is missing (wheezy) or horribly incomplete
> > > > > (jessie).
> > > > >
> > > > > But I'll have to take that back, my apologies. I just read the
> > > > > stretch version on that rock64.  And as man pages go, its
> > > > > decent. And I'll have to do some experimenting as its possible I
> > > > > can train it to behave.
> > > > >
> > > > > And curious I blink compared the jessie vs stretch versions,
> > > > > stretch's is both longer AND more complete, and two different
> > > > > authors and formatted completely different. And wheezy doesn't
> > > > > even have the man page. I don't even know if it should, maybe
> > > > > not for wheezy, lots of water has been recycled since those
> > > > > installs were made, so I'll plead oldtimers.

That's about the *man pages* for resolvconf.

> > > > This is very strange. I just did (in 80 column xterms):
> >
> > [snipped various properties of resolvconf's man page on
> > wheezy/jessie/stretch.]
> >
> > > > So one can't help wondering exactly what is installed on your
> > > > machines if things don't match. Note that there are significant
> > > > differences between the different versions, so following the
> > > > stretch/jessie man page could give you problems on a wheezy
> > > > machine. (I haven't checked out backports.)
> > >
> > > What is installed on 4 of the 6 boxes here, is a wheezy install
> > > thats been tweaked to A: put a realtime kernel on it so it can run
> > > linuxcnc on real hardware. The stretch I'll install here after my
> > > new drive cage arrives, and I found today that newegg's fedex is a
> > > week for delivery, its not expected to arrive here before Thursday
> > > evening, has also been tweaked to run LinuxCNC, probably by a real
> > > time kernel replacement..
> >
> > Which kernel you run should have no connection with the contents of
> > Debian's resolvconf packages. You should still have these three:
> >
> >  4575 Jun 19  2012 /usr/share/man/man8/resolvconf.8.gz
> >  4500 Jan 27  2015 /usr/share/man/man8/resolvconf.8.gz
> >  4500 May 19  2016 /usr/share/man/man8/resolvconf.8.gz

Those are the man pages (your "docs") for wheezy/jessie/stretch.
They should be on your various systems according to Debian codename.

> not on any wheezy sourced from the linuxcnc install iso, David

Well, look again. In /usr/share/man/man8/, not /etc/.

> My /etc/resolv.conf is a real file and looks something like this:
> 
> nameserver 192.168.71.1
> search hosts nameserver
> 
> And it Just Works.

Yes, /etc/resolv.conf is not a man page. And I don't suppose your
/etc/resolv.conf is missing from wheezy or horribly incomplete in
jessie, which is what you were claiming for the *docs*.

And note that none of this is about the man page for resolv.conf which
is in section (5) rather than (8) as it's about a file, not a command.
If you read the latter, you'll see that your line "search hosts nameserver"
doesn't make a lot of sense.

But that's a conversation we had last year.
https://lists.debian.org/debian-user/2017/08/msg01432.html

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web