Installer hangs after clicking "Restart Now"

[Jason Gerard DeRose]

STEPS TO REPRODUCE
 1. Boot Vivid
 2. Select "Install" (not "Try before installing")
 3. Go through the installation process
 4. Upon successful installation, select "Reboot Now"

EXPECTED RESULTS
 * system reboots

ACTUAL RESULTS
 * system does not reboot or shutdown
 * cannot get to tty

AFFECTS
 * images: 20160417+, all flavors
 * ubiquity 2.21.22
 * VirtualBox, QEMU, bare metal

NOTES
 * this was mentioned earlier in the cycle but on older bugs, so this may be a regression of some kind
 * cyphermox claims this does NOT happen in the live session

WORKAROUND
 * hard reboot
 * boot with init=/sbin/upstart

[Martin Pitt (pitti)]

Mathieu, this sounds like the bug you mentioned last Friday, right? ubiquity-dm not *being* a display manager, but running before it, and lightdm trying to start after that, in parallel with shutdown?

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1445587

[Martin Pitt (pitti)]

I finally understand this now. gtk_ui.py's do_reboot() and do_shutdown() call reboot/poweroff. But under systemd this is faster and kills ubiquity.service before it gets to orderly shutting down X.org in ubiquity-dm. So this race has been there all the time, we just didn't notice on most systems as reboot was slow enough to give ubiquity-dm time to get past the X.org shutdown.

[Jason Gerard DeRose (jderose)]

Martin,

Thanks for looking into this! So from what you're saying, this could potentially happen on a bare-metal install also if, say, the installation media was fast enough?

When I'm doing qemu installs, often most or all of the ISO is already cached in RAM, so it make sense that such a race condition could show up in this scenario.

Thanks!

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

Indeed, as you can see from one of the dupes, this can affect bare metal, other virtual machines, any flavor, etc. Thanks Martin!

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 2.21.23

---------------
ubiquity (2.21.23) vivid; urgency=medium

  * Stop running ubiquity.service as an oneshot service, as this blocks the
    initial boot transaction (including ureadahead etc.). Instead, manually
    start lightdm in the cases where we don't want ubiquity-dm.
  * GTK/KDE UI: GTK/KDE UI: Fix race between calling reboot/poweroff and the
    later stopping of the spawned X server by ubiquity-dm. We need to first
    shut down X orderly and then reboot/poweroff to get a proper transition to
    Plymouth. This is a rather nasty hack; fixing this properly requires some
    more intrusive reeingeering. (LP: #1445587)
 -- Martin Pitt <email address hidden> Mon, 20 Apr 2015 18:41:11 +0100

[gravy45 (gravy45)]

It does show up in Ubuntu MATE 15.04 20150422.1. Virtualbox guest 4.3.26. See attachment also.

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

It seems this is a bug only in VirtualBox still. The fix worked for hardware and kvm. Unsure about VMWare but no one's been complaining, so I guess that's a good thing. So if you could file a new bug specifically referencing VirtualBox and how this bug does not fix it, that would be fantastic. Even better, report it on the ISO tracker so others will see it.

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

Actually I see you already have :) For anyone that ends up here, look at https://bugs.launchpad.net/ubuntu-mate/+bug/1447038