Ubuntu no reboot in Virtualbox

Thanks for the quick heads up. I finally figured out that in the logs oracle setup a thing they call Guru Mediation. Under that log entry, it gave some clues about virtualization losing connection to the host and the CPU during the reboot call. I went to Bios, verified all set properly, Virtualization On, Windows 10 all HyperV stuff off, all virtualization off in OS.

Started VirtualBox, went to settings, and verified. Some issues found were passive, but may have caused other things to act up;

1). Make sure the USB settings match the hardware. Mine was on but not configured. It must be on to capture touchpad in laptop mode. Also, if there are listed devices that drop down from the Add Button, and that is your hardware, then add it for the VM to properly load the device(s). In my case, I was on the wrong Version (should be 2.0, not 3.0) and needed to add my USB controller (Realtek).

2). Check your storage devices in host OS and make sure that VirtualBox saw them right. In my case, it was not. Hint: Most newer devices now use SATA/AHCI controllers for all drives, but can pretend to be IDE or other type of controllers. So set that properly.

3). Here is the fix. After an hour of looking at the logs. For our device, your mileage may vary.

Go to settings, after a Guru Mediation failed reboot, in the VirtualBox Settings. Turn off (Uncheck), in the Processor Tab, Enable Nested VT-x/AMD-V. Uncheck it, but leave the setting above it active (Checked) Enable PAE/NX.

Next Tab, Acceleration, Make sure AMD has KVM active as Paravirtualization Interface, but uncheck Enable Nested Paging just below KVM.

Close VirtualBox, Start VirtualBox, make sure settings stay where you put them, then start Ubuntu Guest and, once running, check for updates/upgrades, then try reboot.

If it works, you should see the screen display in the upper area the hard drive info for the .efi boot files as the system reboots, then some screen resolution adjustments as the system restarts. Works good so far, and the drive emulation is faster with the proper controller running the files.

Hi Team,
Just a quick follow up. We all know this is an experiment in progress, so wanted to add a little note to this answer so as to clarify the fix a little more.

Once I used the system for a few days, windows started to lock down virtualbox as an executable. Device Guard and UAC controls reset on their own, and both virtualbox and ubuntu were being affected by the host. At no time did I receive an error from fTPm or Secure Boot, and Windows 10 operated normally. I added exclusions for UAC and host processes that were hooking virtualbox without disabling Device Guard, and that seemed to make Windows happy(?) with VirtualBox. Went to Ubuntu as guest, rebooted, and Crash!

OK, now I have sufficient logs in Ubuntu to see what was locking the OS. Here we go;

1) Alsa audio drivers: could not access the host or post to host system.

2) Graphics could not access certain memory locations in gpu and cpu to control display and memory locations (numerous).

3) USB devices could not talk to host (pci violations and lockouts for hardware)

So now what to try.... actionparsnip was correct, the biggest problem was 3D acceleration. Turned it off, then reboot the machine (All the way, host, vb, ubuntu) And ran the system. Perfect. All 3 of the above errors disappeared. It did slow down the interface somewhat, but if it stops the errors, then I would say that was the hangup. And I know just from years in the AMD family, this is a common problem. Maybe one day we can get a real open source gpu.

Thanks actionparsnip, that solved my question.

What are you doing in the VM that needs 3D acceleration? I don't recommend virtualization for gaming

Nothing at all. Just trying to speed up Ubuntu because of the VirtualBox interface. I know that hardware native access would be the fastest way to operate, but just trying different combinations.

Just the same, thanks for the help on this!

I looked at the Oracle website for VirtualBox, and I may send them a proper log set once I get a stable run for a month or so, just not yet. They are pretty much focused on VMWare (paid service) and I don't want to send out logs that are repetitive on common errors that they are already aware of, and I can only suppose that HP and Microsoft (main OS, hardware) will work to insure that only Hyper-V works properly, or WSL if you prefer a terminal experience (with their approval, of course).

If you aren't using 3D then it won't be any faster. The hardware you have will perform 2D things just as efficiently as if you enable 3D... There will be no difference

OK, I understand. Thank you.

Just as a heads up, Device Guard Reset again (Windows) on last reboot, and to verify it is across all linux virtual loads (mx_linux 19) I loaded a different system, and with 3D off but virtualization features turned on in VirtualBox, both OS systems crash on reboot.

Power off is OK, screen power and system power ACPI is working OK, but reboot is crashing to Guru Mediation in VirtualBox. I can only assume what the real culprit is, but the logs keep complaining about virtualization(s) (But never about KVM).

I know that the ICH9 drive controller (virtual) is, like all of the virtual filesets in VB experimental, so I can carefully tinker with these to see if turning off or changing machine state runs will allow reboot to work, but it seems like I can change a setting, then reboot is ok, then next day on power on for Windows Host the Device Guard runs fresh, sees VirtualBox, and when it starts, it is controlling the hardware path and feature access.

I don't think that will ever be fixed by them, what with TPM and Secure Boot and UEFI, etc.
P.S. Both OS loads in linux are using shim.efi/64/gpt. The installs were flawless.

Last message on the file. Contacted Oracle and sent logs because problems kept randomly popping up. They discovered that I had shared too much memory with the virtual machine. I had 8GB hard memory, and I was sharing 4GB. It was causing memory corruption in the VM. Reduced the memory to 3GB and now the reboots work properly, with all the bells and whistles turned on.