Ubuntu

Bug #642555
Comment #3

Comment 3 for bug 642555

Revision history for this message

Mike Bianchi (mbianchi-foveal) wrote on 2010-09-22:

> I'd believed this was an upstart issue and related to bug 554172 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554172)
> I tried the workarounds until an official fix was release, but neither the workarounds nor the official patch solved the issue for me.

Please document here precisely which workarounds you have used.

Are you seeing runlevel unknown or runlevel N 2 ?

A crucial component of my investigations was turning on the init tracing
by adding to the "linux" line in the grub file
text init='/sbin/init --verbose'

"text" turned off the graphical boot.

"init='/sbin/init --verbose'" showed the interal activity of init .
I also _believe_ that --verbose also improved the boot reliability by
slightly serializing some (not all) things that would otherwise be parallel.

I do not have a means to exercise this bug right now, but am still very
interested.

My two cents: I think it would be good to have access to an old fashion,
one-step-at-a-time boot sequence (as an option).

Since the upstart /bin/init runs things in parallel, using events to
control critical sequences, if the writer of an init sequence does not _fully_
understand the relationships among the many services, it is possible for a
particular service to be started before or after a critical prerequisite
(that I am unaware of) has completed, making the boot randomly unreliable.

I would gladly give up boot speed for boot sequence certainty. I do not
see a way to do that with upstart. Boot sequence certainty was easy to
accomplish when everything was started by numbered filenames under
/etc/init.d .

A variation of that theme _might_ be to record the boot sequence order of a
successful boot and then make that the normal sequence. (I know. This IS a
tricky concept in an SMP situation.)

A suggestion, slightly off topic:

Could upstart init have a command that opens /dev/console
for itself and all its children, and another command that closes it.
By putting, say, "open /dev/console" in the first /etc/init/*.conf file
and "close /dev/console" at the end of the last one, at least all the
boot sequence services would be guaranteed a writable (and presumably not
/dev/null) stdout and stderr.

Please document here precisely which workarounds you have used.

Are you seeing  runlevel unknown  or  runlevel N 2 ?

A crucial component of my investigations was turning on the init tracing
by adding to the "linux" line in the grub file
	 text  init='/sbin/init --verbose'

"text" turned off the graphical boot.

"init='/sbin/init --verbose'" showed the interal activity of  init .
I also _believe_ that  --verbose  also improved the boot reliability by
slightly serializing some (not all) things that would otherwise be parallel.

I do not have a means to exercise this bug right now, but am still very
interested.

My two cents:  I think it would be good to have access to an old fashion,
one-step-at-a-time boot sequence (as an option).

I would gladly give up boot speed for boot sequence certainty.  I do not
see a way to do that with upstart.  Boot sequence certainty was easy to
accomplish when everything was started by numbered filenames under
 /etc/init.d .

A variation of that theme _might_ be to record the boot sequence order of a
successful boot and then make that the normal sequence.  (I know.  This IS a
tricky concept in an SMP situation.)

A suggestion, slightly off topic:

Could upstart init have a command that opens  /dev/console
for itself and all its children, and another command that closes it.
By putting, say, "open /dev/console" in the first  /etc/init/*.conf file
and "close /dev/console" at the end of the last one, at least all the
boot sequence services would be guaranteed a writable (and presumably not
/dev/null) stdout and stderr.