Failsafe boot delay causes a real delay on every boot

Bug #845914 reported by Timo Jyrinki
This bug affects 8 people
Affects Status Importance Assigned to Milestone
upstart (Ubuntu)

Bug Description

Starting today, on each boot there is a non-interruptible long delay, apparently 2 minutes exactly. This started after shutting down computer normally, after having updated oneiric to the latest packages after yesterday.

I do not have a clue what's causing the actual problem, but changing the sleep 120 in /etc/init/failsafe.conf to sleep 1 makes everything work again without problems, and returning it to 120 brings the delay back to the boot.

From user point of view the problem is very worrying and confusing, since a) it happens also in the safe mode and b) it gives impression that either the computer or Ubuntu is simply broken, since also I didn't first wait for two full minutes of nothingness, especially since the problem also occurred in safe mode. I then (after noticing that actually the boot happens if I just wait long enough) started making a note about boot messages, and noted that the delay was slightly before AppArmor profiles loading and finally guessed to change the sleep value in /etc/init/failsafe.

Filing upstart bug mostly because for whatever real need the failsafe boot delay is there (I read a few mailing messages), this shouldn't be a possible behavior. Of course, the real root reason might be somewhere else that causes this to happen. I think I might have been noticed "doing nothing" already before the current value of 120 seconds that was changed a few days ago in upstart, but I'm not sure. This is a new laptop I just got and installed a fresh 64-bit beta 1 Oneiric.

description: updated
description: updated
description: updated
Changed in upstart (Ubuntu):
status: New → Confirmed
Revision history for this message
John Lenton (chipaca) wrote :

As per lp:839595, commenting out /etc/network/interfaces did the trick for me.

Revision history for this message
John Lenton (chipaca) wrote :

Adding my comment here also, because it's unclear to me which of these two bugs is the right place for it.

I can confirm I had 'auto eth0' in /etc/network/interfaces on my notebook, and I don't think I've put them there myself.

Furthermore, I just installed 11.04 in a VM, and /etc/network/interfaces has a "auto eth0" line.

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Like I said, my installation was a fresh Oneiric Beta 1 installation. To be noted though that it was from the alternate CD.

Revision history for this message
Leo Milano (lmilano) wrote :

I think this is mostly a duplicate of bug # 839595 . And the short of it, is that upstart seems to be doing the right thing, but ubiquity seems to be the problem.

A new bug report has been reported for ubiquity, bug #847782

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

I think its more appropriate to mark this as a duplicate of bug #847782. The system is doing what it should, delaying the boot waiting for your defined interfaces to be brought up.

I'm adding plymouth status messages so that the user is informed after 20 and 60 seconds what is happening.

Revision history for this message
xennex82 (xennex82) wrote :

Introducing any kind of script to /etc/network/if-up.d/ that exits with error for eth0 (or in any case static interfaces?) will cause this script to fail, ie. introduce the 120 sec boot delay.

I think it is really bad behavior to consider static network up a must for booting. Static services would already have executed (or tried to execute) from /etc/network/if-up.d/ and they failed if they came after the failing script.

In other words run-parts is executed with the fail-on-fail option (the default).

Should network fail really cause a boot delay?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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