Debian Bug report logs - #403706
(sometimes?) fails to bring up interfaces on bootup by default

Package: release-notes; Maintainer for release-notes is Debian Documentation Team <debian-doc@lists.debian.org>;

Reported by: Bastian Venthur <venthur@debian.org>

Date: Tue, 19 Dec 2006 08:03:01 UTC

Severity: important

Done: Steve Langasek <vorlon@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, venthur@debian.org, Anthony Towns <ajt@debian.org>:
Bug#403706; Package ifupdown. Full text and rfc822 format available.

Acknowledgement sent to Bastian Venthur <venthur@debian.org>:
New Bug report received and forwarded. Copy sent to venthur@debian.org, Anthony Towns <ajt@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Bastian Venthur <venthur@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: (sometimes?) fails to bring up interfaces on bootup by default
Date: Tue, 19 Dec 2006 08:51:28 +0100
Package: ifupdown
Version: 0.6.8
Severity: critical
Tags: patch

Hi ifupdown-Maintainer,

I've installed a recent Debian/Testing on two different boxes and on a
virtual qemu-box and the following problem appeard on all of them: After
booting the system the nentwork inteface is not brought up correctly
which makes this installation (in fact the whole system) unusable for
reomote-only installations.

The problem seems to be the following line in /etc/network/interfaces:

	allow-hotplug eth0

Issuing an 

	sudo ifup -a 

does not do anything.

After changing the line to

	auto eth0

the problem seems to be fixed. Please note that I'm not talking about
some heavyly customized installations but rather about default
installations of an up-to-date Debian/Testing.

I've mentioned the problem on d-devel and d-user-german and it looks
that the problem (as well as the proposed solution) is quite common.


Cheers,

Bastian


-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages ifupdown depends on:
ii  debconf [debconf-2.0]        1.5.8       Debian configuration management sy
ii  libc6                        2.3.6.ds1-8 GNU C Library: Shared libraries
ii  lsb-base                     3.1-22      Linux Standard Base 3.1 init scrip
ii  net-tools                    1.60-17     The NET-3 networking toolkit

ifupdown recommends no packages.

-- debconf information excluded



Tags removed: patch Request was from Javier Fernández-Sanguino Peña <jfs@computer.org> to control@bugs.debian.org. Full text and rfc822 format available.

Message sent on to Bastian Venthur <venthur@debian.org>:
Bug#403706. Full text and rfc822 format available.

Message #10 received at 403706-submitter@bugs.debian.org (full text, mbox):

From: Javier Fernández-Sanguino Peña <jfs@computer.org>
To: 403706-submitter@bugs.debian.org
Cc: control@bugs.debian.org
Subject: No patch
Date: Tue, 19 Dec 2006 11:16:51 +0100
[Message part 1 (text/plain, inline)]
tags 403706 - patch
thanks

There is no patch for this bug, at least not in the bug submission.

Regards

Javier
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Anthony Towns <ajt@debian.org>:
Bug#403706; Package ifupdown. Full text and rfc822 format available.

Acknowledgement sent to "Alex Owen" <r.alex.owen@gmail.com>:
Extra info received and forwarded to list. Copy sent to Anthony Towns <ajt@debian.org>. Full text and rfc822 format available.

Message #15 received at 403706@bugs.debian.org (full text, mbox):

From: "Alex Owen" <r.alex.owen@gmail.com>
To: 403706@bugs.debian.org
Subject: Probably a d-i issue
Date: Tue, 19 Dec 2006 11:56:32 +0000
This is probably a debian-installer issue?

but is affects udev/hotplug/initscripts also!

Regards
Alex Owen



Information forwarded to debian-bugs-dist@lists.debian.org, Anthony Towns <ajt@debian.org>:
Bug#403706; Package ifupdown. Full text and rfc822 format available.

Acknowledgement sent to "Alex Owen" <r.alex.owen@gmail.com>:
Extra info received and forwarded to list. Copy sent to Anthony Towns <ajt@debian.org>. Full text and rfc822 format available.

Message #20 received at 403706@bugs.debian.org (full text, mbox):

From: "Alex Owen" <r.alex.owen@gmail.com>
To: 403706@bugs.debian.org
Subject: network not up after /etc/rcS.d/S40networking completes
Date: Tue, 19 Dec 2006 12:39:17 +0000
reassign 403706 netcfg
thanks

This bug/issue seems to be due (in part) to the code in
d-i/trunk/packages/netcfg/[static.c|dhcp.c]
---8<---
       if (!iface_is_hotpluggable(iface) && !find_in_stab(iface))
           fprintf(fp, "auto %s\n", iface);
       else
           fprintf(fp, "allow-hotplug %s\n", iface);
---8<---


It seems that the kernel now sees everything (or almost everything) as
hotplugable.
Thus my builting network card on my server is now "hotplugable" which
means that is is initiallised asyncronosly at bootup.

The old behavious was to have the "auto eth0" stanza in
/etc/network/interfaces... then I knew that I would have a network (or
an error message) at the end of /etc/rcS.d/S40networking on boot.

Now I may or may not have a network when /etc/rcS.d/S40networking finishes...

This is a serious issue!
It may be that I'm just ignorant... in that case can someone please
point me to the correct docs so I may educate myself!

If i'm not being ignorant then we either:

[1] have to modify the netcfg code to ask at install time if we want
to have an "auto" rather than "hotplug" primary interface and act
accordingly,
or
[2] we need to add some code to /etc/rcS.d/S40networking
(/etc/init.d/networking) to wait till the primary interface has come
online.

Regards
Alex Owen



Bug reassigned from package `ifupdown' to `netcfg'. Request was from "Alex Owen" <r.alex.owen@gmail.com> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `normal' from `critical' Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #29 received at 403706@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 403706@bugs.debian.org
Cc: Alex Owen <r.alex.owen@gmail.com>, Bastian Venthur <venthur@debian.org>, ifupdown@packages.debian.org
Subject: allow-hotplug and udev
Date: Tue, 19 Dec 2006 16:19:29 -0500
[Message part 1 (text/plain, inline)]
If this is actually a d-i/netcfg bug, then one approach would be to
remove net-hotplug.sh (or its udev rule) from hw-detect. This script
detects net device additions, and registers the devices as hotpluggable.
With udev I think that all network devices come in this way, be they pci
cards or usb nics. Perhaps it would be possible to modify the udev rule
to exclude pci cards somehow, I don't know. (Then too, some systems do
have hotpluggable pci cards.)

It's not particularly clear to me that this is a d-i bug though. If
ifupdown/udev doesn't behave correctly/reliably for allow-hotplug
interfaces that are cold-plugged at system boot, shouldn't it be fixed?
We certianly have users with those sorts of interfaces, after all.

I was able to reproduce the behabior described in this bug where the
interface doesn't come up at all, and identify at least two separate
scenarios where udev fails to bring it up. I've filed two bugs on udev
for those scenarios; one invoves a long root fsck and a timeout, while
the other can be reproduced by simply hard power cycling a box that has
the allow-hotplug setting. I feel that this latter bug is indeed release
critical, and is probably the one that the contributors to this bug
report ran into.

That leaves the other note from this bug, that:
> Thus my builtin network card on my server is now "hotplugable" which
> means that is is initiallised asyncronosly at bootup.

That's true, and normally it will be initialised shortly after
/etc/init.d/networking brings up the lo interface, but it could take
arbitrarily long.

I can see that causing some potential problems for certian services that
expect the network to be up after /etc/init.d/networking, but it's not
clear to me that those problems are acutally release critical. I've
downgraded this bug for now, but it could be upgraded if there are
actual concrete examples of this asynchronycity causing problems.

[Hmm, one approach would be to make net.agent, when it calls ifup,
register that interface in some file somewhere. Then when
/etc/init.d/networking starts up, it could read that file and get a list
of interfaces that were (mostly?) cold-plugged, and it could wait until
all those interfaces finish coming up before returning.]

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #34 received at 403706@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 403706@bugs.debian.org
Cc: Alex Owen <r.alex.owen@gmail.com>, Bastian Venthur <venthur@debian.org>, ifupdown@packages.debian.org
Subject: Re: allow-hotplug and udev
Date: Tue, 19 Dec 2006 17:00:06 -0500
[Message part 1 (text/plain, inline)]
Another option would be to make netcfg always add an auto line, so it
has:

allow-hotplug eth0
auto eth0

This avoids any problems caused by udev running ifup too early or too
late, for interfaces that arn't really that hotpluggable, or that are
cold-plugged. /etc/init.d/networking will (generally) start the
interface first, then udev will try to start it again, which is
harmless, and does not even generate any ugly messages. In some rare
cases, udev might manage to start the interface first, if so,
/etc/init.d/networking will output "ifup: interface eth0 already configured"

If the interface is an actual hotpluggable interface, such as a USB
nic, and it's not present at boot, then /etc/init.d/networking might
complain: "eth0: ERROR file getting interface flags: No such device".
In any case, when it gets plugged in, udev will handle it as usual.

The only downside seems to be the potential for these error messages.
The upside: No need to worry about obscure races in udev breakin
networking; no need to worry about asynchronycity issues for the primary
interface.

Here's a patch to netcfg, to do that:

Index: debian/changelog
===================================================================
--- debian/changelog	(revision 43410)
+++ debian/changelog	(working copy)
@@ -1,3 +1,14 @@
+netcfg (1.33) UNRELEASED; urgency=low
+
+  * Add "auto" lines even for hotpluggable interfaces. This can result in
+    udev trying to ifup an interface that /etc/network/interfaces has already
+    upped, but it avoids problems with bugs and races in udev's handling of
+    coldplugged primary network interfaces, and it ensures that the primary
+    interface is always up by the time /etc/network/interfaces completes.
+    Closes: #403706
+
+ -- Joey Hess <joeyh@debian.org>  Tue, 19 Dec 2006 16:57:54 -0500
+
 netcfg (1.32) unstable; urgency=low
 
   [ Colin Watson ]
Index: dhcp.c
===================================================================
--- dhcp.c	(revision 43410)
+++ dhcp.c	(working copy)
@@ -35,9 +35,9 @@
     
     if ((fp = file_open(INTERFACES_FILE, "a"))) {
         fprintf(fp, "\n# The primary network interface\n");
-        if (!iface_is_hotpluggable(iface) && !find_in_stab(iface))
+        if (!find_in_stab(iface))
             fprintf(fp, "auto %s\n", iface);
-        else
+        if (iface_is_hotpluggable(iface))
             fprintf(fp, "allow-hotplug %s\n", iface);
         fprintf(fp, "iface %s inet dhcp\n", iface);
         if (dhostname) {
Index: static.c
===================================================================
--- static.c	(revision 43410)
+++ static.c	(working copy)
@@ -178,9 +178,9 @@
     
     if ((fp = file_open(INTERFACES_FILE, "a"))) {
         fprintf(fp, "\n# The primary network interface\n");
-        if (!iface_is_hotpluggable(interface) && !find_in_stab(interface))
+        if (!find_in_stab(interface))
             fprintf(fp, "auto %s\n", interface);
-        else
+        if (iface_is_hotpluggable(interface))
             fprintf(fp, "allow-hotplug %s\n", interface);
         fprintf(fp, "iface %s inet static\n", interface);
         fprintf(fp, "\taddress %s\n", inet_ntop (AF_INET, &ipaddress, ptr1, sizeof (ptr1)));

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Tags added: patch Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `important' from `normal' Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #43 received at 403706@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 403706@bugs.debian.org
Cc: Alex Owen <r.alex.owen@gmail.com>, Bastian Venthur <venthur@debian.org>, ifupdown@packages.debian.org
Subject: Re: allow-hotplug and udev
Date: Tue, 19 Dec 2006 17:09:51 -0500
[Message part 1 (text/plain, inline)]
Joey Hess wrote:
> I can see that causing some potential problems for certian services that
> expect the network to be up after /etc/init.d/networking, but it's not
> clear to me that those problems are acutally release critical. I've
> downgraded this bug for now, but it could be upgraded if there are
> actual concrete examples of this asynchronycity causing problems.

I've changed my mind, it's probably best to leave this RC. There seems
to be no end of potential for a slow dhcp response to delay udev's ifup
of an interface and for this to break services that are started later.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Severity set to `critical' from `important' Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #50 received at 403706@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Bastian Venthur <venthur@debian.org>, 403706@bugs.debian.org
Subject: Re: Bug#403706: (sometimes?) fails to bring up interfaces on bootup by default
Date: Wed, 20 Dec 2006 01:36:14 -0800
On Tue, Dec 19, 2006 at 08:51:28AM +0100, Bastian Venthur wrote:
> Hi ifupdown-Maintainer,

> I've installed a recent Debian/Testing on two different boxes and on a
> virtual qemu-box and the following problem appeard on all of them: After
> booting the system the nentwork inteface is not brought up correctly
> which makes this installation (in fact the whole system) unusable for
> reomote-only installations.

> The problem seems to be the following line in /etc/network/interfaces:

> 	allow-hotplug eth0

> Issuing an 

> 	sudo ifup -a 

> does not do anything.

> After changing the line to

> 	auto eth0

> the problem seems to be fixed. Please note that I'm not talking about
> some heavyly customized installations but rather about default
> installations of an up-to-date Debian/Testing.

> I've mentioned the problem on d-devel and d-user-german and it looks
> that the problem (as well as the proposed solution) is quite common.

But isn't this a regression in the installer for using an allow-hotplug
stanza, not in ifupdown?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to Frans Pop <elendil@planet.nl>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #55 received at 403706@bugs.debian.org (full text, mbox):

From: Frans Pop <elendil@planet.nl>
To: 403706@bugs.debian.org
Subject: Re: Bug#403706: allow-hotplug and udev
Date: Sat, 30 Dec 2006 03:02:46 +0100
[Message part 1 (text/plain, inline)]
Late reply, sorry.

I'm not convinced this really is RC, especially not if the most severe 
issue can be fixed in udev. For one, it is fairly easy to document and 
fix by an admin based on that documentation.
It's only a real problem for remotely admined boxes, but you kind of do 
expect admins of those to actually read errata and Release Notes.

Personally I would like it very much if we could be more conservative in 
setting allow-hotplug. Use auto more for regular on-board or PCI NICs and 
by default use allow-hotplug only for real removable devices (USB, 
PCMCIA). However, detecting that seems problematic.

I can't really think of a solution that would allow to select hotplug/auto 
that is not very ugly (except maybe for a boot parameter, but that 
depends on people reading documentation again).

On Tuesday 19 December 2006 23:00, Joey Hess wrote:
> Another option would be to make netcfg always add an auto line, so it
> has:
> allow-hotplug eth0
> auto eth0

My first reaction on this solution was the same as MD's comment on IRC: 
it's a hack and such a config is probably undefined. Setting this config 
may, because of that, result in latent bugs in all systems installed 
using d-i that could trigger at any time in the future by changes in 
ifupdown or init scripts or whatever.

Cheers,
FJP
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #60 received at 403706@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 403706@bugs.debian.org
Subject: Re: Re: Bug#403706: allow-hotplug and udev
Date: Thu, 4 Jan 2007 04:05:10 -0500
[Message part 1 (text/plain, inline)]
> I'm not convinced this really is RC, especially not if the most severe
> issue can be fixed in udev. For one, it is fairly easy to document and
> fix by an admin based on that documentation.

IMHO, it depends on whether any remaining failure mode can make it impossible
to get into the box and fix the problem.

BTW, in this article, a nslu2 was installed with d-i, worked fine for a while,
and then failed to come up on the network on boot.. possibly because of the
udev race while fscking, though it's hard to tell:
http://www.smallnetbuilder.com/content/view/29774/77/1/4/
Note the pain that ensued, also note that the naive fix of reinstalling
the box wouldn't have worked.

> My first reaction on this solution was the same as MD's comment on IRC:
> it's a hack and such a config is probably undefined.

It seems perfectly well defined to me.

auto = bring up the interface automatically on boot if possible
allow-hotplug = bring up the interface if it's hotplugged

I don't see any reason why these two can't be combined, ifupdown behaves
perfectly reasonably when the union of the two behaviors is requested.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to Frans Pop <elendil@planet.nl>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #65 received at 403706@bugs.debian.org (full text, mbox):

From: Frans Pop <elendil@planet.nl>
To: 403706@bugs.debian.org
Subject: Re: Bug#403706: allow-hotplug and udev
Date: Thu, 04 Jan 2007 17:34:34 +0100
[Message part 1 (text/plain, inline)]
On Tuesday 19 December 2006 23:00, Joey Hess wrote:
> Here's a patch to netcfg, to do that:

I'd prefer to apply the patch below instead. Although it has two lines to
print an "auto <iface>" line, I feel that that is more in line with the
fact that it is a (hopefully temporary) workaround.
I also feel we should document inside the file why this weird configuration
is necessary.

Index: dhcp.c
===================================================================
--- dhcp.c      (revision 43836)
+++ dhcp.c      (working copy)
@@ -37,8 +37,15 @@
         fprintf(fp, "\n# The primary network interface\n");
         if (!iface_is_hotpluggable(iface) && !find_in_stab(iface))
             fprintf(fp, "auto %s\n", iface);
-        else
+        else {
+            fprintf(fp, "# Because to potential problems bringing up hotpluggable interfaces\n");
+            fprintf(fp, "# both an 'auto' and 'allow-hotplug' are used.\n");
+            fprintf(fp, "# See bugs #403706 and #403805 for further information.\n");
+            fprintf(fp, "# If %s is an interface that does not really need hotplugging, you\n", iface);
+            fprintf(fp, "# can safely remove the allow-hotplug line and these comments.\n");
+            fprintf(fp, "auto %s\n", iface);
             fprintf(fp, "allow-hotplug %s\n", iface);
+        }
         fprintf(fp, "iface %s inet dhcp\n", iface);
         if (dhostname) {
             fprintf(fp, "\thostname %s\n", dhostname);
Index: static.c
===================================================================
--- static.c    (revision 43836)
+++ static.c    (working copy)
@@ -180,8 +180,15 @@
         fprintf(fp, "\n# The primary network interface\n");
         if (!iface_is_hotpluggable(interface) && !find_in_stab(interface))
             fprintf(fp, "auto %s\n", interface);
-        else
-            fprintf(fp, "allow-hotplug %s\n", interface);
+        else {
+            fprintf(fp, "# Because to potential problems bringing up hotpluggable interfaces\n");
+            fprintf(fp, "# both an 'auto' and 'allow-hotplug' are used.\n");
+            fprintf(fp, "# See bugs #403706 and #403805 for further information.\n");
+            fprintf(fp, "# If %s is an interface that does not really need hotplugging, you\n", iface);
+            fprintf(fp, "# can safely remove the allow-hotplug line and these comments.\n");
+            fprintf(fp, "auto %s\n", iface);
+            fprintf(fp, "allow-hotplug %s\n", iface);
+        }
         fprintf(fp, "iface %s inet static\n", interface);
         fprintf(fp, "\taddress %s\n", inet_ntop (AF_INET, &ipaddress, ptr1, sizeof (ptr1)));
         fprintf(fp, "\tnetmask %s\n", inet_ntop (AF_INET, &netmask, ptr1, sizeof (ptr1)));
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #70 received at 403706@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Frans Pop <elendil@planet.nl>, 403706@bugs.debian.org
Subject: Re: Bug#403706: allow-hotplug and udev
Date: Thu, 4 Jan 2007 13:24:26 -0800
On Thu, Jan 04, 2007 at 05:34:34PM +0100, Frans Pop wrote:
> +        else {
> +            fprintf(fp, "# Because to potential problems bringing up hotpluggable interfaces\n");

s/Because to/Because of/

> +            fprintf(fp, "# both an 'auto' and 'allow-hotplug' are used.\n");
> +            fprintf(fp, "# See bugs #403706 and #403805 for further information.\n");
> +            fprintf(fp, "# If %s is an interface that does not really need hotplugging, you\n", iface);
> +            fprintf(fp, "# can safely remove the allow-hotplug line and these comments.\n");
> +            fprintf(fp, "auto %s\n", iface);
>              fprintf(fp, "allow-hotplug %s\n", iface);
> +        }

If you're going to reference bug numbers, perhaps you should specify that
they're Debian bugs, for clarity?

Also, how is the user supposed to know if an interface "really needs"
hotplugging?  Only those who have followed kernel development somewhat
closely understand that most devices are now brought on-line asynchronously.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to "Alexander E. Patrakov" <patrakov@ums.usu.ru>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #75 received at 403706@bugs.debian.org (full text, mbox):

From: "Alexander E. Patrakov" <patrakov@ums.usu.ru>
To: linux-hotplug-devel@lists.sourceforge.net
Cc: 403706@bugs.debian.org, Marco d'Itri <md@Linux.IT>
Subject: Udev sometimes forgets to RUN a program when renaming network interface
Date: Fri, 05 Jan 2007 17:30:00 +0500
To Marco d'Itri: this testcase may explain at least a fraction of Debian bug 
  #403706 (because in Debian ifup is run, essentially, from udev rules), 
that's why the CC. Udev version is 0.100-2.3. Also reproducible with 0.103-1.

To repeat the steps below, you need a Debian Etch installation CD, and 
VMware Server. QEMU may be able to reproduce this too, but it is untested.

1) Create a virtual machine with two network cards. The first of them should 
look into a custom empty virtual network (e.g., /dev/vmnet2 - the intention 
is to simulate a useless network card looking into nowhere). The other card 
should use host-only or NAT networking (the intention is that it gets its IP 
address via DHCP).

2) Install Debian Etch into this virtual machine from the CD. Select eth1 as 
the primary network interface. Do not update the system, because this would 
trigger the update-initramfs script and break the testcase! (the testcase 
relies on the fact that udev not in initramfs has to swap the two network 
interfaces at step 6)

This installation procedure creates the following files:

/etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth1
iface eth1 inet dhcp

/etc/udev/rules.d/z25_persistent-net.rules:
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0c:29:d8:39:6e", 
NAME="eth1"

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0c:29:d8:39:64", 
NAME="eth0"

3) Create the file /etc/udev/rules.d/z49_debug.rules with the following 
contents:

SUBSYSTEM=="net", ACTION=="add", RUN+="/bin/sh -c 'echo FOUND NETWORK 
INTERFACE %k >/dev/console'"

4) Reboot the system, watch how it prints that it found eth1, eth0 and lo. 
So far so good. Note that the renaming rules above are not really triggered, 
because these two network cards are PCI cards served by the same module.

5) Now edit /etc/network/interfaces so that it mentions eth0 instead of 
eth1, and edit /etc/udev/rules.d/z25_persistent-net.rules by swapping eth0 
and eth1 (so that 00:0c:29:d8:39:6e becomes eth0 and 00:0c:29:d8:39:64 
becomes eth1). The intention is, as you may have guessed, is to swap the 
names, so that the used card becomes eth0, and the useless one is eth1. The 
consequence is that the renaming rules become essential.

6) Reboot. This time it prints the message:

udevd-event[2669]: rename_netif: error changing net interface name 
eth1_rename to eth0: No such device

(but "ifconfig -a" shows that the 00:0c:29:d8:39:6e card does become eth0)

Then it prints a message that it found eth1 and lo, and no message about 
eth0. And of course, the network is not up, because udev forgot to run 
net.agent for the new eth0. Bug!

While it took us some special preparations to trigger this bug with two 
identical network cards, I guess that this will happen by itself with 50% 
probability if the network cards are not identical, due to random module 
loading order.

7) This time, repeat step (5), using names "used" and "unused" for the two 
interfaces, reboot and watch how udev finds the "used", "unused" and "lo" 
interfaces.

-- 
Alexander E. Patrakov



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to Andrey Borzenkov <arvidjaar@mail.ru>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #80 received at 403706@bugs.debian.org (full text, mbox):

From: Andrey Borzenkov <arvidjaar@mail.ru>
To: linux-hotplug-devel@lists.sourceforge.net
Cc: "Alexander E. Patrakov" <patrakov@ums.usu.ru>, 403706@bugs.debian.org, Marco d'Itri <md@linux.it>
Subject: Re: Udev sometimes forgets to RUN a program when renaming network interface
Date: Fri, 5 Jan 2007 15:50:35 +0300
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 05 January 2007 15:30, Alexander E. Patrakov wrote:
[...]
>
> 5) Now edit /etc/network/interfaces so that it mentions eth0 instead of
> eth1, and edit /etc/udev/rules.d/z25_persistent-net.rules by swapping eth0
> and eth1 (so that 00:0c:29:d8:39:6e becomes eth0 and 00:0c:29:d8:39:64
> becomes eth1). The intention is, as you may have guessed, is to swap the
> names, so that the used card becomes eth0, and the useless one is eth1. The
> consequence is that the renaming rules become essential.
>
> 6) Reboot. This time it prints the message:
>
> udevd-event[2669]: rename_netif: error changing net interface name
> eth1_rename to eth0: No such device
>
> (but "ifconfig -a" shows that the 00:0c:29:d8:39:6e card does become eth0)
>

I confirm this for Mandriva cooker with udev 103 and kernel 2.6.20-rc3. The 
two interfaces are eth0 (PCI e100 normally unused) and eth1 (built-in PCMCIA 
wireless, primary interface). Effectively the latter is found first by 
coldplugging then the former is loaded by network startup script. The 
interface eth1 gets renamed and comes up just fine; I have not tried eth0. 
Both have DHCP.

> Then it prints a message that it found eth1 and lo, and no message about
> eth0. And of course, the network is not up, because udev forgot to run
> net.agent for the new eth0. Bug!
>

Looks like it; I should have 2 dhclient while I have just one for eth1:

{pts/1}% pgrep -l dh
3491 dhclient
{pts/1}% ps wwwfp 3491
  PID TTY      STAT   TIME COMMAND
 3491 ?        Ss     0:00 
dhclient -1 -q -lf /var/lib/dhcp/dhclient-eth1.leases -pf /var/run/dhclient-eth1.pid -cf /etc/dhclient-eth1.conf 
eth1

As far as I can tell, the bug happens under 2.6.20; I have not seen it under 
2.6.19 or earlier.

I did not get around to debugging this yet.

- -andrey

> While it took us some special preparations to trigger this bug with two
> identical network cards, I guess that this will happen by itself with 50%
> probability if the network cards are not identical, due to random module
> loading order.
>
> 7) This time, repeat step (5), using names "used" and "unused" for the two
> interfaces, reboot and watch how udev finds the "used", "unused" and "lo"
> interfaces.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFnkmgR6LMutpd94wRAmzlAJkBZLkAygg7UENvqYiWsvkGRyim2ACgh4MO
w8+ZnjwTFo4o9k34pATybmo=
=THa9
-----END PGP SIGNATURE-----



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #85 received at 403706@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: "Alexander E. Patrakov" <patrakov@ums.usu.ru>, 403706@bugs.debian.org
Cc: Marco d'Itri <md@Linux.IT>
Subject: Re: Bug#403706: Udev sometimes forgets to RUN a program when renaming network interface
Date: Fri, 5 Jan 2007 15:15:17 -0500
[Message part 1 (text/plain, inline)]
Alexander E. Patrakov wrote:
> Ta Marco d'Itri: this testcase may explain at least a fraction of Debian 
> bug #403706 (because in Debian ifup is run, essentially, from udev 
>   rules), that's why the CC. Udev version is 0.100-2.3. Also reproducible 
> with 0.103-1.

Please file this as a separate bug on udev.   

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #90 received at 403706@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: 403706@bugs.debian.org
Subject: Re: Bug#403706: allow-hotplug and udev
Date: Fri, 5 Jan 2007 15:19:17 -0500
[Message part 1 (text/plain, inline)]
Frans Pop wrote:
> +            fprintf(fp, "# Because to potential problems bringing up hotpluggable interfaces\n");
> +            fprintf(fp, "# both an 'auto' and 'allow-hotplug' are used.\n");
> +            fprintf(fp, "# See bugs #403706 and #403805 for further information.\n");
> +            fprintf(fp, "# If %s is an interface that does not really need hotplugging, you\n", iface);
> +            fprintf(fp, "# can safely remove the allow-hotplug line and these comments.\n");

We're not doing this to work around #403805. That's a udev bug, which
should not ship in etch, since the fix for RC bug #403804 will also fix
it.

I really dislike spamming the interfaces file with this huge and ugly
comment. The release notes are a better place to document this kind of
thing.

I also agree with Steve that nobody is going to understand the
circumstances when it's safe to remove the allow-hotplug. Moreover,
there's no _reason_ to remove the allow-hotplug, since if your interface
is in fact not hotpluggable, it's a total no-op to leave it in.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to "Alexander E. Patrakov" <patrakov@ums.usu.ru>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #95 received at 403706@bugs.debian.org (full text, mbox):

From: "Alexander E. Patrakov" <patrakov@ums.usu.ru>
To: Joey Hess <joeyh@debian.org>
Cc: 403706@bugs.debian.org, Marco d'Itri <md@Linux.IT>
Subject: Re: Bug#403706: Udev sometimes forgets to RUN a program when renaming network interface
Date: Sat, 06 Jan 2007 11:06:17 +0500
Joey Hess wrote:

> Please file this as a separate bug on udev.   

Done, see #405775.

-- 
Alexander E. Patrakov



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#403706; Package netcfg. Full text and rfc822 format available.

Acknowledgement sent to Frans Pop <elendil@planet.nl>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #100 received at 403706@bugs.debian.org (full text, mbox):

From: Frans Pop <elendil@planet.nl>
To: 403706@bugs.debian.org
Subject: Re: Bug#403706: allow-hotplug and udev
Date: Wed, 31 Jan 2007 21:45:15 +0100
[Message part 1 (text/plain, inline)]
reassign 403706 release-notes
severity 403706 important
thanks

On Tuesday 19 December 2006 22:19, Joey Hess wrote:
> It's not particularly clear to me that this is a d-i bug though. If
> ifupdown/udev doesn't behave correctly/reliably for allow-hotplug
> interfaces that are cold-plugged at system boot, shouldn't it be fixed?
> We certianly have users with those sorts of interfaces, after all.

After some discussion on IRC (see below), I've decided to cut the knot and 
downgrade this to a documentation issue rather than a configuration 
issue. I'll add some info about this issue in the errata for D-I and 
reassigning this BR to the Release Notes for documentation there.


<fjp> joeyh: I've not yet uploaded netcfg because of #403706. What is your 
current view on that, given that both udev issues are now fixed?
<joeyh> fjp: It's a time bomb. If we'd prefer not to fix the problem until 
the bomb goes off, I guess that's fine by me
<fjp> vorlon: What is your "RM and generally sane person" opinion about 
#403706? My personal opinion is that it is not a d-i problem and that the 
fix suggested by Joey, though probably not as insane as I first thought, 
is still only a workaround, not a solution.
* joeyh gibbers quietly in his corner about liking to have a working 
network setup
<Sledge> :-)
<vorlon> fjp: um... my opinion is that it should be fixed, somehow, before 
release? :)
<fjp> vorlon: Note that there is no real actual problem. This would just 
be to prevent potential future problems.
<vorlon> oh?
<vorlon> so there's a workaround in place?
<fjp> vorlon: I'd be quite happy to downgrade it and for example mention 
something in the RN.
<fjp> The BRs that triggered this one were solved in udev.
<vorlon> ok
<vorlon> then yeah, downgrading seems ok
<joeyh> the remaining bug is that in random circumstances, the machine's 
primary network interface can take arbitrarily long to come up during 
boot.
<joeyh> In the meantime, daemons are starting
<joeyh> this lay lead to undefined behavior.
<joeyh> It's hard to make any claims about the behavior without auditing a 
bunch of daemons.
<fjp> Yeah, but IMO that is a structural problem in udev/init processing, 
and not a d-i network configuration problem. And after installation it 
becomes a sysadmin responsability.
<vorlon> we'll fix that for lenny by switching to upstart ;)
[Message part 2 (application/pgp-signature, inline)]

Bug reassigned from package `netcfg' to `release-notes'. Request was from Frans Pop <elendil@planet.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `important' from `critical' Request was from Frans Pop <elendil@planet.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Documentation Team <debian-doc@lists.debian.org>:
Bug#403706; Package release-notes. Full text and rfc822 format available.

Acknowledgement sent to Bastian Venthur <venthur@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Documentation Team <debian-doc@lists.debian.org>. Full text and rfc822 format available.

Message #109 received at 403706@bugs.debian.org (full text, mbox):

From: Bastian Venthur <venthur@debian.org>
To: 403706@bugs.debian.org, elendil@planet.nl, submitter-403706@bugs.debian.org
Subject: i think it's still critical
Date: Fri, 02 Mar 2007 13:49:22 +0100
Hi all,

thanks for working so hard on this bug, but please don't bury this bug
into some documentation. I fear nobody will read it there. If we want to
give the user a fair chance to get around this bug, please document it
*in* the config (and in the release notes if you want).

Documented or not, this bug is still grave for remote machines so just
dropping a note in the release notes seems like cheating to me.

Why was this bug downgraded to important? Doesn't this bug meet the
criteria of a critical bug anymore?



Cheers,

Bastian


PS: Please CC me, as the submitter of this bugreport I'm very interested
in the outcome.

-- 
Bastian Venthur                                      http://venthur.de
Debian Developer                                 venthur at debian org




Tags removed: patch Request was from Javier Fernández-Sanguino Peña <jfs@computer.org> to control@bugs.debian.org. (Sun, 18 Mar 2007 19:48:02 GMT) Full text and rfc822 format available.

Reply sent to Steve Langasek <vorlon@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Bastian Venthur <venthur@debian.org>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #116 received at 403706-done@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 403706-done@bugs.debian.org
Subject: Re: (sometimes?) fails to bring up interfaces on bootup by default
Date: Wed, 4 Apr 2007 05:44:21 -0700
Documentation for the problem of asynchronous network initialization has
been committed to the release notes CVS.

As noted in the bug log, the problem that was preventing network interfaces
from being initialized *altogether* on boot has been resolved separately in
udev.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 17 Jun 2007 12:06:19 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 24 07:52:47 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.