From the credible – to the unlikely – to success. A quick war story today: When I recently created a new Ubuntu 26.04 system from scratch for use as my primary OS on my notebook, I waited with one thing until the end: Installing Virtualbox. Not that I was of the complexity, it is actually straight forward. However, I did most of the apps and tools installation and the configuration for it in a virtual machine, and only moved the installation to a real notebook once I was almost done. Much more comfortable to do it this way. So one of the last tasks was to install Virtualbox, since that is, of course, best run on physical hardware. While things looked good at first and all my virtual machines ran as they should, including the USB mapping into the VMs for some special tasks, I soon noticed I had a big problem: In 80% of the cases where I suspended and resumed the notebook by closing the lid, my virtual machines would crash after resume. Totally reproducible. What a nice surprise at the end of a week long process.
First Try
So I started to search the web with a (paid for) AI assistant I use a lot these days and it suggested that the problem might be KVM kernel modules, which Virtualbox was using for some things since Virtualbox release 7. At least that’s what the AI agent said. It sounded credible. So I blocked the KVM kernel modules as described. Unfortunately, I didn’t help. I kept asking the chatbot, but the plans the AI had for fixing this started getting a bit surreal.
Let’s Try Again – Differently
So at some point I decided to go for the most expensive option and used GPT Codex 5.3 with the same initial prompt. And this agent went straight to a completely different suggestion: The VM is actually not crashing, it’s an incompatibility of Ubuntu 26.04 and the QT6 packages that are bundled inside Virtualbox 7.2.14.
The fix: Setting a shell variable to disable a particular Virtualbox functionality. That didn’t sound very credible and while the content behind the link provided to the Github issue discussion looked good, the issue itself was already open for half a year with nobody really working on a permanent fix. So could this really be my issue?
I gave it a try with the following: First, the non persistent fix: Start Virtualbox form the shell as follows and then start the virtual machines:
VBOX_DESKTOPWATCHDOGPOLICY_SYNTHTEST=Disabled VirtualBoxAnd that’s it, no more VM crashes on suspend/resume! Unbelievable, but it really worked!
I then went ahead and made this startup persistent as suggested by the AI assistant as follows:
mkdir -p ~/.config/environment.d
printf 'VBOX_DESKTOPWATCHDOGPOLICY_SYNTHTEST=Disabled\n' > ~/.config/environment.d/virtualbox.conf
# now reboot, done!And there we go, no crashes anymore after suspend/resume. Not a single one! Sometimes I am just baffled… I then ran a ‘normal’ web search after the fact to see if I would have found it without an AI agent. Yes, I could have, but the fix was far far down the result list.
P.S.: Speaking about costly which might be a ‘slight’ exaggeration: I use GPT Codex 5.3 via Openrouter on a per token basis and the fix cost $0.14…