entering 'reboot' at the rescue console brings up gdm

Known, use "reboot -f"

Caused by the fact that the rcS job is still running, reboot issues the "shutdown" event but that won't actually complete until rcS and then rc2 have finished ... you'll probably find that the moment it hits gdm, it starts shutting down again?

no, I had to select 'reboot' at the gdm prompt.

Perhaps I was to fast pressing reboot, however (30seks).

Oh, right, the gettys would be running and thus save the system from shutdown -- ho-hum :)

Actually, sorry, scratch that last -- the reboot event can be issued when processes are in start

Seeing the same in Gutsy. It does not start to shutdown after starting gdm.

Need to figure out what's causing this

Isn't it printed on the screen after dropping to maintenance console, that after doing maintenance you have to press Control+D to reboot?

No, this is not printed. And in fact, ctrl-D won't reboot, either. There is really, really no way to properly reboot at this stage.

"reboot -f" is _not_ a proper workaround, since it will not umount/sync filesystems properly.

BTW: This bug still exists in 8.04rc. :-(

Still there in Ubuntu 8.04.1. I think its especially bad because fsck tells me to reboot (I guess that's recommended after root file system repair) and when I type "reboot" it starts up everything (which must be not recommended for the same reasons).

In Ubuntu 8.10, the wording has been changed to reflect the actual beahvior. It now reads "press ctrl-D to resume boot". I don't think this is a proper solution to the problem. IMHO there _have_ to be a way to properly shutdown without continuing the boot. E.g. one might want to make a copy of the corrupted filesystem before trying to repair it. Continuing the boot is the worst thing one can do in such a situation.

8.04.2 remote use of reboot -f leaves the user in server mode having to make a journey to the on off button or find someone who can

not great when it is a test firewall but better than it being in production

Fedora bug looks like the same thing, just expressed differently

Ok, so here's my current working theory on this bug.

When you are in single-user mode, the rcS-default job is running: this is what runs "sulogin". Once "sulogin" finishes, this then runs "telinit" to switch to the default runlevel.

If you type "reboot" inside the "sulogin" shell, that will run "shutdown" which will send a runlevel event to change the runlevel (to 6).

Now, what's supposed to happen is this:

 * the rcS-sulogin job is stopped (stop on runlevel)
 * the rcS-sulogin script, sulogin, etc. are sent the TERM signal and die
 * the rc6 job is started (start on runlevel 6)
 * shutdown begins

When I try it, that's what happens.

Now, what I think *MIGHT* happen for some people is:

 * the rcS-sulogin job is stopped (stop on runlevel)
 * the sulogin script gets sent the TERM signal
 * the rcS-sulogin script continues, and gets to run "telinit 2"
 * the rcS-sulogin script gets send the TERM signal
 * _but_ telinit2 sends the "runlevel 2" event
 * the rc6 job is stopped (stop on runlevel [!6])
 * the rc2 job is started (start on runlevel 2)
 * normal boot begins

So this would be a race condition.

0.3 gives us an easy way to fix this, the job stop cause is in $UPSTART_EVENT for the post-stop script, so all we need to do is move the telinit into post-stop and only run if if $UPSTART_EVENT != runlevel

Interestingly this is impossible with 0.5 because it doesn't reveal why a process was stopped, and this makes we realise that we do need that functionality

Though also thinking about it, we really want the rc-default job to be run - and therefore the stopping event to know why it stopped ;)

Moving the telinit code into post-stop and checking $UPSTART_EVENT looks like it does the trick

Actually, we have to check $1 as well - $UPSTART_EVENT is not reset if the stop command is by exit, so it still contains "runlevel" because that's what started the job.

        if [ "${UPSTART_EVENT}" = "runlevel" -a "$1" != "S" ]
        then
            exit 100
        fi

Seems right

100 being for debugging, obv

This bug was fixed in the package upstart - 0.3.10-2

---------------
upstart (0.3.10-2) karmic; urgency=low

  * debian/upstart.postinst: Use telinit u to re-exec, rather than
    kill just in case it's not Upstart that's running. LP: #92177.
  * debian/event.d/system-services/tty*: Run getty in 8-bit clean
    mode. LP: #273189.
  * debian/event.d/upstart-compat-sysv/rc-default:
    - Don't use grep -w, instead split on $IFS and iterate. LP: #385911.
    - Check for any valid runlevel, not just S. LP: #85014.
    - Make console owner, since it may spawn sulogin.
  * debian/event.d/upstart-compat-sysv/rcS:
    - Spawn sulogin if given -b or "emergency". LP: #193810.
  * debian/event.d/upstart-compat-sysv/rcS:
    - Make console owner. LP: #211402.
  * debian/event.d/upstart-compat-sysv/rcS-sulogin:
    - Place the telinit code in post-stop, checking $UPSTART_EVENT first so
      we don't change the runlevel if we were stopped due to a runlevel
      change. LP: #66002.

 -- Scott James Remnant <email address hidden> Thu, 18 Jun 2009 16:19:34 +0100