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  *or* stopping kdm. The runlevel event is emitted first; does this confuse things?