Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
in /etc/network/interfaces: "auto" vs "allow-hotplug"
6,622 views
Skip to first unread message
Rick Thomas
Sep 24, 2017, 12:00:05 AM9/24/17
to
I have two machines (out of a group of ten) that will not bring up their ethernet interface at boot time if the interfaces is of type “allow-hotplug”. When I change that to “auto” the interface comes up at boot with no problem…
The remaining eight machines have no problem with allow-hotplug. (which is the default as setup by the d-i)
It does not seem to correlate to kernel version. The two “auto” machines are running 4.12 and 4.9; The “allow-hotplug” machines are running anything between 3.16 and 4.12.
Nor does it seem to correlate with static vs dhcp. The two “auto” machines are both using dhcp. The “allow-hotplug” machines are using a mixture of static and dhcp.
Anybody have a clue as to what’s going on?
Thanks in advance…
Rick
The remaining eight machines have no problem with allow-hotplug. (which is the default as setup by the d-i)
It does not seem to correlate to kernel version. The two “auto” machines are running 4.12 and 4.9; The “allow-hotplug” machines are running anything between 3.16 and 4.12.
Nor does it seem to correlate with static vs dhcp. The two “auto” machines are both using dhcp. The “allow-hotplug” machines are using a mixture of static and dhcp.
Anybody have a clue as to what’s going on?
Thanks in advance…
Rick
Henrique de Moraes Holschuh
Sep 24, 2017, 9:30:06 AM9/24/17
to
On Sat, 23 Sep 2017, Rick Thomas wrote:
> I have two machines (out of a group of ten) that will not bring up
> their ethernet interface at boot time if the interfaces is of type
> “allow-hotplug”. When I change that to “auto” the interface comes up
> at boot with no problem…
...
> I have two machines (out of a group of ten) that will not bring up
> their ethernet interface at boot time if the interfaces is of type
> “allow-hotplug”. When I change that to “auto” the interface comes up
> at boot with no problem…
> Anybody have a clue as to what’s going on?
anything PCIe/SoC.
allow-hotplug: *wait* for kernel+drivers+udev to detect the device,
then ip link set <dev> up it. The only thing that can
deal with annoying USB, SDIO, etc.
This can be kinda important when non-auto-loading stuff is involved, or
when network file systems are involved.
So, look at what *exact* kind of network device you're dealing with.
--
Henrique Holschuh
Rick Thomas
Sep 25, 2017, 5:20:06 AM9/25/17
to
In both cases, the ethernet interface is on the motherboard, which (I guess) means they are PCI.
One is an Apple PowerMac G5. lspci says:
0002:20:0f.0 Ethernet controller: Apple Inc. UniNorth 2 GMAC (Sun GEM)
The other is a Toshiba Satellite laptop. lspci says:
02:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
08:00.0 Ethernet controller: Qualcomm Atheros AR8152 v1.1 Fast Ethernet (rev c1)
The interface in question is the Fast Ethernet, not the Wireless (which is unused)
Since “allow-hotplug” seems to work OK most of the time, even for PCI/PCIe/SoC, and “auto” doesn’t work at all for USB, I guess that’s why the installer uses “allow-hotplug” by default. Or maybe they just chose the first thing that seemed to work long ago and have not seen any reason to change it?
I’ve only started seeing this since Stretch (though I may have seen it once or twice in late revs of Jessie). Do you have any idea what may have changed in that timeframe?
Another semi-correlation that may be relevant: The two that require “auto” both have new-style network interface names. One of the “allow-hotplug” machines also has a new-style name, but all the rest have old-style “eth#” names.
If it really is true that for PCI/PCIe/SOC interfaces, the best choice is “auto”: Is there some way the installer could know the difference and do the “right thing” in all cases?
Thoughts?
Rick
Greg Wooledge
Sep 25, 2017, 9:10:06 AM9/25/17
to
On Sat, Sep 23, 2017 at 08:56:49PM -0700, Rick Thomas wrote:
> I have two machines (out of a group of ten) that will not bring up their ethernet interface at boot time if the interfaces is of type “allow-hotplug”. When I change that to “auto” the interface comes up at boot with no problem…
>
> The remaining eight machines have no problem with allow-hotplug. (which is the default as setup by the d-i)
The basic difference is the order in which services get loaded at
> I have two machines (out of a group of ten) that will not bring up their ethernet interface at boot time if the interfaces is of type “allow-hotplug”. When I change that to “auto” the interface comes up at boot with no problem…
>
> The remaining eight machines have no problem with allow-hotplug. (which is the default as setup by the d-i)
boot time, and whether the services wait for something, or just go.
An interface marked "auto" will be waited-for by services that are
configured to wait for interfaces to be up. E.g. mounting NFS file
systems, or starting an NFS server.
An interface marked "allow-hotplug" is considered nonessential or
transient, and the core OS services won't wait for it before starting.
Greg Wooledge
Sep 25, 2017, 11:50:06 AM9/25/17
to
On Mon, Sep 25, 2017 at 11:40:12AM -0400, Gene Heskett wrote:
> stretch install for an arm64 has no man command. If the man page can be
> found, zmore can read it but thats such an eyeball assault you lose
> track of what it was you wanted to check.
It's not in the man pages anyway. It's the sort of thing you either
find out the hard way, or because someone tells you.
Also, there's http://manpages.debian.org/interfaces
In fact, the man page outright *lies* and says they're synonyms. Didn't
notice that until just now.
> On Monday 25 September 2017 09:00:51 Greg Wooledge wrote:
> > An interface marked "auto" will be waited-for by services that are
> > configured to wait for interfaces to be up. E.g. mounting NFS file
> > systems, or starting an NFS server.
> >
> > An interface marked "allow-hotplug" is considered nonessential or
> > transient, and the core OS services won't wait for it before starting.
>
> Thank you Greg. Its not possible to check that because a new minimal
> > An interface marked "auto" will be waited-for by services that are
> > configured to wait for interfaces to be up. E.g. mounting NFS file
> > systems, or starting an NFS server.
> >
> > An interface marked "allow-hotplug" is considered nonessential or
> > transient, and the core OS services won't wait for it before starting.
>
> stretch install for an arm64 has no man command. If the man page can be
> found, zmore can read it but thats such an eyeball assault you lose
> track of what it was you wanted to check.
It's not in the man pages anyway. It's the sort of thing you either
find out the hard way, or because someone tells you.
Also, there's http://manpages.debian.org/interfaces
In fact, the man page outright *lies* and says they're synonyms. Didn't
notice that until just now.
Gene Heskett
Sep 25, 2017, 11:50:06 AM9/25/17
to
On Monday 25 September 2017 09:00:51 Greg Wooledge wrote:
Thank you Greg. Its not possible to check that because a new minimal
stretch install for an arm64 has no man command. If the man page can be
found, zmore can read it but thats such an eyeball assault you lose
track of what it was you wanted to check.
Cheers, Gene Heskett
stretch install for an arm64 has no man command. If the man page can be
found, zmore can read it but thats such an eyeball assault you lose
track of what it was you wanted to check.
--
"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>
Gene Heskett
Sep 25, 2017, 12:10:07 PM9/25/17
to
> Didn't notice that until just now.
to be in the manpages instead of pestering all the forums and IRC lists
on the planet and still not getting a meaningful answer that works
because everyone is looking at the same, and WRONG manpage.
We scooped that stuff up out of the trench behind the bovines in the
cowbarn, daily. Or did 78 years ago when I was a child on an Iowa, USA
farm.
Thanks again Greg.
Pascal Hambourg
Sep 25, 2017, 1:30:05 PM9/25/17
to
Le 25/09/2017 à 18:00, Gene Heskett a écrit :
>>
>> Also, there's http://manpages.debian.org/interfaces
>>
>> In fact, the man page outright *lies* and says they're synonyms.
No it doesn't. It says that "allow-auto" (not "allow-hotplug") and
>>
>> Also, there's http://manpages.debian.org/interfaces
>>
>> In fact, the man page outright *lies* and says they're synonyms.
"auto" are synonyms, which is correct AFAICS.
Jimmy Johnson
Sep 25, 2017, 1:30:05 PM9/25/17
to
As you have pointed out, things have changed, have you ran #ifconfig -a
to get the name of your device? I'm thinking the name you are using is
not the same name the system is using and why hotplug is not working?
--
Jimmy Johnson
Debian Stretch - KDE Plasma 5.8.6 - Intel i7-3540M - EXT4 at sda6
Registered Linux User #380263
Rick Thomas
Sep 26, 2017, 5:40:05 AM9/26/17
to
> On Sep 25, 2017, at 10:25 AM, Jimmy Johnson <field.e...@gmail.com> wrote:
>
> On 09/23/2017 08:56 PM, Rick Thomas wrote:
>> I have two machines (out of a group of ten) that will not bring up their ethernet interface at boot time if the interfaces is of type �allow-hotplug�. When I change that to �auto� the interface comes up at boot with no problem�
>> The remaining eight machines have no problem with allow-hotplug. (which is the default as setup by the d-i)
>> It does not seem to correlate to kernel version. The two �auto� machines are running 4.12 and 4.9; The �allow-hotplug� machines are running anything between 3.16 and 4.12.
>> Nor does it seem to correlate with static vs dhcp. The two �auto� machines are both using dhcp. The �allow-hotplug� machines are using a mixture of static and dhcp.
>> Anybody have a clue as to what�s going on?
>> Thanks in advance�
>> Rick
>
> Hi, Rick
>
> As you have pointed out, things have changed, have you ran #ifconfig -a
> to get the name of your device? I'm thinking the name you are using is not the same name the system is using and why hotplug is not working?
root@macpro:~# ifconfig -a
enP1p3s15f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.148 netmask 255.255.240.0 broadcast 192.168.15.255
inet6 fe80::211:24ff:fe38:1048 prefixlen 64 scopeid 0x20<link>
ether 00:11:24:38:10:48 txqueuelen 1000 (Ethernet)
RX packets 4450 bytes 4876801 (4.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2649 bytes 246222 (240.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
So the interface name is “enP1p3s15f0"
I haven’t done anything to change the name from the original one assigned by the installer.
Here’s what’s in /e/n/interfaces:
root@macpro:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto enP1p3s15f0
iface enP1p3s15f0 net dhcp
I had to change “allow-hotplug” to “auto” to get it to come up on reboot:
root@macpro:~# diff /etc/network/interfaces.ORIG /etc/network/interfaces
11c11
< allow-hotplug enP1p3s15f0
---
> auto enP1p3s15f0
If there’s some place that’s mistakenly expecting a name like “eth0”, where might it be located?
> --
> Jimmy Johnson
Rick
Linux user since 1987
Pascal Hambourg
Sep 26, 2017, 8:00:05 AM9/26/17
to
Le 26/09/2017 à 11:38, Rick Thomas a écrit :
>
> # The primary network interface
> auto enP1p3s15f0
> iface enP1p3s15f0 net dhcp
^^^
>
> # The primary network interface
> auto enP1p3s15f0
> iface enP1p3s15f0 net dhcp
It should be "inet". Typo in your post or in the actual file ?
Greg Wooledge
Sep 26, 2017, 9:30:07 AM9/26/17
to
On Tue, Sep 26, 2017 at 02:38:37AM -0700, Rick Thomas wrote:
> # The primary network interface
> auto enP1p3s15f0
> iface enP1p3s15f0 net dhcp
As Pascal noted, the word before "dhcp" should be "inet".
> # The primary network interface
> auto enP1p3s15f0
> iface enP1p3s15f0 net dhcp
> I had to change “allow-hotplug” to “auto” to get it to come up on reboot:
> root@macpro:~# diff /etc/network/interfaces.ORIG /etc/network/interfaces
> 11c11
> < allow-hotplug enP1p3s15f0
> ---
> > auto enP1p3s15f0
> If there’s some place that’s mistakenly expecting a name like “eth0”, where might it be located?
or a third party package.
Gene Heskett
Sep 26, 2017, 11:30:05 AM9/26/17
to
On Tuesday 26 September 2017 09:21:47 Greg Wooledge wrote:
> On Tue, Sep 26, 2017 at 02:38:37AM -0700, Rick Thomas wrote:
> > # The primary network interface
> > auto enP1p3s15f0
> > iface enP1p3s15f0 net dhcp
>
> As Pascal noted, the word before "dhcp" should be "inet".
>
No Greg, the word "net" s/b "inet".
> On Tue, Sep 26, 2017 at 02:38:37AM -0700, Rick Thomas wrote:
> > # The primary network interface
> > auto enP1p3s15f0
> > iface enP1p3s15f0 net dhcp
>
> As Pascal noted, the word before "dhcp" should be "inet".
>
> > I had to change “allow-hotplug” to “auto” to get it to come up on
> > reboot: root@macpro:~# diff /etc/network/interfaces.ORIG
> > /etc/network/interfaces 11c11
> > < allow-hotplug enP1p3s15f0
> > ---
> >
> > > auto enP1p3s15f0
>
> Looks good.
>
> > If there’s some place that’s mistakenly expecting a name like
> > “eth0”, where might it be located?
>
> A locally created script (especially one that does firewall stuff),
> or a third party package.
Rick Thomas
Sep 26, 2017, 5:30:07 PM9/26/17
to
On Sep 26, 2017, at 6:21 AM, Greg Wooledge <woo...@eeg.ccf.org> wrote:
> On Tue, Sep 26, 2017 at 02:38:37AM -0700, Rick Thomas wrote:
>> # The primary network interface
>> auto enP1p3s15f0
>> iface enP1p3s15f0 net dhcp
>
> As Pascal noted, the word before “dhcp" should be "inet".
And, given that the “i” is missing in both versions of the interfaces file, why does “auto” work and “allow-hotplug” not work?
>
>> I had to change “allow-hotplug” to “auto” to get it to come up on reboot:
>> root@macpro:~# diff /etc/network/interfaces.ORIG /etc/network/interfaces
>> 11c11
>> < allow-hotplug enP1p3s15f0
>> ---
>>> auto enP1p3s15f0
>
> Looks good.
>
>> If there’s some place that’s mistakenly expecting a name like “eth0”, where might it be located?
>
> A locally created script (especially one that does firewall stuff),
> or a third party package.
Rick
Jimmy Johnson
Sep 26, 2017, 7:10:06 PM9/26/17
to
setup the internet or at lest it will try.
Below is my Stretch interfaces config.
-------------------------------------------
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eno1
iface eno1 inet dhcp
# This is an autoconfigured IPv6 interface
iface eno1 inet6 auto
-----------------------------------------
Good Luck,
0 new messages