So it turns out this is a bit of a mess, but thankfully also an easy fix (for now…).
- Linux 6.12 takes control of virtualization features of the CPU even when no KVM virtual machines are running. This prevents VirtualBox VMs from running unless the kernel module option
kvm.enable_virt_at_load=0is set. Kicksecure previously set this option by default since it ships kernel 6.12. - Virtualbox 7.2.2 implemented a fix for this, but it only works with kernel 6.16.0 and higher. I did not realize there was a kernel version limitation here.
- VirtualBox later introduced a bug where trying to start a VM while
kvm.enable_virt_at_load=0was set would trigger a kernel panic. - In response, I submitted a change to Kicksecure that make
kvm.enable_virt_at_load=0no longer set by default, thinking that modern VirtualBox didn’t need it anymore. - Apparently no one noticed this was an issue until just recently? Maybe an older Debian kernel has the APIs from kernel 6.16.0 backported into it, but the most recent kernels don’t? I have no idea, but in any event, now we’re in a situation where VirtualBox VMs just don’t start.
As a temporary stop-gap solution, boot into a sysmaint session, run sudo nano /etc/modprobe.d/fix-vbox.conf, then type in options kvm enable_virt_at_load=0. Press Ctrl+S to save, press Ctrl+X to exit, and then reboot into a user session. VirtualBox should now work normally, as long as you have a new enough version of VirtualBox installed.
I’ll submit a change to re-add the option. Hopefully VirtualBox won’t start triggering kernel panics because of it again.