Comment 2 for bug 870832

Steve Langasek (vorlon) wrote :

There's enough information here to reproduce the issue (and I can reproduce it easily), so I consider this bug "triaged", although I haven't been able to diagnose *why* it's happening so a fix is elusive for the moment.

This appears to be an issue specific to ubiquity-dm. It's reproducible when choosing "install $OS" from the menu instead of "Try $OS", in which case kdm/lightdm are never run. As such I'm reassigning the bug to ubiquity.

The intended shutdown sequence is as follows:
 - ubiquity-dm is running, having started on 'starting [kdm|lightdm]'. The main dm itself is in state 'start/starting'.
 - a reboot event is issued from within ubiquity at the end of installation. ubiquity itself remains running with the X server.
 - the reboot event causes a runlevel change. The target of kdm changes from 'start' to 'stop'.
 - the ubiquity job, which is 'stop on stopping [kdm|lightdm]', exits on SIGTERM from upstart, taking the X server with it before it returns.
 - with the ubiquity job stopped, the kdm job also stops, immediately running its post-stop script without ever running the main script. this script emits the 'desktop-shutdown' event.
 - the plymouth job starts upon receipt of the 'desktop-shutdown' event and takes over the console smoothly.

What actually happens:
 - No idea. I've had a very hard time debugging this so far, as even when I mangle jobs to try to keep things running, executing 'reboot' somehow sends *all* my VTs into graphical mode (displaying a working cursor over the console text)
 - I suspect this may be a race condition because ubiquity stops on runlevel [06] *or* stopping kdm. The runlevel event is emitted first; does this confuse things?