Utopic server VM's do not fully restart

[Para Siva]

Utopic server VM installations do not fully restart (roughly 50% of the time) after the installation. The screen either is stuck at the grub menu selection screen indefinitely or stuck at the screen as shown in the attachment.

Although, manually hitting enter a couple of times make the vm to fully boot, the automated smoke tests hang forever due to this issue.

The following line can be seen in dmesg when this happens
init: plymouth-upstart-bridge main process (167) terminated with status 1

Not sure when exactly this issue started occurring due to some other issues impacting the smoke tests recently, but the tests started failing roughly around when 3.15.0-2 was introduced (20140524). The host where the VM's are created is trusty, and this can be seen with amd64 and i386 not always but roughly 5/10 reboot attempts.

Seen a similar bug report, https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1309617 for trusty and not sure if at all it's related.

To Reproduce:
1. Do a server install using utopic iso (20140604) - doing an lvm partition with dns installation *appear to make the bug more easily reproducible
2. Once the installation is complete carry out virsh destroy /virsh start repetitively and this issue should arise within about 5 attmpts

[Para Siva (psivaa)]

Screen shot when the boot hangs forever

[Steve Langasek (vorlon)]

plymouth-upstart-bridge is a cosmetic element of the boot, feeding messages about upstart jobs into plymouth for display. A failure of this service is almost certainly not going to be responsible for a boot-time hang - though I also don't know what is causing it, so for now, not reassigning to a different package.

psivaa, you mention the kernel version. Is downgrading the kernel sufficient to resolve the failure? At the time of the boot hang, if you press 'Esc', is any information displayed from plymouth? Or if you boot with 'splash' on the commandline, do you get something more informative than a boot hang?

Stéphane, you're the VM master - can you reproduce the problem psivaa is describing?

[Para Siva (psivaa)]

Adding 'splash' to command line did not give any more information but I was able to reproduce this even with the last known working kernel 3.15.0-1-generic.

Curious if filesystem corruption cause by the previous malformed shutdown is any reason for this behaviour? I just noticed that destroying the vm prematurely during a startup is a certain way to reproduce this issue.

[Steve Langasek (vorlon)]

On Tue, Jun 10, 2014 at 11:06:07AM -0000, Parameswaran Sivatharman wrote:
> Curious if filesystem corruption cause by the previous malformed
> shutdown is any reason for this behaviour? I just noticed that
> destroying the vm prematurely during a startup is a certain way to
> reproduce this issue.

That's certainly a possibility, though in that case plymouth should show
more information under 'splash'.

[Para Siva (psivaa)]

OK, thanks.
I've got GRUB_CMDLINE_LINUX_DEFAULT="splash" in the /etc/default/grub (and ran update-grub) and still *I dont see any more info. The grub menu is permanently present without the time ticking down.

I'm not sure if this is a bug in libvirt by not performing a properly cleaned up shutdown when virsh shutdown is called.

[Para Siva (psivaa)]

This was fixed by adding a delay before shutting down the VM in utah. Marking this as invalid. Thanks for the info in this.