Latest Update Broke VirtualBox - No VMs Can Run

Just the other day, I installed a new 2TB NVME SSD into my system to hold my VMs.
I tested all the VMs to see if they would boot once they were moved over. No problems.
Today I tried to install TAILS in a VM. Nothing worked - got a variety of errors.
At first I assumed there was an issue with TAILS or the settings for it. I worked with Gemini to try to fix it, to no avail.
So I reverted to Google searches of the various error messages, which mostly concerned some sort of display issue, indicating that a display value was being creating which exceeded the size of the display.
In the process, I noted reports that some times when Oracle updates VirtualBox, there are issues with Linux, and that anything other than original Oracle Virtualbox is not supported in their forums.
So I got the idea to test my previously running VMs again.
None of them will boot - same issue as the TAILS VM.

I have to conclude that latest update broke Virtualbox.

I have no idea what to do about this situation, except uninstall and reinstall openSUSE VirtualBox since I assume Oracle VirtualBox won’t even install on openSUSE Tumbleweed.

Most likely the virtualbox-kmp wasn’t updated. Please show:
zypper se -i -v virtualbox-kmp

I just uninstalled it from Yast and reinstalled it.

Same issue. “Critical error”. If I “ignore” the Critical Error", the error panel on the right shows this error:

Failed to acquire display parameter.
Argument aWidth is invalid (must be aWidth != 0 && aWidth <= 32767).
Result Code:
NS_ERROR_INVALID_ARG (0x80070057)
Component:
DisplayWrap
Interface:
IDisplay {4680b2de-8690-11e9-b83d-5719e53cf1de}

zypper se -i -v virtualbox-kmp
Loading repository data...
Reading installed packages...

S  | Name                   | Type    | Version              | Arch   | Repository
---+------------------------+---------+----------------------+--------+---------------------------------
i  | virtualbox-kmp-default | package | 7.1.8_k6.15.0_1-1.10 | x86_64 | Main Repository (OSS) (20250414)
    name: virtualbox-kmp-default
i  | virtualbox-kmp-default | package | 7.1.8_k6.14.6_1-1.6  | x86_64 | (System Packages)
    name: virtualbox-kmp-default
i  | virtualbox-kmp-default | package | 7.1.8_k6.14.6_2-1.9  | x86_64 | (System Packages)
    name: virtualbox-kmp-default

Should I remove all but the .15 one?

No, these are for kernels you still have installed. So from GRUB you should be able to start the previous kernel.

FWIW, I left VBox years ago for the constant issues and went for virt-manager (KVM + qemu). Does the job fine and is in-kernel so no issues with out-of-kernel modules.

1 Like

I don’t see a particular need to boot to a previous kernel, as I’ve never done that in that past. So on advice of Gemini, I removed them, so the latest kmp matches the running version of VirtualBox.

Unfortunately, after a reboot, that has not changed the situation. None of the VMs will run still.

I’m not prepared to switch to KVM as a lot of VM advice is oriented to VirtualBox and VMWare. I have both VirtualBox and VMWare Workstation Pro installed (the latter just recently and I’m not using it at all.) I have five Windows VMs sinstalled and I’m trying to get some more installed prepatory to working on a computer security lab.

So this is a major PITA right now.

So now I tried VMWare Workstation Pro - and of course I have to “compile modules” - and of course they won’t compile - which means a new reinstall of VMWare.

So now I have ZERO virtual machine capability.

OK, if you trust Gemini to be a better source, I don’t see much reason to be on this thread

2 Likes

No where did I say anything about trusting Gemini to be a better source. I appreciate any advice anyone here gives me.

This is why people get tired of dealing with forums - people who are so thin-skinned that they have to feel insulted when someone doesn’t revere their advice.

Can we stick to the issue at hand, please?

Well, Gemini made you delete the option you had to boot a previous kernel. And FWIW, I don’t feel insulted at all, am pretty thick-skinned after 20+ years of moderatorship. I just don’t want to have to compete with whatever AI. That said, please cool down.

2 Likes

Right. Maybe others can help. Most likey they will ask for some output

1 Like

I have no interest in booting to a previous kernel just for this issue. I would prefer to determine if either I’ve made some dumb mistake or there is an issue with the latest update.

Looking at the changelog in Yast for VirtualBox, I see this;

Wed 16 Apr 2025 05:00:00 AM PDT
Jan Engelhardt jengelh@inai.de

  • Update to release 7.1.8
    • VMM: Fixed issue when VM clock went backwards in rare
      circumstances.
    • Graphics: Fixed issue when assertion was triggered on
      restoring VM state if VMSVGA graphics adapter was used
      without 3D acceleration.
    • Linux Guest Additions: Fixed issue when VBoxClient could
      crash in XWayland guest.
  • Delete kernel-6-14.patch (obsolete)

It looks like two graphics-related adjustments were made, so I wonder if either of them might have something to do with the issue. (I’m not running on Wayland, however.)

Then please come up with some output. Like:

  • Does the systemd service run?
  • Anything in the journal?
  • VBox logs maybe?
  • Start VBox from a terminal and look at the output?

VirtualBox itself appears to be running fine. The service is running.

I can post a log, but those things are huge. Here’s the paste link:
https://paste.opensuse.org/pastes/70c05516b437

A basic forum search would have brought up a thread, which explains that the VB version actually shipped in TW is not kernel 6.15 ready/compatible. The issue will be fixed in the next VB version.

1 Like

Sigh… That post was AFTER my earlier report…

As a “basic forum search” would have told you.

Can you please cool down a bit? We are not some paid call centre. So far you have dismissed any help, I am now wondering why you even ask here.

2 Likes

So a few things here:

  1. Yes, VirtualBox is currently not functioning because of the change to the 6.15 kernel. It’s not the only thing, as you noticed, VMware Workstation doesn’t build its modules either. I also found that the droidcam v4l2loopback module doesn’t work. 6.15 brings some changes that break some third party kernel modules. Having an older kernel available (which is the default for openSUSE installs generally) gives you an option to have a functional system without the latest and greatest kernel. The reality is that sometimes a new kernel breaks things that need to be fixed upstream, so if you need something that a new kernel breaks, you can use an older kernel to keep running.
  2. I run VMware Workstation, and while I can’t vouch for the fix, there patched code available on github. I don’t know the author and haven’t run a full security audit of their changes. That said, those modules are working for me. They may work for you. They are at GitHub - amadejkastelic/vmware-host-modules: Patches needed to build VMware (Player and Workstation) host modules against recent kernels (branch is 6_15). Like I said, they work for me, but I have not vetted the code changes, so you’ll have to decide for yourself if you want to use those or wait for VMware to catch up with their own code for the 6.15 kernel. The code is derived from modifications that were made for earlier kernel releases where the VMware modules wouldn’t work (fixes by mkubecek, who IIRC is a SUSE employee who took this on on his own).
  3. It is possible to migrate from VMware VMs to KVM - and I know you can also migrate from VirtualBox to VMware, so probably also can migrate to KVM. If you want the latest kernel and no headaches with third-party kernel module updates being broken, KVM is your best option, because it’s in-kernel.
2 Likes

I can also confirm that VirtualBox 7.1.8 is broken on tumbleweed with 6.15 kernel. I get this error when starting any virtual machine:

An error has occurred during virtual machine execution! The error details are shown below. You may try to correct the error and resume the virtual machine execution.



Unable to allocate and lock memory. The virtual machine will be paused. Please close applications to free up memory or close the VM.

Error ID:HostMemoryLow
Severity:Non-Fatal Error

Booting to 6.14.6-2 bypasses the error and allows the virtual machines to start.