FIXED: spurious "Waiting up to 60 more seconds for network configuration" message at startup, but all network devices are up

Thanks for filing this separate bug report. I'm reassigning it to the ifupdown package; interfaces managed by network-manager do not trigger this delay, only those managed in /etc/network/interfaces.

Please show the output of this command:
$ ls -l /run/network

Are you sure you're current with all packages from the final 11.10 release? There were several bugs related to this problem that were fixed shortly before release.

> but seems to be stuck until enter key is pressed.

By this, you mean the message is left on the screen for longer than 60 seconds, and boot only continues if you hit enter? Does boot continue if you hit enter immediately after it appears?

$ ls -l /run/network
totalt 4
-rw-r--r-- 1 root root 6 2011-10-24 21:25 ifstate
-rw-r--r-- 1 root root 0 2011-10-24 21:25 ifup.lo
-rw-r--r-- 1 root root 0 2011-10-24 21:34 ifup.wlan0
drwxr-xr-x 2 root root 40 2011-10-24 21:25 static-network-up-emitted

All packages are updated, but I have upgraded it twice, which unfortunately seems to sometimes cause problems.

/etc/network/interfaces contains:

auto lo
iface lo inet loopback
iface wwan0 inet dhcp

Finally it says "Booting system without full netwirk configuration..." but it is stuck until I press enter. This happened even with the wwan0 line outcommented.

> drwxr-xr-x 2 root root 40 2011-10-24 21:25 static-network-up-emitted

This shows that /etc/network/if-up.d/upstart triggered successfully and the 'static-network-up' event was sent. That should cause /etc/init/rc-sysinit.conf to be triggered very quickly, and result in 'runlevel 2' being emitted, stopping the failsafe job before it ever displays this message.

However, since /etc/init/failsafe.conf only stops on 'runlevel', and *not* as soon as static networking is done, any delays in running /etc/init.d/rcS or any delays bringing up the filesystem could cause this message to still be displayed.

So I'll reassign this to upstart, since I think there's a real bug here in /etc/init/failsafe.conf; either it needs to only wait for the network or it needs to give a clearer message explaining that the filesystem can also be the culprit.

Now, in your case: can you attach /etc/fstab from this system, and the output of 'ls -l /etc/rcS.d' ?

$ ls -l /etc/rcS.d
totalt 4
-rw-r--r-- 1 root root 447 2011-07-14 07:11 README
lrwxrwxrwx 1 root root 19 2011-04-30 20:34 S05keymap.sh -> ../init.d/keymap.sh
lrwxrwxrwx 1 root root 21 2011-03-12 01:12 S13pcmciautils -> ../init.d/pcmciautils
lrwxrwxrwx 1 root root 16 2011-03-12 01:12 S25brltty -> ../init.d/brltty
lrwxrwxrwx 1 root root 18 2011-03-12 01:12 S37apparmor -> ../init.d/apparmor
lrwxrwxrwx 1 root root 20 2011-03-12 01:12 S47lm-sensors -> ../init.d/lm-sensors
lrwxrwxrwx 1 root root 17 2011-03-12 01:12 S55urandom -> ../init.d/urandom
lrwxrwxrwx 1 root root 20 2011-03-12 01:12 S70x11-common -> ../init.d/x11-common
lrwxrwxrwx 1 root root 27 2011-04-30 20:32 S90console-screen.sh -> ../init.d/console-screen.sh

Btw, no difference if the internal modem is disabled.

Ok. Could you please boot with '--verbose' added to the kernel commandline, reboot, and attach /var/log/kern.log and /var/log/boot.log?

Steve, failsafe only starts after filesystem, so its not anything in the mounting of the regular filesystems:

start on filesystem and net-device-up IFACE=lo

The interactions here are difficult to debug because when failsafe stops, nothing clears the message from plymouth, so its entirely possible that failsafe has already exited, but plymouth has not.

I agree that /etc/init.d/rcS seems a likely place where things might be stuck. Perhaps failsafe.conf should 'stop on starting rc-sysinit' ?

Files attached.

Your kernel log shows:
Oct 26 00:14:20 marius-T1005 kernel: [ 29.834585] init: networking pre-start process (882) exited normally
Oct 26 00:14:20 marius-T1005 kernel: [ 29.834792] init: networking state changed from pre-start to spawned
Oct 26 00:14:20 marius-T1005 kernel: [ 29.836729] init: networking main process (883)
Oct 26 00:14:20 marius-T1005 kernel: [ 29.836878] init: networking state changed from spawned to post-start
Oct 26 00:14:20 marius-T1005 kernel: [ 29.837730] init: networking state changed from post-start to running
Oct 26 00:14:20 marius-T1005 kernel: [ 29.838538] init: mountall main process (330) exited normally
Oct 26 00:14:20 marius-T1005 kernel: [ 29.838695] init: mountall goal changed from start to stop
Oct 26 00:14:20 marius-T1005 kernel: [ 29.839091] init: mountall state changed from running to stopping
<snip>
Oct 26 00:14:20 marius-T1005 kernel: [ 29.841294] init: networking main process (883) exited normally
Oct 26 00:14:20 marius-T1005 kernel: [ 29.841447] init: networking goal changed from start to stop
Oct 26 00:14:20 marius-T1005 kernel: [ 29.841902] init: networking state changed from running to stopping
Oct 26 00:14:20 marius-T1005 kernel: [ 29.842391] init: Handling filesystem event
<snip>
Oct 26 00:14:20 marius-T1005 kernel: [ 29.847223] init: failsafe goal changed from stop to start
Oct 26 00:14:20 marius-T1005 kernel: [ 29.847592] init: failsafe state changed from waiting to starting
<snip>
Oct 26 00:14:20 marius-T1005 kernel: [ 29.849781] init: rc-sysinit goal changed from stop to start
Oct 26 00:14:20 marius-T1005 kernel: [ 29.850153] init: rc-sysinit state changed from waiting to starting
<snip>
Oct 26 00:14:20 marius-T1005 kernel: [ 29.852407] init: mountall state changed from stopping to killed
Oct 26 00:14:20 marius-T1005 kernel: [ 29.852810] init: mountall state changed from killed to post-stop
Oct 26 00:14:20 marius-T1005 kernel: [ 29.854145] init: mountall post-stop process (885)
Oct 26 00:14:20 marius-T1005 kernel: [ 29.854314] init: Handling stopping event
Oct 26 00:14:20 marius-T1005 kernel: [ 29.854847] init: networking state changed from stopping to killed
Oct 26 00:14:20 marius-T1005 kernel: [ 29.855591] init: networking state changed from killed to post-stop
Oct 26 00:14:20 marius-T1005 kernel: [ 29.856230] init: networking state changed from post-stop to waiting
<snip>
Oct 26 00:14:20 marius-T1005 kernel: [ 29.867779] init: failsafe state changed from starting to pre-start
Oct 26 00:14:20 marius-T1005 kernel: [ 29.868357] init: failsafe state changed from pre-start to spawned
Oct 26 00:14:20 marius-T1005 kernel: [ 29.869757] init: failsafe main process (890)
Oct 26 00:14:20 marius-T1005 kernel: [ 29.870003] init: failsafe state changed from spawned to post-start
Oct 26 00:14:20 marius-T1005 kernel: [ 29.871893] init: failsafe post-start process (891)
<snip>
Oct 26 00:14:20 marius-T1005 kernel: [ 29.876002] init: Handling starting event
Oct 26 00:14:20 marius-T1005 kernel: [ 29.876681] init: rc-sysinit state changed from starting to pre-start
Oct 26 00:14:20 marius-T1005 kernel: [ 29.877185] init: rc-sysinit state changed from pr...

Your rcS.d shows symlinks for /etc/init.d/keymap.sh and /etc/init.d/console-screen.sh, neither of which is part of a standard Ubuntu install; they come from the packages 'console-common' and 'console-tools' respectively. These may be slowing down the boot, or even interfering with the console configuration by the console-setup package which owns this. (The console-tools package is being obsoleted in both Debian and Ubuntu, but nothing so far is taking care of forcing its removal from disk.)

Could you please run 'sudo rm /etc/rcS.d/S05keymap.sh /etc/rcS.d/S90console-screen.sh' and reboot, and see if that corrects the problem for you?

Clint, I think it's better for failsafe to 'stop on static-network-up'. No need to block rc-sysinit's startup (in case anything goes wrong), but we shouldn't wait for the bottom of rc-sysinit when we know static-network-up is sufficient to cause it to progress.

Note that the final versions of both the console-common and console-tools packages include checks for console-setup, and if present their init scripts are supposed to be no-ops. So if disabling the rcS symlinks for these fixes the problem for you, it's possible that you had removed these packages by hand before that was implemented. (init scripts are left behind on package removal because they're considered configuration files.)

If removing these symlinks *doesn't* fix the problem, the issue may lie in one of the other scripts in /etc/rcS.d that are supposed to be there but are misbehaving nevertheless.

Japp, because of bug #769103 and specifically bug #381517, I had to manually replace one or two of those console setup packages.

I have removed the two files now and will report back at next reboot if the problem has gone away or the keyboard problem has appeared again.

The file removal solved this problem and the shutdown hang (but not bug #879071), but bug #769103 appeared again, so it is not a solution for me...

Before package console-tools is removed, bug #381517 should be fixed. It seems like a quite trivial fix, just adding the parts in /etc/init.d/console-screen.sh (e.g. setting key repeat rate) missing in the init files in the new packages.

Hello Marius, or anyone else affected,

Accepted upstart into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Marius, could you test the upstart package that's been uploaded to oneiric-proposed? This should solve the misleading error message, even if it doesn't solve the slow boot - the slow boot being a bug in one of the other packages mentioned (console-tools, console-common).

Unfortunately I still see the problem with upstart 1.3-0ubuntu10 installed. Maybe you are able to reproduce it by installing the other console package?

Steve,

I updated to the new package, and still seeing the issue as well. Is there anything (logs/diags) you need from me?

thanks
Jeff

Hi Marius,

On Thu, Oct 27, 2011 at 08:59:40AM -0000, Marius Kotsbak wrote:
> Unfortunately I still see the problem with upstart 1.3-0ubuntu10
> installed. Maybe you are able to reproduce it by installing the other
> console package?

The updated package version is 1.3-0ubuntu11. Were you using this version,
or 1.3-0ubuntu10 like you mentioned? The problem is expected to still be
seen with 1.3-0ubuntu10.

To get 1.3-0ubuntu11, you need to follow the steps described in the wiki
page linked from Chris Halse Rogers' message.

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

Jeff, there are different reasons why this message can appear. In your case, it may really be caused by a delay in bringing up the network. The purpose of the upstart SRU is to make sure the message only appears when it should, which is why I've asked Marius to test - since we've already determined that the message is wrong in your case.

If you've tested with upstart 1.3-0ubuntu11 and still see the message at startup, you can file a new bug report and attach your /etc/network/interfaces file.

Okay, it probably had not reached my mirror. Now I have 1.3-0ubuntu11. The shutdown hang disappared,
but I still get the network problem message at boot...

Well, that's certainly unexpected. Can you boot with --verbose again, and attach updated logs?

I tried again now, and then it was just stuck in the boot without the message until I hit the enter key, so maybe the fix is working after all.

Ok, that sounds to me like it's fixed. Marking 'verification-done', thanks.

The "hit the enter key" sounds to me like one of the scripts in /etc/rcS.d is waiting for input when it shouldn't. Opening a task on those packages for tracking.

This bug was fixed in the package upstart - 1.3-0ubuntu11

---------------
upstart (1.3-0ubuntu11) oneiric-proposed; urgency=low

  * debian/conf/failsafe.conf: stop on static-network-up, so that a slow
    runlevel switch doesn't leave a confusing message on screen about
    starting up without networking. LP: #881079.
 -- Steve Langasek <email address hidden> Wed, 26 Oct 2011 12:05:47 -0700

1.3-0ubuntu11 here (11.10 32bit on Virtualbox), I still get the "Waiting up to 60 seconds for network configuration" at boot.

# 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
auto eth0
iface eth0 inet dhcp

Flapane, please show the output of the command 'ifconfig eth0' after boot.

Hello,

I had the bug with 1.3-0ubuntu10 and upgrading upstart to 1.3-0ubuntu11 from oneiric-proposed fixed this bug for me.

Just for information, my /etc/network/interfaces file:
auto lo eth0 eth1 eth2 eth3 eth4
iface lo inet loopback
iface eth0 inet dhcp
iface eth1 inet manual
iface eth2 inet manual
iface eth3 inet manual
iface eth4 inet manual

DistroRelease: Ubuntu 11.10
Architecture: amd64

@Steve:
eth0 Link encap:Ethernet HWaddr 08:00:27:8c:2f:18
          indirizzo inet:10.0.2.15 Bcast:10.0.2.255 Maschera:255.255.255.0
          indirizzo inet6: fe80::a00:27ff:fe8c:2f18/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:15 errors:0 dropped:0 overruns:0 frame:0
          TX packets:80 errors:0 dropped:0 overruns:0 carrier:0
          collisioni:0 txqueuelen:1000
          Byte RX:2158 (2.1 KB) Byte TX:10613 (10.6 KB)

Thanks for your help

Flapane,
well, that output looks perfectly normal. Could you boot with '--verbose' added to your kernel command line, then attach /var/log/kern.log to this bug?

Same problem here. I installed 1.3-0ubuntu11 from oneiric-proposed, but nothing changed.
The delay was caused by the following lines of /etc/network/interfaces:

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

Indeed, the ppp connection relies on the wifi connection, which will be enabled *after*, by Network Mananger.
I don't want to eliminate such lines.
So, I have solved in this way: I removed all the "sleep" lines inside /etc/init/failsafe.conf. Now, everything works.

Now, I ask you programmers: why all these "sleep"s? Why do you want to wait 2 minutes? I think, if the network is not up after few seconds, skip it, and boot up without network. Please tell me if I am wrong.

On Tue, Nov 01, 2011 at 03:37:44PM -0000, ororo wrote:
> auto dsl-provider
> iface dsl-provider inet ppp
> pre-up /sbin/ifconfig wlan0 up # line maintained by pppoeconf
> provider dsl-provider

> Indeed, the ppp connection relies on the wifi connection, which will be
> enabled *after*, by Network Mananger.

> I don't want to eliminate such lines.

You surely do. 'auto' is a directive to ifupdown to try to start the
interface automatically at boot. This clearly will always fail according to
your description, so your /etc/network/interfaces is broken and should be
fixed.

> Now, I ask you programmers: why all these "sleep"s? Why do you want to
> wait 2 minutes? I think, if the network is not up after few seconds,
> skip it, and boot up without network. Please tell me if I am wrong.

You are wrong. The network can take more than a minute to be configured in
some legitimate circumstances, and it's important that we be as safe as
possible in our failsafe. Your bug is that you have a misconfigured system
that is causing you to *hit* the failsafe. A properly configured system
should never hit the timeout.

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

Thank you for your answer. However, there is a reason if want to keep ppp inside /etc/network/interfaces. Indeed, when finally the wlan is started, then the ppp will work, too, without human interference. Otherwise, if I remove the interface ppp, I will have to manually launch "pon dsl-provider"... ok, not a great effort, but I prefer to avoid it.

By the way, I am *sure* that my wlan will never take 1 minute to get up. So, in my opinion, there should be some parameter somewhere allowing the user to de/activate the "2 minutes sleep". Just my opinion.

On Tue, Nov 01, 2011 at 08:39:18PM -0000, ororo wrote:
> Thank you for your answer. However, there is a reason if want to keep
> ppp inside /etc/network/interfaces. Indeed, when finally the wlan is
> started, then the ppp will work, too, without human interference.
> Otherwise, if I remove the interface ppp, I will have to manually launch
> "pon dsl-provider"... ok, not a great effort, but I prefer to avoid it.

I said nothing about removing the interface from /etc/network/interfaces. I
said that the *auto* line is wrong. It was previously non-functional; it is
now actively broken.

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

Vorlon,
I added splash=verbose in my GRUB command line (I hope it's ok, I don't know any other way to increase verbosity)

On Wed, Nov 02, 2011 at 08:28:57AM -0000, Flapane wrote:

> I added splash=verbose in my GRUB command line (I hope it's ok, I don't
> know any other way to increase verbosity)

You need to literally add --verbose to the command line to get the needed
information.

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

Thanks, I added the required parameter: http://i.imgur.com/tmTYq.jpg

Flapane,

Thanks for the log. It shows the information I'm looking for, though I'm confused by exactly what it shows.

Nov 2 16:06:31 virtualbox kernel: [ 25.934277] init: network-interface (eth0) pre-start process (350) exited normally
Nov 2 16:06:31 virtualbox kernel: [ 25.934627] init: network-interface (eth0) state changed from pre-start to spawned
Nov 2 16:06:31 virtualbox kernel: [ 25.934884] init: network-interface (eth0) state changed from spawned to post-start
Nov 2 16:06:31 virtualbox kernel: [ 25.935013] init: network-interface (eth0) state changed from post-start to running

This, combined with your /etc/network/interfaces file, should be enough to cause the system to continue booting without the failsafe job.

However, it's at least clear to me that you have a different issue than the one being addressed in this bug: your error is not a spurious message, but an actual timeout waiting for the network. Please open a new bug report against the ifupdown package, attaching the same files that you've included in this bug to date, and add a comment here with the bug number.

Done it, thanks. Bug #885596

This bug was fixed in the package upstart - 1.3-0ubuntu11

---------------
upstart (1.3-0ubuntu11) oneiric-proposed; urgency=low

  * debian/conf/failsafe.conf: stop on static-network-up, so that a slow
    runlevel switch doesn't leave a confusing message on screen about
    starting up without networking. LP: #881079.
 -- Steve Langasek <email address hidden> Wed, 26 Oct 2011 12:05:47 -0700

I've got the same bug. My upstart package is 1.3-0ubuntu11. The file /etc/network/interfaces contains:

auto lo eth1 eth1:0
iface lo inet loopback
iface eth1 inet static
        address 10.11.12.1
        netmask 255.255.0.0
        gateway 10.11.12.13
iface eth1:0 inet static
        address 192.168.1.254
        netmask 255.255.255.0

And on first boot after upgrade to 11.10 (from 9.10 if it's relevant) I've got no network interfaces eth1* at all - got them after 'mkdir /run/network && /sbin/ifup eth1'. I have no network-manager installed (don't want it to break my network/DNS settings). On next boot I've got all interfaces but still with big delay with those messages and I have not hit any key to boot. Tried to hit but nothing happened - still the same delay. Relevant fragment from my syslog file:

Nov 6 23:42:03 rep avahi-daemon[1217]: Registering new address record for 192.168.1.254 on eth1.IPv4.
Nov 6 23:42:03 rep avahi-daemon[1217]: Registering new address record for 10.11.12.1 on eth1.IPv4.
Nov 6 23:42:03 rep avahi-daemon[1217]: Registering HINFO record with values 'I686'/'LINUX'.
Nov 6 23:42:04 rep dbus[1200]: [system] Activating service name='org.freedesktop.ColorManager' (using servicehelper)
Nov 6 23:42:04 rep avahi-daemon[1217]: Server startup complete. Host name is rep.local. Local service cookie is 214144042.
Nov 6 23:42:05 rep dbus[1200]: [system] Successfully activated service 'org.freedesktop.ColorManager'
Nov 6 23:42:05 rep avahi-daemon[1217]: Service "rep" (/services/udisks.service) successfully established.
Nov 6 23:42:10 rep kernel: [ 26.280020] eth1: no IPv6 routers present
Nov 6 23:44:02 rep ntpdate[1056]: step time server 62.149.0.30 offset -0.267916 sec
Nov 6 23:44:02 rep ntpd[1343]: ntpd 4.2.6p2@1.2194 Fri Sep 2 18:37:15 UTC 2011 (1)
Nov 6 23:44:02 rep ntpd[1345]: proto: precision = 1.020 usec
Nov 6 23:44:02 rep ntpd[1345]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Nov 6 23:44:02 rep ntpd[1345]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Nov 6 23:44:02 rep ntpd[1345]: Listen and drop on 1 v6wildcard :: UDP 123
Nov 6 23:44:02 rep ntpd[1345]: Listen normally on 2 lo 127.0.0.1 UDP 123
Nov 6 23:44:02 rep ntpd[1345]: Listen normally on 3 eth1 10.11.12.1 UDP 123
Nov 6 23:44:02 rep ntpd[1345]: Listen normally on 4 eth1 192.168.1.254 UDP 123
Nov 6 23:44:02 rep ntpd[1345]: Listen normally on 5 eth1 fe80::beae:c5ff:fe8f:3ba6 UDP 123
Nov 6 23:44:02 rep ntpd[1345]: Listen normally on 6 lo ::1 UDP 123
Nov 6 23:44:02 rep kernel: [ 139.271465] type=1400 audit(1320615842.839:8): apparmor="STATUS" operation="profile_replace" name="/sbin/dhclient" pid=1371 comm="apparmor_parser"

i.e. it succesfully got all interfaces up but then hung for 2 minutes with crasy messages. May be it's connected with the fact it is a new /run directory which has symlink /var/run ? I have /var on dedicated partition and I'm not sure if /var is already mounted at that time.
Hope it helps.

On Sun, Nov 06, 2011 at 10:02:15PM -0000, LStranger wrote:
> I've got the same bug. My upstart package is 1.3-0ubuntu11. The file
> /etc/network/interfaces contains:

> auto lo eth1 eth1:0
> iface lo inet loopback
> iface eth1 inet static
> address 10.11.12.1
> netmask 255.255.0.0
> gateway 10.11.12.13
> iface eth1:0 inet static
> address 192.168.1.254
> netmask 255.255.255.0

That's not the same bug. You may be seeing bug #876829.

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

You're wrong about bug #876829 - that bug is about alias that isn't up but if you look into log you'll see it's not the case - all interfaces are up! And I still get the messages despite of EVERY interface is up! Bug isn't fixed in 1.3-0ubuntu11 yet!

Or should I open a new bug with the same subject instead as you've marked this one as fixed? Bug which affects me is exactly:
spurious "Waiting up to 60 more seconds for network configuration" message at startup, but all network devices are up at that moment.

On Wed, Nov 09, 2011 at 03:12:41PM -0000, LStranger wrote:
> You're wrong about bug #876829 - that bug is about alias that isn't up
> but if you look into log you'll see it's not the case - all interfaces
> are up! And I still get the messages despite of EVERY interface is up!

If something is bringing up the eth1:0 interface alias on your system, it's
*not* ifupdown, because alias handling is known to be completely broken with
the ifupdown in oneiric.

And if ifupdown isn't bringing up the alias, then this job can't see it as
up, even if it actually is.

> Bug isn't fixed in 1.3-0ubuntu11 yet!

Yes, it is.

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

Ah, I see... that's strange enough as alias really is up (just as log says, routing table says that also, and my host is available by alias IP from local network) but ifconfig doesn't show it so probably that's the case. Thank you for pointing on that.

I'm getting exactly these symptoms after a test upgrade from vanilla Lucid -> Precise.

Upon reboot, the iface is indeed reachable and I can ssh into it within about 10 seconds but
on the monitor it says "Waiting up to 60 more seconds for network configuration..." error,
and hangs there for a full minute. The /etc/network/interfaces contains all necessary info,
worked perfectly fine in Lucid, and the interface is indeed reachable the whole time:

root@19r8s12:/etc# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 54:52:00:08:ea:ee
          inet addr:192.168.1.181 Bcast:192.168.1.255 Mask:255.255.255.0
          inet6 addr: fe80::5652:ff:fe08:eaee/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:377 errors:0 dropped:0 overruns:0 frame:0
          TX packets:122 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:27347 (27.3 KB) TX bytes:16381 (16.3 KB)
          Interrupt:10 Base address:0x6000

root@19r8s12:/etc# 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).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.181
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1

root@19r8s12:/etc#

Hi Mark, this sounds like a new bug, not the one that caused the original reporter problems. Indeed, you should not see any slow down as soon as eth0 is up.

Can you post the output of

ls -l /etc/network/if-up.d

And

ls -l /run/network

Thanks!

Try this workaround:
sudo sed -i "s|sleep|#sleep|g" /etc/init/failsafe.conf

Hello Clint, going to have to say user error on this one apologies for the false alarm - someone had a line in a script that was changing stuff in /etc/udev which bonked things. Did a fresh Precise reinstall from the mini.iso and no issues, also a Lucid -> Precise upgrade to confirm and indeed... no issues. Apologies for the false alarm!

I am still touched by the problem[1] after upgrading from oneiric to precise, but I have
no any changes on /etc/udev.

Also the workaround in #56 does work for me.

[1], https://bugs.launchpad.net/bugs/835833

Ming, please provide a comment if you intentionally meant to change the bug's status back to confirmed.

I solved by deleting the configuration lines in /etc/network /interfaces that are related to the wireless interface.

Because my interface starts after starting the system.

I'm having this problem with a fresh (post-beta1) Precise install on an EeePC 900. Commenting out lines in /etc/network/interfaces does nothing, even if BOTH wlan0 and eth0 are able to connect.

Excerpts from Jane Atkinson's message of Thu Mar 08 23:39:32 UTC 2012:
> I'm having this problem with a fresh (post-beta1) Precise install on an
> EeePC 900. Commenting out lines in /etc/network/interfaces does nothing,
> even if BOTH wlan0 and eth0 are able to connect.
>

Hi Jane. It would be helpful if you could open a new bug report with

apport-bug upstart

And then mention it here. This bug is basically "fixed" for precise, so
if it comes back in the same form, that would be a new regression bug.
Apport-bug will give us some information about your system that should
help us debug the possible reasons why you're still seeing this timeout
message.

Clint:

Done. I've opened a new bug report: Bug #950662

I have a similar bug. lubuntu 12.04. If I add in the config bridge br0

/etc/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
#iface eth0 inet dhcp
iface eth0 inet static
    address 10.0.1.8
    netmask 255.255.0.0
    gateway 10.0.0.9

auto br0
iface br0 inet static
        address 192.168.0.10
        network 192.168.0.0
        netmask 255.255.255.0
        broadcast 192.168.0.255
        gateway 192.168.0.1

normal boot without a bridge

Please note there is a problem with removable network devices (usually usb). The file /etc/init/network-interface.conf "causes network devices to be brought up or down as a result of hardware being added or removed", as its own comment says, but they must be configured as "auto" in /etc/network/interfaces (exec ifup --allow auto $INTERFACE), which will most likely cause the "Waiting up to 60 more seconds for network configuration" message at boot.

For removable network devices, there should be a method of bringing them up and down correctly without requiring them to be plugged at boot. It was working on previous releases of Ubuntu, probably because there was no delay at boot for missing devices.

On Sat, Jun 02, 2012 at 09:58:18AM -0000, Roberto Gordo Saez wrote:
> Please note there is a problem with removable network devices (usually
> usb). The file /etc/init/network-interface.conf "causes network devices
> to be brought up or down as a result of hardware being added or
> removed", as its own comment says, but they must be configured as "auto"
> in /etc/network/interfaces

If you have network devices that are not always present, which you want to
be autoconfigured when they are, it may be better to configure them with
NetworkManager instead of with ifupdown.

> For removable network devices, there should be a method of bringing them
> up and down correctly without requiring them to be plugged at boot. It
> was working on previous releases of Ubuntu, probably because there was
> no delay at boot for missing devices.

It still works, it just introduces a delay. You can certainly edit the
upstart job to remove / reduce the delay, if that works better for your
environment.

A more complete fix for the problem of ifupdown starting of
sometimes-available network interfaces is unlikely to happen any time soon,
I'm afraid.

In regards to your last comment Steve resorting to having to use network manager to resolve the problem is not a viable or root cause fix. The other issue in using network manager is that it is not applicable when vlans are being used.

Since upgrading from 11.04 to 11.10 and onwards I too have been faced with a myriad of frustrating problems during boot time. For one I would like to completley disable the windows like mentallity of polling and attempting to auto enable network interfaces.

often VLAN's are dropped out and on almost all occasions there is a 2 minute delay even though the VLANs are staticlly set and assigned int he interfaces file.

Sure its good to have the option remain as it is for the average user (I do see the advantages) but for many of us, we thrive on unix/linux due to its awesome capabilites, resiliant, high speed networking stack. And my gosh, this issue, from an oustisde perspective really does bring a sad face to many!!!

there are 15 variations of connection instances on my particular mini mobile pc, such as;

usb teather to android 3g
wirless teather to 3g
wireless access point device
wireless client (multiple configurations)
USB eth10/100 & usb 1GB + multiple VLANS
a physical 1gb eth interface + multiple VLANS
sometimes some of the interfaces are static other times they are dhcp client
vmware network bridging to a variation of interface and location scenarios

All of these configuration are mixed in different scenarios depending on my location and purpose at the time.

I want to boot direct with no network and fire the appropriate script the sets the interfaces file up and starts the networks as desired, along with mounting, vmware, nfs and cifs mappings.

Ubuntu rocks, I love it, but this network boot delay pains me no end :) Especially when there are also 5-6 vmguests each with the same delays!!!

I only mentioned the scenarios above to give a picture of users that do not fall into a common category, please dont let this wonderful OS fall into the Windows trap of frustration.

Is there a permenant solution to disable the network delay timer???

The problem also occurs for my with a freshly-installed Ubuntu Server 12.04 (64 bit). The problem seems to be the existence of sub-interfaces. If there is eth0:1 (iface eth0:1 inet static) in /etc/network/interfaces, an additional waiting time of ~2min is added to the boot sequence. This is quite inappropriate for an uptime-critical server setup. Commenting the sub-interface out resolves the delay-problem, but -- of course -- does not configure the necessary sub-interface.

/var/log/boot.log in the problem case.

With this configuration, the problem does not occur. However, of course, the sub-interface is missing. This is not a useful solution, therefore.

On Mon, Aug 27, 2012 at 08:53:11AM -0000, Thomas Dreibholz wrote:
> The problem also occurs for my with a freshly-installed Ubuntu Server
> 12.04 (64 bit). The problem seems to be the existence of sub-interfaces.
> If there is eth0:1 (iface eth0:1 inet static) in
> /etc/network/interfaces, an additional waiting time of ~2min is added to
> the boot sequence.

Please file a separate bug report against ifupdown for this; this is a
separate root cause from the other issues that have been reported here.

> Commenting the sub-interface out resolves the delay- problem, but -- of
> course -- does not configure the necessary sub- interface.

As a workaround, you could also avoid the delay by using multiple addresses
on a single interface instead of using subinterfaces, which I believe is now
supported by ifupdown.

I had this issue with installing linux 12.04, kubuntu.

Sometimes it hanged and wanted to search network.

Sometimes it skipped the part.

oneiric has seen the end of its life and is no longer receiving any updates. Marking the oneiric task for this ticket as "Won't Fix".

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release