Fix Linux Mint Update Error Caused by VirtualBox DKMS

I recently tried to update Linux Mint through Update Manager. Most packages downloaded and installed normally, but the update ended with the following message:

installArchives() failed

The update report was very long and contained hundreds of successful package operations. The real problem appeared near the end, where Linux Mint tried to configure a new kernel and rebuild the VirtualBox kernel modules.

Building module:
make -j12 KERNELRELEASE=7.0.0-28-generic ...

Error! Bad return status for module build on kernel:
7.0.0-28-generic

dkms autoinstall on 7.0.0-28-generic/x86_64 failed
for virtualbox(10)

dpkg: error processing package
linux-headers-7.0.0-28-generic

The new Linux kernel was not the actual problem. The failure happened because an older VirtualBox 7.0.16 installation could not compile its kernel modules for the new 7.0.0-28-generic kernel.

Because DKMS runs automatically while a new kernel is being installed, the VirtualBox build failure interrupted the configuration of several kernel packages. This made Update Manager report that the entire update had failed, even though most packages had already been installed successfully.

This guide explains how the problem was diagnosed and fixed, step by step.

What caused the Linux Mint update failure?

VirtualBox needs kernel-level drivers to run virtual machines. The main VirtualBox host modules include:

vboxdrv — the main VirtualBox kernel driver
vboxnetflt — used for bridged and filtered networking
vboxnetadp — used for host-only network adapters

These modules must match the Linux kernel currently running on the computer. When Linux Mint installs a new kernel, DKMS normally rebuilds third-party modules automatically.

In this case, Linux Mint installed kernel 7.0.0-28-generic. The old VirtualBox 7.0.16 module source could not build against that kernel, so DKMS returned an error.

The following packages were consequently left unconfigured:

linux-headers-7.0.0-28-generic
linux-headers-generic-hwe-24.04
linux-generic-hwe-24.04
linux-image-7.0.0-28-generic

The correct solution was not to remove the new kernel. The correct solution was to remove the incompatible VirtualBox version, finish configuring the interrupted packages, and then install a newer VirtualBox release.

How to recognize this specific error

The installArchives() failed message is only a general Update Manager error. It does not identify the package that caused the failure.

Look near the bottom of the update report for lines containing terms such as:

Error!
dkms autoinstall failed
Bad return status for module build
dpkg: error processing package
virtualbox

You can also inspect the most recent APT terminal log:

grep -Ei 'virtualbox|dkms|error|failed' /var/log/apt/term.log | tail -n 100

When the report shows that a VirtualBox module failed while Linux was configuring kernel headers or a kernel image, this guide is relevant.

Before starting the repair

Do not panic if the update report is long. In this case, core packages such as PHP, Apache, Firefox, LibreOffice, Cinnamon and the Linux kernel had already been unpacked or configured. Only the VirtualBox module build and dependent kernel package configuration failed.

Do not immediately remove kernel packages. The kernel itself may be working correctly. First remove or upgrade the third-party module that failed to build.

If you have not rebooted yet, repair the package state first. If you already rebooted and Linux Mint starts normally, you can still follow the same repair process.

Step 1: Check the currently running kernel

Open Terminal and run:

uname -r

Before the reboot, the system may still be running the previous kernel. After the repair and reboot, it should report the newly installed kernel.

In this case, the target kernel was:

7.0.0-28-generic

Your version may be different. Use the kernel version shown in your own update report.

Step 2: Check which VirtualBox packages are installed

Before removing anything, list the installed VirtualBox and DKMS packages:

dpkg -l | grep -Ei 'virtualbox|dkms'

This helps you identify whether VirtualBox came from the Linux Mint or Ubuntu repository, an Oracle package, or another source.

The failing update used VirtualBox 7.0.16. That version had registered a DKMS module which could not compile for the new kernel.

Step 3: Protect existing virtual machines

Removing the VirtualBox application does not normally delete virtual machine files. However, important virtual machines should always be backed up before changing virtualization software.

VirtualBox commonly stores machines in:

~/VirtualBox VMs/

Check whether that directory exists:

ls -lah ~/VirtualBox\ VMs/

If it contains important machines, copy the directory to another drive or backup location. Do not manually delete it during this repair.

It is also sensible to create a Timeshift snapshot before making major package changes, provided the system is currently stable enough to do so.

Step 4: Remove the incompatible VirtualBox installation

Remove the old repository-based VirtualBox packages:

sudo apt purge virtualbox virtualbox-dkms virtualbox-qt

If you installed VirtualBox directly from Oracle and the package is named virtualbox-7.0, remove it with:

sudo apt purge virtualbox-7.0

Use the package list from the previous step to determine which command applies to your system.

APT may report that one or more package names are not installed. That is harmless. The important requirement is to remove the package that registered the incompatible VirtualBox kernel module.

Afterward, remove packages that are no longer needed:

sudo apt autoremove

Step 5: Finish configuring interrupted packages

Now ask dpkg to continue configuring packages that were unpacked but left incomplete:

sudo dpkg --configure -a

This is one of the most important commands in the repair. The failed VirtualBox module is no longer present, so the kernel packages should now configure normally.

Next, repair any broken dependencies:

sudo apt --fix-broken install

Refresh the repository information:

sudo apt update

Then complete the remaining upgrades:

sudo apt full-upgrade

The old VirtualBox 7.0.16 build error should no longer appear.

Step 6: Check whether the package system is healthy

Run the following command:

sudo dpkg --audit

A healthy system normally produces no output. If it lists packages, run the configuration and broken-dependency commands again:

sudo dpkg --configure -a
sudo apt --fix-broken install

Step 7: Verify the new kernel files

Before rebooting, confirm that the kernel image and initramfs exist.

For kernel 7.0.0-28-generic, the commands were:

ls -lh /boot/vmlinuz-7.0.0-28-generic
ls -lh /boot/initrd.img-7.0.0-28-generic

Replace the version with the kernel shown in your own update report.

If the initramfs file exists, refresh it with:

sudo update-initramfs -u -k 7.0.0-28-generic

If the initramfs file is missing, create it instead:

sudo update-initramfs -c -k 7.0.0-28-generic

Finally, rebuild the GRUB boot menu:

sudo update-grub

Step 8: Reboot into the new kernel

After all package commands finish without errors, reboot Linux Mint:

sudo reboot

After logging in again, verify the active kernel:

uname -r

The repaired system returned:

7.0.0-28-generic

This confirmed that Linux Mint had successfully booted with the new kernel.

Step 9: Install a newer VirtualBox release

Do not reinstall the same VirtualBox version that failed to compile. Install a newer release that supports the new Linux kernel.

For Linux Mint 22.x, the relevant Oracle package is normally the Ubuntu 24.04, or Noble, AMD64 build.

Choose the current supported VirtualBox release.
Select Ubuntu 24.04 or Noble.
Select AMD64 for a standard 64-bit Intel or AMD computer.
Download the package only from the official Oracle VirtualBox website.

After downloading it, open Terminal and enter the Downloads directory:

cd ~/Downloads

Confirm that the installer is present:

ls -lh *.deb

In this case, the downloaded package was:

virtualbox-7.2_7.2.12-174389~Ubuntu~noble_amd64.deb

The exact version and build number will change over time. Install the filename that actually exists in your Downloads directory.

Fixing the “Unsupported file” installation error

An initial attempt to install VirtualBox used this command:

sudo apt install ./virtualbox-7.2_*.deb

APT returned:

E: Unsupported file ./virtualbox-7.2_*.deb given on commandline

This did not mean that APT could not install VirtualBox. It meant that no file matched the wildcard.

The following command confirmed that no Debian package had been downloaded:

ls -lh *.deb

The result was:

ls: cannot access '*.deb': No such file or directory

When a shell wildcard does not match any file, the original wildcard text may be passed to APT. APT then reports it as an unsupported file.

Always confirm that the installer exists before running the installation command.

Step 10: Install the downloaded VirtualBox package

Install the package using its exact filename:

sudo apt install ./virtualbox-7.2_7.2.12-174389~Ubuntu~noble_amd64.deb

Replace that filename with the package you downloaded.

You can type the first few characters of the filename and press the Tab key to let the shell complete it.

After installation, verify the version:

VBoxManage --version

The working installation returned:

7.2.12r174389

Step 11: Build the VirtualBox modules

Build the VirtualBox kernel modules for the currently running kernel:

sudo /sbin/vboxconfig

The successful output looked like this:

vboxdrv.sh: Stopping VirtualBox services.
vboxdrv.sh: Starting VirtualBox services.
vboxdrv.sh: Building VirtualBox kernel modules.

No compilation error appeared afterward. This confirmed that the newer VirtualBox release could build against kernel 7.0.0-28-generic.

Step 12: Verify the VirtualBox kernel drivers

Check which VirtualBox modules are loaded:

lsmod | grep '^vbox'

The repaired system showed:

vboxnetadp             28672  0
vboxnetflt             40960  0
vboxdrv               720896  2 vboxnetadp,vboxnetflt

This confirmed that the three required VirtualBox modules were loaded.

Also check the VirtualBox device node:

ls -l /dev/vboxdrv

The working result was similar to:

crw------- 1 root root 10, 262 Aug 3 04:06 /dev/vboxdrv

If vboxdrv is loaded and /dev/vboxdrv exists, the VirtualBox host driver is active.

Why can “dkms status” be empty?

You may run:

dkms status

In this case, the command returned no output after Oracle VirtualBox 7.2 was installed.

An empty result did not mean that VirtualBox was broken. The Oracle package had successfully built and loaded its modules through its own configuration process.

The more useful checks were:

sudo /sbin/vboxconfig
lsmod | grep '^vbox'
ls -l /dev/vboxdrv

Because the modules were built, loaded and connected to the device node, VirtualBox was working correctly.

Why does “VBoxManage list vms” show nothing?

To list registered virtual machines, run:

VBoxManage list vms

If the command returns no output, it usually means that no virtual machines are currently registered for that Linux user.

It does not indicate a failed VirtualBox installation.

Check whether existing virtual machine folders are still present:

ls -lah ~/VirtualBox\ VMs/

If a machine folder exists but does not appear in VirtualBox, open VirtualBox and add its .vbox file.

Final Linux Mint and VirtualBox health check

Run the following commands one final time:

sudo dpkg --audit
sudo apt --fix-broken install
sudo apt update
sudo apt full-upgrade

Then verify the active kernel and VirtualBox installation:

uname -r
VBoxManage --version
lsmod | grep '^vbox'
ls -l /dev/vboxdrv

The repaired system confirmed:

Kernel 7.0.0-28-generic was running.
VirtualBox 7.2.12r174389 was installed.
vboxdrv, vboxnetflt and vboxnetadp were loaded.
/dev/vboxdrv existed.
No broken package state remained.

What to do if VirtualBox modules still fail to build

If sudo /sbin/vboxconfig still fails, first confirm that the headers for the running kernel are installed:

sudo apt install build-essential linux-headers-$(uname -r)

Then run the configuration command again:

sudo /sbin/vboxconfig

If it still fails, inspect the build output or relevant log file. The exact location can vary depending on how VirtualBox was installed.

For a DKMS-managed installation, a common location is:

/var/lib/dkms/virtualbox/<version>/build/make.log

Should you disable Secure Boot?

Do not disable Secure Boot simply because a DKMS build failed.

A compilation failure and a Secure Boot rejection are different problems:

A compilation failure means the module source could not be built for the kernel.
A Secure Boot problem normally happens after a module builds but Linux refuses to load it because the module is unsigned or its key is not trusted.

In this case, the old VirtualBox source failed during compilation. Disabling Secure Boot would not have made that source compatible with the new kernel.

Only investigate Secure Boot if the module builds successfully but does not load. You can check its state with:

mokutil --sb-state

What if Linux Mint does not boot with the new kernel?

Linux Mint normally keeps older kernels installed when a new kernel is added. If the new kernel does not boot, open the GRUB menu and choose:

Advanced options for Linux Mint
A previously working kernel

After booting the older kernel, repair the package state and investigate the failed kernel or third-party module before trying again.

Harmless warnings that were not the cause

The update log also contained several Python SyntaxWarning messages from HPLIP files.

Those warnings were unrelated to the failed update. They did not stop package configuration.

The important failure was clearly identified by these lines:

dkms autoinstall failed for virtualbox
Error! Bad return status for module build
dpkg: error processing package linux-headers

When reading a long update report, focus on the final errors and the package names connected to them. Earlier warnings are not always responsible for the failed operation.

Frequently asked questions

Does removing VirtualBox delete my virtual machines?

Removing the application package does not normally delete machines stored in ~/VirtualBox VMs/. However, backing up important virtual machines before changing VirtualBox is strongly recommended.

Why did Update Manager say the whole update failed?

Update Manager reported the final package-management result. Most packages installed successfully, but the VirtualBox DKMS error prevented several kernel packages from completing their configuration.

Should I remove the new kernel?

Not as the first repair step. The kernel was not the source of the failure. The incompatible VirtualBox module was the component that failed to build.

Can I reinstall the same VirtualBox version?

Reinstalling the same incompatible version may cause the same error. Install a release that supports the kernel you are using.

Is an empty “dkms status” result a problem?

Not necessarily. Verify whether the VirtualBox modules are loaded and whether /dev/vboxdrv exists. Those checks confirmed that the Oracle VirtualBox installation was working in this case.

Conclusion

A Linux Mint update can fail when an older VirtualBox release cannot compile its external kernel modules for a newly installed kernel.

The error may leave the Linux image, kernel headers and HWE metapackages only partially configured. However, this does not necessarily mean that the new kernel is defective or that Linux Mint must be reinstalled.

The successful repair process was:

Identify the VirtualBox DKMS failure in the update log.
Back up important virtual machines.
Remove the incompatible VirtualBox version.
Finish package configuration with dpkg --configure -a.
Repair dependencies with apt --fix-broken install.
Complete the Linux Mint update.
Verify the kernel image and initramfs.
Reboot into the new kernel.
Install a newer VirtualBox release.
Run /sbin/vboxconfig.
Verify that the VirtualBox modules are loaded.

After following these steps, Linux Mint successfully booted with kernel 7.0.0-28-generic, and VirtualBox 7.2.12 loaded all required host modules correctly.

Find an article