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

Bug #881079 reported by Marius B. Kotsbak
190
This bug affects 38 people
Affects Status Importance Assigned to Milestone
upstart
Invalid
Undecided
Unassigned
console-common (Ubuntu)
Triaged
High
Unassigned
Oneiric
Won't Fix
High
Unassigned
Precise
Won't Fix
High
Unassigned
console-tools (Ubuntu)
Triaged
High
Unassigned
Oneiric
Won't Fix
High
Unassigned
Precise
Won't Fix
High
Unassigned
upstart (Ubuntu)
Fix Released
Medium
Unassigned
Oneiric
Fix Released
Medium
Unassigned
Precise
Fix Released
Medium
Unassigned

Bug Description

SRU justification: any delays in running the rc-sysinit script cause a spurious message to appear on the plymouth boot splash saying that the boot is waiting for the network to become available when it really isn't. This is confusing and misleading to users.

At bootup, while displaying the Ubutu logo, it says waiting for network configuration. Then it says: "Waiting up to 60 more seconds for network configuration", but seems to be stuck until enter key is pressed. Out of the syslog file it seems like it tries to start the wireless network already at bootup, but fails since the key to the network is only available in my user account after logging in.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: network-manager 0.9.1.90-0ubuntu4
ProcVersionSignature: Ubuntu 3.0.0-13.21-generic 3.0.6
Uname: Linux 3.0.0-13-generic i686
ApportVersion: 1.23-0ubuntu3
Architecture: i386
CRDA: Error: [Errno 2] Ingen slik fil eller filkatalog
Date: Mon Oct 24 21:36:06 2011
EcryptfsInUse: Yes
IfupdownConfig:
 auto lo
 iface lo inet loopback

 iface wwan0 inet dhcp
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
IpRoute:
 default via 10.0.0.138 dev wlan0 proto static
 10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.1 metric 2
 169.254.0.0/16 dev wlan0 scope link metric 1000
Keyfiles: Error: [Errno 2] Ingen slik fil eller filkatalog
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
ProcEnviron:
 LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:en
 PATH=(custom, user)
 LANG=nb_NO.UTF-8
 SHELL=/bin/bash
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: network-manager
UpgradeStatus: Upgraded to oneiric on 2011-10-17 (7 days ago)

Related branches

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :
Revision history for this message
Steve Langasek (vorlon) wrote :

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?

affects: network-manager (Ubuntu) → ifupdown (Ubuntu)
Changed in ifupdown (Ubuntu):
status: New → Incomplete
Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

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

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

/etc/network/interfaces contains:

auto lo
iface lo inet loopback
iface wwan0 inet dhcp

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

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.

Revision history for this message
Steve Langasek (vorlon) wrote :

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

affects: ifupdown (Ubuntu) → upstart (Ubuntu)
Revision history for this message
Marius B. Kotsbak (mariusko) wrote :
Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

$ 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

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

Btw, no difference if the internal modem is disabled.

Revision history for this message
Steve Langasek (vorlon) wrote :

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

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :
Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

Files attached.

Revision history for this message
Steve Langasek (vorlon) wrote :
Download full text (5.0 KiB)

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

Read more...

Revision history for this message
Steve Langasek (vorlon) wrote :

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?

Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

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.

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

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

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

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.

Steve Langasek (vorlon)
Changed in upstart (Ubuntu Oneiric):
status: New → In Progress
Changed in upstart (Ubuntu Precise):
status: Incomplete → In Progress
Changed in upstart (Ubuntu Oneiric):
importance: Undecided → Medium
Changed in upstart (Ubuntu Precise):
importance: Undecided → Medium
Steve Langasek (vorlon)
description: updated
Revision history for this message
Chris Halse Rogers (raof) wrote : Please test proposed package

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!

Changed in upstart (Ubuntu Oneiric):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Steve Langasek (vorlon) wrote : Re: "Waiting up to 60 more seconds for network configuration" at startup

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

Revision history for this message
Marius B. Kotsbak (mariusko) 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?

Revision history for this message
Jeff Burns (admiraljkb) wrote :

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

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 881079] Re: "Waiting up to 60 more seconds for network configuration" at startup

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>

Revision history for this message
Steve Langasek (vorlon) wrote : Re: "Waiting up to 60 more seconds for network configuration" at startup

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.

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

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

Revision history for this message
Steve Langasek (vorlon) wrote :

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

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

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.

Revision history for this message
Steve Langasek (vorlon) wrote :

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.

tags: added: verification-done
removed: verification-needed
Changed in console-common (Ubuntu Oneiric):
status: New → Triaged
Changed in console-common (Ubuntu Precise):
status: New → Triaged
Changed in console-common (Ubuntu Oneiric):
importance: Undecided → High
Changed in console-common (Ubuntu Precise):
importance: Undecided → High
Changed in console-tools (Ubuntu Precise):
status: New → Triaged
Changed in console-tools (Ubuntu Oneiric):
importance: Undecided → High
Changed in console-tools (Ubuntu Precise):
importance: Undecided → High
Changed in console-tools (Ubuntu Oneiric):
status: New → Triaged
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in upstart (Ubuntu Precise):
status: In Progress → Fix Released
Revision history for this message
Flapane (flapane) wrote :

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

Revision history for this message
Flapane (flapane) wrote :

# 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

Revision history for this message
Steve Langasek (vorlon) wrote :

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

Revision history for this message
Richard Sellam (richard-sellam) wrote :

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

Revision history for this message
Flapane (flapane) wrote :

@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

Revision history for this message
Steve Langasek (vorlon) wrote :

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?

Revision history for this message
ororo (ororo) wrote :

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.

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 881079] Re: "Waiting up to 60 more seconds for network configuration" at startup

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>

Revision history for this message
ororo (ororo) wrote : Re: "Waiting up to 60 more seconds for network configuration" at startup

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.

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 881079] Re: "Waiting up to 60 more seconds for network configuration" at startup

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>

Revision history for this message
Flapane (flapane) wrote : Re: "Waiting up to 60 more seconds for network configuration" at startup

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)

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 881079] Re: "Waiting up to 60 more seconds for network configuration" at startup

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>

Revision history for this message
Flapane (flapane) wrote : Re: "Waiting up to 60 more seconds for network configuration" at startup

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

Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Revision history for this message
Flapane (flapane) wrote :

Done it, thanks. Bug #885596

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in upstart (Ubuntu Oneiric):
status: Fix Committed → Fix Released
Revision history for this message
LStranger (andrej-rep) 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

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.

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 881079] Re: "Waiting up to 60 more seconds for network configuration" at startup

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>

summary: - "Waiting up to 60 more seconds for network configuration" at startup
+ FIXED: spurious "Waiting up to 60 more seconds for network
+ configuration" message at startup, but all network devices are up
Revision history for this message
LStranger (andrej-rep) 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! Bug isn't fixed in 1.3-0ubuntu11 yet!

Revision history for this message
LStranger (andrej-rep) wrote :

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.

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 881079] Re: FIXED: spurious "Waiting up to 60 more seconds for network configuration" message at startup, but all network devices are up

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>

Revision history for this message
LStranger (andrej-rep) wrote :

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.

Revision history for this message
Mark - Syminet (mark-syminet) wrote :

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#

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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!

Revision history for this message
panticz.de (panticz.de) wrote :

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

Revision history for this message
Mark - Syminet (mark-syminet) wrote :

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!

Revision history for this message
Ming Lei (tom-leiming) wrote :

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 Lei (tom-leiming)
Changed in upstart (Ubuntu Precise):
status: Fix Released → Confirmed
Changed in upstart (Ubuntu Precise):
status: Confirmed → Fix Released
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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

Revision history for this message
Alberto Jovito (thedemon007) wrote :

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.

Revision history for this message
Jane Atkinson (irihapeti) wrote :

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.

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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.

Revision history for this message
Jane Atkinson (irihapeti) wrote :

Clint:

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

tags: added: rls-mgr-p-tracking
Revision history for this message
JohnDoe_71Rus (johndoe99) wrote :

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

Revision history for this message
Roberto (rgs) 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 (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.

Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Revision history for this message
Craig (craig-tait) wrote :

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

Revision history for this message
Thomas Dreibholz (dreibh) 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. 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.

Revision history for this message
Thomas Dreibholz (dreibh) wrote :

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

Revision history for this message
Thomas Dreibholz (dreibh) wrote :

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

Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Steve Langasek (vorlon)
Changed in upstart:
status: New → Invalid
Revision history for this message
Jarkko Korpi (jarkko-korpi-t) wrote :

I had this issue with installing linux 12.04, kubuntu.

Sometimes it hanged and wanted to search network.

Sometimes it skipped the part.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

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

Changed in console-common (Ubuntu Oneiric):
status: Triaged → Won't Fix
Changed in console-tools (Ubuntu Oneiric):
status: Triaged → Won't Fix
Revision history for this message
Steve Langasek (vorlon) wrote :

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

Changed in console-common (Ubuntu Precise):
status: Triaged → Won't Fix
Changed in console-tools (Ubuntu Precise):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.