Closed IvanDL95 closed 10 months ago
I'm able to reproduce the same behavior on Fedora 38. I don't have a good answer here and open to suggestions.
I have half an idea to attempt libvirt support.
Try upgrading to Vagrant 2.4.0 which is currently working for me on Fedora 38 and VirtualBox Version 7.0.10 r158379 (Qt5.15.10)
Versions
Host operating system
Fedora 38 KDE
Summary
Starting the VM with Virtualbox as a provider doesn't start after a kernel upgrade. I had secure boot enabled and thought it could be that and did the MOK key signing again, as instructed by Virtualbox and done succesfully the first time, but it still froze even after disabling secure boot.
Not even destroying and recreating the VM solves the issue, it still hangs at the same point.
Details
Starting homestead VM via
vagrant up
freezes athomestead: Booting VM...
after a kernel upgrade. The terminal doesn't send any other important info. The virtualbox logs doesn't seem to provide much info, it just stays at a cache commit message and does nothing else.The old kernel was the one provided by default with a fresh fedora 38 installation (6.2.9) and after a big update I've got upgraded to 6.5.5, but had to lock to the old version because of this issue.
As I said before, I had secure boot enabled and enrolled the MOK key succesfully the first time. I attempted to sign a MOK key again because the initial setup config
/sbin/vboxconfg
complained that the module wasn't signed, but everything pointed at the kernel module working alright as virtualbox had no issue at trying to boot. Then I reinstalled virtualbox running the new kernel and did everything again but with secure boot disabled and I had the same result. After rebooting to the old one the homestead VM started like nothing happened.At this point I'm pretty sure VBox is at fault here, but I have no way to find out why it doesn't start because I don't get any meaningful error.
Homestead.yaml
Expected behavior
The VM should boot succesfully.
Actual behavior
Virtualbox hangs indefintely and never finishes. I have to abort the process.
Steps to reproduce
References
This issue happens in windows and I get same output:
Except I don't get the FAIL message (the poor guy probably has a problem with Windows Hyper-V, happened to me before) but an eternal wait instead. The error only shows up if I force quit by finishing the process eagerly (CTRL + C).