[Solved] Ubuntu 18.04 guest hangs during boot

[MainMan]

Hello Experts,

I'm trying to launch a new VM from an existing VMDK file in VirtualBox 5.28. The VM will never finish boot, but doesn't show any errors either. The longest I've waited for the boot to complete is about 2 days.

Please see the attached screenshot for the last lines that will appear on the VM console during boot.

boot sequence hanging

ubuntu_boot_hanging.png (23.87 KiB) Viewed 10621 times

So here the boot seems to hang indefinitely. In addition, I can see the VirtualBox process using about 20 % of CPU all the time.

PFA also VBox.log and VBoxHardening.log.

Other VMs, e.g. another Ubuntu 18.04 machine created via bootable ISO image, and also a Win10 VM, do work properly in the same VirtualBox.

I've tried the same VMDK file in VMware Workstation 15, and there the VM is able to boot normally. In this instance, I can see in dmesg output the next thing that should happen after the 'Btrfs loaded' message is mounting the root filesystem:

Code: Select all

EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

I've also tried with VirtualBox 6.0.6, but the behavior is similar.

The host is Windows 10 Enterprise 1709.

What could cause this hanging boot issue?

[MainMan]

PFA the VBOX file, too.

[MainMan]

Hmm, after more careful examination of the VBoxHardening.log, I'm now assuming the issue is caused by Symantec:

18c4.4abc: supR3HardenedWinFindAdversaries: 0x3
18c4.4abc: \SystemRoot\System32\drivers\SysPlant.sys:
...
18c4.4abc:     FileDescription: Symantec CMC Firewall SysPlant

Unfortunately I'm not able to remove Symantec as this is controlled by my employer.

[socratis]

Try to put an exception for all VirtualBox related processes then...

[MainMan]

Hi,

Unfortunately, I'm not able to create application exceptions in Symantec, as it s not allowed by the group policy.

However, I can see similar Symantec-related messages in the VBoxHardening.log also for a working VM:

4b64.7a4: supR3HardenedWinFindAdversaries: 0x3
4b64.7a4: \SystemRoot\System32\drivers\SysPlant.sys:
...
4b64.7a4:     FileDescription: Symantec CMC Firewall SysPlant

So these Symantec-related messages don't seem to indicate the real issue, as they come also for working VMs. And as mentioned, this particular VMDK file works if I use it in VMware Workstation.

I'm attaching the VBoxHardening log for a working Ubuntu VM.

[socratis]

And as mentioned, this particular VMDK file works if I use it in VMware Workstation.

A pre-made VM in another program might or might not work, I don't know what you've installed in your VM that doesn't make it a bootable one. Only you know. For example, if you've installed the VMware tools, then that might be a problem...

Try with a fresh install from an ISO. Does that fail?

[MainMan]

Hi,

Sorry about lack of response, I was on sick leave.

As an answer to the question, yes, VMs created from ISO images worked while the problem with this one VMDK file persisted.

But I've got good news and the problem is now resolved.

First of all, I upgraded my VirtualBox to version 6.06.

Secondly, the guy who had created this VM found the issue:

Using Win10 host with VirtualBox 6.0.2 the boot is indeed slow still with this VM image. However, the intial part of the boot process goes with normal speed if the serial port (that's been configured for unknown purposes) is disabled. For some reason, the process gets apparently stuck after "Btrfs loaded, crc32c=crc32c-intel" is printed so this change still doesn't solve the issue.

Disabling the serial port is actually the wrong solution but investigating why that helped revealed the actual issue. The VM is configured with console=ttyS0 as one of the kernel parameters (/etc/default/grub -> GRUB_CMDLINE_LINUX_DEFAULT) which causes a dependency with the serial port. If the serial port is enabled but not connected (the default state) then the boot is slow. Disabling the serial port makes the boot fast until something needs to be written to the port and that's when things get stuck. Changing the Port Mode to "Raw File" (in VirtualBox configuration) and giving some file to use results in everything working as expected (at least from my point of view) with VirtualBox 6. The given raw file will contain the startup message + a login prompt after boot.

So based on the above, I checked the Serial Ports setting for this VM in VirtualBox, and noticed that Port 1 was indeed enabled but disconnected. Changing the enabled port's mode to RAW and giving some file location as Path/Address resolved the issue, and the VM boots up normally.

This thread can be closed. Thank you for your responses.

[socratis]

Thank you for the response and the explanation. There was a rewrite of the serial port part and there were several issues. I'm glad that you finally got it going.

Marking as [Solved].