Shutdown/Restart of live session guest does not work in Virtualbox, and VMWare

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/1447038

Also affects 32-bit guest

Status changed to 'Confirmed' because the bug affects multiple users.

Does not affect kvm/qemu or bare metal.

This was replicated in a VMware Workstation 10.0.5 environment. This gist link will detail the hardware profile for the VM used for testing:

https://gist.github.com/anonymous/1bcd127e8b5748283514

Just tested this with Wily Daily ISO for July 3, 2015 and can confirm it still is occurring.

Tested on Ubuntu MATE 15.10 daily ISO for July 22 and it appears to be fixed :-)

Tested with the Ubuntu MATE 15.10 daily ISO for August 29th, and it doesn't appear fixed, or at least it shows a shutdown job with "unlimited". I waited a couple of minutes then just closed the VB guest. How long did you have to wait for it to finally shut down, or did it shut down really quickly?

What I'm seeing with the current RC image shutting down from vbox

No, this won't show in KVM; only with VirtualBox or VMWare.

Is anyone else seeing this report from comment #9 about a job waiting to be terminated, but with an 'unlimited' limit?

Otherwise, this would seem to be an issue with the caching when we stop the image, still -- we must still be missing some small things for it to work correctly on VBox and VMware.

I've not seen that 'unlimited' message, and I've likely run ~200 iso's in vbox

I am repeatedly seeing #10 with virtualbox.

This bug is still present in Xenial.

I am finding this to be present in Xenial as of the 20151231 daily ISOs.

mathieu-tl: In comment #12, what exactly are you looking for? I'm working on improving this bug report.

I was expecting confirmation of my thoughts about that job waiting to end; we got that from flocculant.

There isn't anything missing for this but careful debugging on the shutdown processes. Ideally it would have to be reproduced with the splash disabled, so we can see as much information as possible, possibly attaching a serial console to the VM so that debug messages from plymouth and/or systemd can be written there, hopefully something will pop up.

The gist of it hasn't changed, I still think this is failing because plymouth doesn't like some aspect of how the video driver works on VirtualBox and VMWare, so one thing to try would be to test with different video drivers -- in KVM parlance, for example, switching between vga and qxl could change the result, but I'm not familiar enough with VBox and haven't used VMWare in so long that I wouldn't know what drivers there are or how to change them :)

Changing the Virtualbox settings and the kernel command line to output to a text file on the host machine (see https://www.virtualbox.org/wiki/Serial_redirect) worked to get a log file, but caused the "Please remove the installation medium, then press ENTER:" screen as well as a text-mode animation to show up. Pressing enter did not cause the system to shut itself down though. The text-mode shutdown animation continued to display along with the "Please remove the installation medium, then press ENTER:" message. Due to the fact that the issue changes whenever logging is set up, it will likely be difficult to debug this issue fully.

Just a reminder that someone will need to add this to Xenial's Release Notes, too.

One of the comments on the Ubuntu MATE 16.04 Alpha 1 tracker suggests the KVM is also affected. Can someone confirm?

KVM is also affected.

This bug is still present in Xenial Lubuntu live CD 20160102
but if i use single inlog Shutdown its ok

Bug present in Xenial GNOME (daily)

Mathieu,
   According to systemd debug-shell the stuck job, is casper-stop waiting on "plymouth watch-keystroke", see attached screenshot. Atleast on VMware the plymouth shutdown splash is not being displayed, so I guess keystrokes never make it to plymouth.

No such issue was faced by me......

No longer affects Lubuntu Alternate 64 bit 120116 and KVM

No longer affects Lubuntu Desktop 64 bit Running LiveCD mode on 120116 iso with KVM

I used Xubuntu xenial-desktop-amd64.iso on 20160113 and in VirtualBox PLEU 5.0.12 r104815 and the installer still gets hung after it has ejected the ISO. I know it ejects as VirtualBox flips back from having the ISO mounted to the drive being empty.

Should not it then get to some message about pressing any key to restart? Pressing keys did nothing to cause a restart of the VM.

I used VirtualBox's hard reset and the VM boots up just fine. Does not look completely fixed to me.

I did some testing on this bug.

Due to some issues between me and the cdimage server, I ran the 20160129 image of Lubuntu Desktop in my QA testing VM, on my VMware Workstation Pro 12 environments (both 32bit and 64bit). There is indeed a "won't shutdown" issue, but I think it's related to the prompt that shows up on the other already-released ISOs for the main releases - it asks for the user to hit "Enter" to reboot after ejecting or removing installation media. This does not display, though, so it looks like a "won't shutdown ever" issue.

Given that I remembered this, though, in a test to see if this was the issue, I hit "Enter" at the blinking cursor I see when running this in VMware, when it appears to not "shut down". This allows the system to shut down as it should, and hitting "Enter" then has the guest "live" session shut off as it should.

I think, then, that with the images, it may be a case that it is waiting for the response to this prompt, hence the "Unlimited" task of waiting for user input. As referenced to in comment 25 here, the waiting for the enter keystroke is what is hanging it up, and the splash screens not showing up to show this is the main issue.

Follow-up to comment #30 (my last post to this bug): This workaround is confirmed in VMware Workstation Pro 12, with version 12 vmx files, in the 20160130 daily as well

I have also followed this up and installed the latest virtual-box as advertised which is Version 5.0.14 r105127 as if it were solved on that, we would have enough time to get it into the LTS. Sadly, when pressing enter / return the session is still showing as running.

Testing Ubuntu GNOME 16.04 Beta 1 20160225.1 (amd64) and this bug is alive and doing well.

it also occurs on bare metal. It seems to be a race issue where a process
is starting before the previous one has things settled. But, it is pain so
we do need a geek to agree to look at it and we minions provide logs and
testing to them. I'm up for being a minion :)

On 25 February 2016 at 12:10, amjjawad  <email address hidden> wrote:

> Testing Ubuntu GNOME 16.04 Beta 1 20160225.1 (amd64) and this bug is
> alive and doing well.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1447038
>
> Title:
> Shutdown/Restart of live session guest does not work in Virtualbox,
> and VMWare
>
> Status in Release Notes for Ubuntu:
> Fix Released
> Status in casper package in Ubuntu:
> Triaged
>
> Bug description:
> Hardware: https://gist.github.com/anonymous/e613830ce44594c5cf93
>
> Running a live guest, 20150422 15.04 image. Cannot shutdown/restart
> using normal procedure/menu item. Must hard power off the guest.
>
> Steps to reproduce:
> - Start up live session in Virtualbox or VMWare preferably with the
> latest daily ISO
> - Select "Shut Down" in the system GUI
>
> Expected results:
> - The system shuts down and the VM reports that it is shut down
>
> Actual results:
> - The system does not shut down and instead remains on a blank screen
>
> Known affected flavors:
> - Ubuntu
> - Xubuntu
> - Ubuntu GNOME
> - Lubuntu
> - Kubuntu
> - Ubuntu MATE
>
> Notes:
> - The bug does not occur after installation, only in the live session
> - Does not affect 14.10 and earlier
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu-release-notes/+bug/1447038/+subscriptions
>

Phill,
   Boot with "systemd.debug-shell plymouth:debug" added as kernel params then when it hangs switch to VT9. You will probably need to manually remount a partition/usb to get the logs out, since you will be quite late in the shutdown cycle.

grab `journalctl` output and /var/log/plymouth-debug.log

I can't reproduce on my laptop, though I did poke around previously in a VM. vbox was I recall having drm issues, vmware just seemed racy (it worked maybe 1/5 reboots).

Tim you can also edit the kernel command line to output the logs through a serial port if you have the equipment to receive the logs afterwards.

@ darkxst - Tried to grab these logs from running the debugs - not managed so far.

That said, originally I misread your 'added' and removed quiet splash and just put the debug commands - without quiet and splash - I get the 'Remove media and press Enter' - doing so - does as expected.

flocculant, if you remove "splash" plymouth gets disabled and the casper code will fallback to console i/o.

yea - realised that a bit later - can't edit comments - anyway - still not able to grab the logs though.

you couldnt get to VT9 or just unable to export logs?

Not able to get to vt9. Can only get to vt1.

wierd, if systemd is hung vt9 is available on shutdown when booting with systemd.debug-shell

mea culpa ...

systemd.debug-shell works - unsurprisingly =shell doesn't, that'll explain why it worked once and then not again ...

So - got to vt9 - can see plymouth.log

Not seemingly able to do much other than read it in the vt.

However by grepping the log at vt9 against the one I got from inside the booted system - the last line is exactly the same.

The log that shows once the livesession is booted can be seen at http://paste.ubuntu.com/15327027/

Not having much luck with journalctl - got the one from the livesession as a paste, trying to grab the output from vt9 is problematic - would be simple if I could get networking there ... all I've managed is a bunch of screenshots of the extra journalctl output.

Just saw two variations of this with Ubuntu Studio amd64 and Virtual Box on two different sets of host hardware (desktop and laptop).

Laptop:
Reached the end of the full installation, and got the "Installation complete - you need to restart" dialogue. Clicked to restart and the VM froze with the dialogue showing that I had clicked the button for at least half an hour. Walked away, and when I came back, the VM had booted into the installed Ubuntu Studio. So a pass, but frustratingly slow.

Desktop:
Reached the end of the full installation, and got the "Installation complete - you need to restart" dialogue. Clicked to restart and the VM slowly removed icons, then went to a blank screen, and hung for at least half an hour. Walked away, and when I came back, the VM had booted into the live Ubuntu Studio installation ISO again. Chose shutdown from the menu, and I am still waiting for the machine to shutdown 20 minutes later.

I did some testing today with Lubuntu Xenial i386 in two real computers, and it seems that live systems booted from cloned drives do not shutdown correctly, but grub-n-iso systems are not affected by this bug.

See this link to the current bug report #1552985
and to my comment, #17

Could it be that this bug is actually the same as that one? An ISO image used by VirtualBox has the same content as a USB drive created by cloning (from the ISO image file).

To make it convenient for you, here is the link to the bug report referred to in the previous comment

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1552985/

are those images created with grub-n-iso persistent USB's? that will create differences in timing etc especially on 2nd and later boots. Atleast on vmware this issue seems to be a race issue in the systemd units.

I don't think syslinux vs grub should make any difference, I see the same issue on an installed system under Vmware. It just doesnt hang there, since there is no prompt asking for user input.

This bug is alive for Ubuntu 16.04 GA. Any schedule to fix it ?

This bug is alive for Ubuntu 16.04.1 Desktop.

This issue is alive for ubuntu-gnome-16.10-beta1-desktop-amd64.iso when install in ESXi 6.0GA / 6.5RC.

This issue is alive for ubuntu-16.10-beta2-desktop64 when install in ESXi 6.0GA / ESXi 6.5 build 4491798

This issue is alive for ubuntu-17.04-desktop64 dailybuild 7-Mar-2017 when check in ESXi6.6.

I hit the similar issue as described in #44 in Canonical Ubuntu 15.10, Ubuntu 16.04, Ubuntu 16.10, Ubuntu 17.04 when check in ESXi6.0 GA, ESXi 6.5GA, ESXi 6.6.

Issue description:
Reached the end of the full installation, and got the "Installation complete - you need to restart" dialogue. Clicked to restart and the VM froze with the dialogue