"Waiting for network configuration" due to uncommented 'auto' lines in /etc/network/interfaces (historical installer/upgradebug?)

[karaluh]

I get the message on each boot. It is followed by "Waiting up to 60 more seconds for network configuration". After that system continues to boot. When loging to KDE network is up and running. This bug appeared after upgrade to Oneric.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: upstart 1.3-0ubuntu11
ProcVersionSignature: Ubuntu 3.0.0-14.23-generic 3.0.9
Uname: Linux 3.0.0-14-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 1.23-0ubuntu4
Architecture: i386
Date: Tue Dec 6 20:46:27 2011
ProcEnviron:
 LANGUAGE=pl_PL:pl:en_GB:en
 LANG=pl_PL.UTF-8
 SHELL=/bin/bash
SourcePackage: upstart
UpgradeStatus: Upgraded to oneiric on 2011-10-13 (53 days ago)

[Steve Langasek (vorlon)]

please attach the contents of /etc/network/interfaces from the affected system.

[Adam Porter (alphapapa)]

I have encountered the same problem immediately upon rebooting after upgrading to Oneiric. Here is my /etc/network/interfaces file, which is has NOT CHANGED since upgrading from Natty to Oneiric:
----
# 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
address 127.0.0.1
netmask 255.0.0.0

# The primary network interface
auto eth0
iface eth0 inet dhcp
----
Apparently something in the init scripts has changed and is forcing either the "auto eth0" or the dhcp line to wait a LONG time for an address. This is a horrible regression from Natty.

[karaluh (karaluh)]

/etc/network/interfaces

[Steve Langasek (vorlon)]

In both of your cases, is the machine connected to a network at boot time, and when the boot finally continues, is the network working?

Please show the output of this command:

 ls -ld /var/run

[Adam Porter (alphapapa)]

$ ls -ld /var/run
lrwxrwxrwx 1 root root 4 2012-01-07 20:12 /var/run -> /run

The /var/run->/run transition happened correctly when I upgraded.

This happened on my laptop which is not plugged into an Ethernet connection but uses wireless.

After commenting out these lines:

#auto eth0
#iface eth0 inet dhcp

...it booted. I noticed after logging in that NetworkManager had forgotten all of my previously-used wireless networks--another bug, perhaps related? IIRC, before the upgrade I had my default wireless connection set as a system connection in NM.

[Steve Langasek (vorlon)]

On Wed, Jan 11, 2012 at 02:42:41AM -0000, Adam Porter wrote:

> This happened on my laptop which is not plugged into an Ethernet
> connection but uses wireless.

> After commenting out these lines:

> #auto eth0
> #iface eth0 inet dhcp

> ...it booted.

Ok. This is all expected behavior then, except for the 'auto eth0' line
being there in the first place. Did you set this up manually at some point?

> I noticed after logging in that NetworkManager had forgotten all of my
> previously-used wireless networks--another bug, perhaps related?

This would be an unrelated issue.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[karaluh (karaluh)]

> In both of your cases, is the machine connected to a network at boot time, and when the boot finally continues, is the
> network working?

Yes and yes.

> Please show the output of this command:
> ls -ld /var/run

lrwxrwxrwx 1 root root 4 2012-01-14 22:53 /var/run -> /run

[Steve Langasek (vorlon)]

karaluh,

Ok, that all looks correct, so I don't know what's causing this problem. Can you please also attach the otuput of this command:

grep dhclient /var/log/syslog

[karaluh (karaluh)]

> Can you please also attach the otuput of this command:
> grep dhclient /var/log/syslog

No output.

[Steve Langasek (vorlon)]

Is dhclient running on this system, then? (ps awx| grep dhclient)

[karaluh (karaluh)]

 1334 ? S 0:00 /sbin/dhclient -d -4 -sf /usr/lib/NetworkManager/nm-dhcp-client.action -pf /var/run/dhclient-eth2.pid -lf /var/lib/dhcp/dhclient-77ab34ef-20a6-48ce-b3d9-c0bcb29a50bc-eth2.lease -cf /var/run/nm-dhclient-eth2.conf eth2

[Steve Langasek (vorlon)]

Aha. So your /etc/network/interfaces includes an 'auto' line for eth0, but your network device's name now is eth2; so the boot waits for an eth0 that will never be brought up, but in the meantime Network Manager brings up the real network on eth2.

So the fix for this is for you to delete the lines showing 'eth0' in /etc/network/interfaces.

Do you know if these lines were added by the system, or if you set them up manually at some earlier point?

[karaluh (karaluh)]

> So the fix for this is for you to delete the lines showing 'eth0' in /etc/network/interfaces.

Indeed, that solved the issue.

> Do you know if these lines were added by the system, or if you set them up manually at some earlier point?

Hard to say, the system was dist-upgraded several times, so it might be obsolete setting, or maybe I've put those to workaround some networking bug long time ago. The lines were there for as long as I can remember. The eth number mismatch is most likely caused by motherboard upgrade, the previous one had only one ethernet port, current one has two.

[Steve Langasek (vorlon)]

Reassigning to ifupdown. If this is a problem with some default /etc/network/interfaces file as produced by the Ubuntu installer at an earlier date, we should try to track that down and fix up the interfaces files on upgrade if we can.

[Stéphane Graber (stgraber)]

Can you attach the following information?
 - /etc/udev/rules.d/70-persistent-net.rules
 - /var/log/kernel.log
 - /var/log/installer/syslog

Thanks

[karaluh (karaluh)]

/etc/udev/rules.d/70-persistent-net.rules

[karaluh (karaluh)]

/var/log/kern.log

[karaluh (karaluh)]

/var/log/installer/syslog

[Stéphane Graber (stgraber)]

Ok, so these logs show that when you installed your machine, you had a single network interface, called eth0 at the time which was an Nvidia network card with MAC address:
00:0c:76:7e:fe:89

Nowadays, the only piece of nvidia hardware you seem to have is a graphic card. Your network cards now are:
00:17:31:a2:7d:55
00:17:31:a2:7f:ad

You also once plugged a USB network card in this machine.

So based on this, my guess is that you changed hardware in this machine quite significantly, resulting in the change of network cards.
When you installed your machine, it was a AMD Athlon(tm) XP 3200+ but nowadays it's a AMD Athlon(tm) 64 X2 Dual Core Processor 4200+

When you switched hardware, you should have changed /etc/udev/rules.d/70-persistent-net.rules to match the new network hardware so that your new main network card would be assigned eth0 instead of eth1.

The easiest way to do this, is my simply removing all the network interfaces from this file and rebooting, it'll then get populated again with the new values.

If what I'm saying above sounds correct and the problem instead started appearing after the change of hardware, this isn't really a bug, it's actually the expected behaviour when moving an install to new hardware (network device names are linked to the MAC address to avoid them switching order between boots).

[Adam Porter (alphapapa)]

[Another emailed bug comment that never showed up on Launchpad...]

I have encountered this bug on my laptop, which has been running Ubuntu since early 2008 when I got it, and its hardware has never changed.

[Stéphane Graber (stgraber)]

Adam: Can you provide the same information as karaluh then so I can see what's going on in your case and whether you'd need to report this as a separate bug?

[Steve Langasek (vorlon)]

On Sat, Feb 04, 2012 at 09:35:03PM -0000, Stéphane Graber wrote:
> If what I'm saying above sounds correct and the problem instead started
> appearing after the change of hardware, this isn't really a bug, it's
> actually the expected behaviour when moving an install to new hardware
> (network device names are linked to the MAC address to avoid them
> switching order between boots).

I think your analysis is correct, but I don't agree that it's not a bug.
For NM-using systems, I think we really ought to have cleaned up
/etc/network/interfaces on upgrade at some point instead of leaving
redundant interface declarations there that have now caused problems years
later. I'm just not sure it's safe for us to ever do this cleanup of
/e/n/i.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[karaluh (karaluh)]

> I think your analysis is correct, but I don't agree that it's not a bug.

Agreed. You cannot expect that all your users are able to edit configuration files to follow changes in network stack. I consider myself as an experienced user, and I had no idea what caused the delay and how to fix it until I reported the bug. Especialy, since the "bug" wasn't exposed immediately after switching the hardware.

[Stéphane Graber (stgraber)]

Yeah, though in this case I don't see how we could have automatically detected it.

The initial installation (based on kernel versions) was Ubuntu 8.04 which apparently was still writing interface entries in /etc/network/interfaces even when using Network Manager (we don't do that anymore).

Now, to be able to automatically migrate that configuration to its current equivalent (which is to only have the loopback device in /etc/network/interfaces), we'd need to have a way to know whether the user actually meant for eth0 to be in /etc/network/interfaces which is a supported use case currently interpreted by Network Manager as "don't touch this interface and let ifupdown deal with it".

I'm not completely sure as I don't have any desktop install of Ubuntu 8.04 around (end of support) but I guess if we wanted to fix this issue we would have needed to put some magic in the 8.04 => 8.10 and 8.04 => 10.04 upgrader, potentially looking at the installer debconf database or the install log to figure out whether the current /etc/network/interfaces is the result of the installer or the result of someone manually disabling Network Manager.

[Stéphane Graber (stgraber)]

Marking as Won't fix, as unfortunately none of the fixes mentioned before seem to deal with all the cases and they all sound like they might cause significant breakage if they go wrong.

So far what was mentioned is that somewhere between 8.04 and 10.04, we switched from having Network Manager ignore /etc/network/interfaces to having it consider such a declaration as being a "don't touch the interface".

We then introduced in 11.10 some code waiting for all interfaces defined in /etc/network/interfaces (and marked auto) to be up before continuing the boot sequence.

People who would have upgraded their machine all the way from 8.04 with a similar /etc/network/interfaces would still have a working setup on 12.04 as ifupdown would be doing the dhcp query and Network Manager would ignore the interface (agreed, not what we WANT, but still a working setup).

Now the problem is when on top of that, you've changed hardware and eth0 no longer exists. That'd confuse any system, including Network Manager, but it only slows down the boot when combined with an entry in /etc/network/interfaces.

Overall, I think this is enough of a corner case that it's not worth spending time fixing. I scanned other bug reports and it's the only reported case of that bug with currently 4 people marked as affected.

[kabandham (trebauchet1986)]

In my case, commenting out the following lines in /etc/network/interfaces fixed this issue as well as the issue of Network Manager not starting on startup, two issues which had cropped up after an upgrade to ubuntu 12.04....

auto dsl-provider
iface dsl-provider inet ppp
pre-up /sbin/ifconfig eth0 up # line maintained by pppoeconf
provider dsl-provider

auto eth0
iface eth0 inet dhcp

Commenting out the last two lines alone did not help...