Plymouth not shown during live disk shutdown.

[Philip Muškovac]

When rebooting after installing kubuntu oneiric amd64 with the release candidate image at shutdown instead of plymouth background you see the terminal with the plymouth dots being shown in the center.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: plymouth 0.8.2-2ubuntu28
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.23-0ubuntu2
Architecture: amd64
Date: Sat Oct 8 18:40:57 2011
DefaultPlymouth: /lib/plymouth/themes/kubuntu-logo/kubuntu-logo.plymouth
InstallationMedia: Kubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20111007)
MachineType: LENOVO 4349W1R
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-12-generic root=UUID=408b8f9a-b069-445f-86ba-3d9c5cbd75a1 ro nouveau.noaccel=1 nomodeset pcie_aspm=force
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
 LANGUAGE=en_US.UTF-8
ProcFB: 0 VESA VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-12-generic root=UUID=408b8f9a-b069-445f-86ba-3d9c5cbd75a1 ro nouveau.noaccel=1 nomodeset pcie_aspm=force
SourcePackage: plymouth
TextPlymouth: /lib/plymouth/themes/xubuntu-text/xubuntu-text.plymouth
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/26/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 6MET81WW (1.41 )
dmi.board.name: 4349W1R
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6MET81WW(1.41):bd10/26/2010:svnLENOVO:pn4349W1R:pvrThinkPadT510:rvnLENOVO:rn4349W1R:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 4349W1R
dmi.product.version: ThinkPad T510
dmi.sys.vendor: LENOVO

[Steve Langasek (vorlon)]

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?

[Steve Langasek (vorlon)]

Interestingly, running 'stop kdm' from console in the installer hangs indefinitely, and 'status kdm' shows the job as 'stop/starting'. So the only reason this works as well as it does is that the ubiquity job is also 'stop on runlevel [06]'

[Steve Langasek (vorlon)]

Well, one problem in the ubiquity-dm code is that it has no SIGTERM signal handler. So anything that causes ubiquity-dm to die by signal (i.e., anything that causes upstart to want to stop the job, such as a manual call to 'service ubiquity stop' or a runlevel change) does not clean up the child processes... such as the X server.

This doesn't explain the behavior at the end of an install, because in that case ubiquity-dm does try to shut down the X server before calling reboot. It might still be related to the race condition between ubiquity-dm shutting down (thus no longer blocking the kdm job and allowing it to try to start an X server) and the runlevel event being propagated by the 'reboot' call. If so, it might be possible to address this by having ubiquity-dm not exit in the reboot case but instead wait to receive SIGTERM.

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Marcus Tomlinson (marcustomlinson)]

This issue has sat incomplete for more than 60 days now. I'm going to close it as invalid. Please feel free re-open if this is still an issue for you. Thank you.

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release