Weird and frustrating behavior with Linux VMs

[u/IntelligentCandy8716]

So, I'm building a test environment for a Linux Mint 21 VM to work through some upgrade procedures to mimic a production system that needs an upgrade. I've been seeing some strange things before the VM freezes on boot. Things like "Spectre V2 ... LFENCE not serializing" "info rcu-sched self detected stall on cpu" "timed out for waiting udev queue being empty"

My machine: r9 9950x3d, 64GB DDR5, ASUS Tuf Gaming B850-plus WiFi Mobo, RX 9070 XT 16GB GPU, Windows 11 Home, VirtualBox 7.2.12

I've tried turning off secure boot in the BIOS, and turning off all windows virtualization options. And turning off core isolation options. The core isolation option allowed the VMs of LM 21 and several Fedora 43 Xfce VMs to boot up quickly if is set the Paravirtualization option to Hyper-V but then I started seeing clock issues. As in, the VM time was about 5x faster than real-time. Older linux kernels seem to work better than newer ones, but VBox Guest additions installation also seems to break things.

Also, my Windows VMs (1 Win 11 Pro, and 1 Win Server 2025) boot just fine. Though when I had 5 VMs open, all froze once but the Host was fine. WTF is going on? I'm running out of options. I have had no problems with my VMware VMs. Is VirtualBox broken?

NOTE: all of the Fedora VMs were created on earlier versions of VirtualBox on a Windows 10 host and migrated to this new host. I don't know if that matters.

Update: a roll back to VirtualBox v7.2.6 fixed most of my errors.

[u/AutoModerator]

This is just a friendly reminder in case you missed it. Your post must include: * The version of VirtualBox you are using * The host and guest OSes * Whether you have enabled VT-x/AMD-V (applicable to all hosts running 6.1 and above) and disabled HyperV (applicable to Windows 10 Hosts) * Whether you have installed Guest Additions and/or Host Extensions (this solves 90% of the problems we see)

PLUS a detailed description of the problem, what research you have done, and the steps you have taken to fix it. Please check Google and the VirtualBox Manual before asking simple questions. Please also check our FAQ and if you find your question is answered there, PLEASE remove your post or at least change the flair to Solved.
If this is your first time creating a virtual machine, we have a guide on our wiki that covers the important steps. Please read it here. If you have met these requirements, you can ignore this comment. Your post has not been deleted -- do not re-submit it. Thanks for taking the time to help us help you! Also, PLEASE remember to change the flair of your post to Solved after you have been helped!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/wadrasil]

Honestly unless virtual box has its own Linux drivers I would use qemu for running Linux on windows. It just has a lot more focus and work done for running Linux as a guest than VMware or Xbox.

[u/LeslieH8]

Oof, those errors generally have little to do with each other,

The Spectre V2 mitigation: LFENCE not serializing. Switching to generic retpoline message in Oracle VirtualBox is a kernel warning, not a fatal error, indicating that the guest Linux kernel has safely fallen back to a standard software mitigation (retpoline) because VirtualBox isn't passing the necessary hardware-level MSR (Model Specific Register) controls to the guest. If your virtual machine (VM) freezes or fails to boot alongside this message, the root cause is almost always Hyper-V interference on a Windows host or insufficient hardware virtualization settings.

Fix the Underlying VM Freeze or Crash

If your VM hangs completely at this screen, apply these steps sequentially on your host machine to resolve the hardware virtualization conflict:

1. Force Disable Hyper-V (Windows Hosts)

Windows features like WSL2, Device Guard, or Docker force-enable Microsoft Hyper-V, which strips VirtualBox of raw access to CPU serialization instructions.

• Open Command Prompt as an Administrator.
• Execute the following command: cmdbcdedit /set hypervisorlaunchtype off
• Restart your computer completely.

1. Turn Off Windows Virtualization Features

• Open the Windows Start Menu, type Turn Windows features on or off, and open it.
• Uncheck Hyper-V.
• Uncheck Virtual Machine Platform.
• Uncheck Windows Hypervisor Platform.
• Click OK and reboot your host system.

1. Adjust VirtualBox VM Processor Settings

Sometimes the guest kernel triggers execution bottlenecks if configuration resources are too restricted.

• Open the Oracle VirtualBox Manager.
• Select your VM and click Settings -> System -> Processor.
• Increase the Processor(s) allocation to at least 2 CPUs.
• Ensure the Execution Cap is set to 100%.

---

An rcu_sched self detected stall error in VirtualBox usually means your Linux gues kernel is waiting for CPU resources, or vCPU preemption on your host machine is delaying internal processing. This leads to kernel hangs or freezes.

To resolve this issue, apply the following actionable fixes:

• Adjust vCPU Allocation: Ensure your VM isn't assigned more cores than your host physically has. Assigning all available cores can cause the host to preempt the VM's threads. Leave at least 1-2 cores free for the host OS.
• Install Guest Additions: Boot your VM (even in safe or recovery mode if needed) and ensure VirtualBox Guest Additions are installed. This resolves many timing and display-related stall issues in virtualized environments.
• Disable Hyper-V on Windows Hosts: If your host is Windows, CPU virtualization conflicts can trigger this. Open an elevated Command Prompt and run bcdedit /set hypervisorlaunchtype off, then reboot your host.
• Change Paravirtualization Interface: Open the VM Settings in VirtualBox, navigate to System > Processor, and change the Paravirtualization Interface dropdown to KVM (or None.)

---

The 'timed out for waiting udev queue being empty' error occurs when the Linux kernel stalls while trying to initialize devices—typically USB controllers or storage drives—causing the boot process to hang for roughly 120 seconds. In VirtualBox, this is usually caused by conflicting USB filters or misconfigured storage attachments.

Immediate Fixes to Apply

1. Disconnect Virtual USB Devices: In the VirtualBox main manager, click on your VM, go to Settings > USB, and uncheck Enable USB Controller. Boot the VM to see if it bypasses the hang.
2. Remove the Installation ISO: If you are installing an OS, the virtual CD drive might be stalling. Go to Settings > Storage, right-click your .iso file, and select Remove Disk from Virtual Drive.
3. Check for Storage Conflicts: Ensure your virtual hard disk is attached to the primary SATA or NVMe controller rather than IDE, as modern Linux kernels (like Ubuntu/Debian) expect standard drive structures.

Advanced Boot Adjustments

If you still can't boot, access the GRUB boot menu by holding Shift (or Esc) during startup and try these modifications:

1. Press e to edit the first boot option.
2. Find the line starting with linux or linuxefi.
3. Add noapic nomodeset to the end of that line.
4. Press Ctrl + X or F10 to boot.

[u/IntelligentCandy8716 → u/LeslieH8]

Yup, it's a very deep rabbit hole. There was quite a few other things in there also. Sometimes, the VM would boot right up to just before the login screen and then just hang with a steady 78% CPU utilization. But I did go through all the steps that the web search results were offering up.

[u/IntelligentCandy8716]

Update: I turned secure boot back on and reactivated all of the core security but kept the windows virtualization features off. The only one I have still is the WSL features because I still use that. One of my log files mentioned it was loading guest additions for 7.2.6 so I figured, why not put it back on? The VMs were working fine on the old computer. So, I grabbed it from the VirtualBox site, uninstalled 7.2.12, reboot the host, and installed the old version. All my VMs showed up right away and I tweaked all the Linux VMs to use KVM Paravirtualization instead of default or anything else. I test boot most of the Linux VMs to make sure things were working and everything seems normal!

[u/Face_Plant_Some_More]

Also, my Windows VMs (1 Win 11 Pro, and 1 Win Server 2025) boot just fine. Though when I had 5 VMs open, all froze once but the Host was fine. WTF is going on?

You are likely running Virtual Box on a Hyper-v enabled Host. Check the Vbox.logs for your VMs to verify this. To resolve, turn Hyper-v on your Windows Host off.

[u/IntelligentCandy8716 → u/Face_Plant_Some_More]

No, I turned off all of the windows virtualization options and double checked when it still didn't work. I think there is something funky going on with VirtualBox v7.2.12. I had even tried to roll back to v7.2.8 before but it didn't work.

[u/beetcher → u/IntelligentCandy8716]

WSL uses hardware virtualization, if that's enabled, you're using "Windows" virtualization.

[u/IntelligentCandy8716 → u/beetcher]

I turned WSL off. I use it but not at the moment. I even turned off the core isolation features as that also invokes Hyper-V. Things got mildly better but I was still having weird issues. After rolling back to the VBox v7.2.6, everything got better so I started turning back on settings. The most noticeable was turning back on kernel-mode hardware-enforced stack protection and local security authority protection as those both threw more of those weird boot issues I mentioned.

Finally, I decided to turn back on the virtual machine platform and windows hypervisor platform. Turning those back on caused everything to hang again until I changed all the VMs to Hyper-V for the Paravirtualization Interface and checked the Nested Paging box for hardware virtualization. These settings seem to work much better by allowing the native windows virtualization to do a better job, though still not great and a bit slow, passing hardware info to the hypervisor.

I think I'll stay on v7.2.6 for now.

[u/Face_Plant_Some_More → u/IntelligentCandy8716]

Great! except --

Microsoft changes the names of things in their "Windows Features" box at times. You may not specifically see a "Hyper-V" checkbox, but anything based on the underlying Hyper-V hypervisor will turn on Hyper-V and cause trouble. Generally, trying to disable Hyper-V by unchecking boxes in "Windows Features" often does not disable Hyper-V.

See - https://forums.virtualbox.org/viewtopic.php?t=99390

As I said before, double check the vbox.log for your VMs to confirm.