Vboxdrv Key Was Rejected By Service
Francisca Noggles
During startup, vboxdrv.service fails. The tty starts fine, I can do everything inside it. However, startx leads to what I believe to be the normal stdout, but after that, nothing happens, I have no graphical interface, my i3wm does not start.
EDIT: I have updated the machine again (it asked me whether I want to replace virtualbox-guest-modules with linux, I gladly agreed in hope of fixing the problem with the update, but behaviour stays the same), new pacman -Qs virtualbox:
If I build my own kernel with signed modules, I have the key, dkms builds the virtualbox modules on my laptop which has the kernel source and my signing key.Can you enhance the dkms script to use /usr/src/linux-xxx/signing_key.* and sign the modules if those files are present?
The above unit is meant to be executed before vboxdrv.service (i.e. before the VirtualBox startup service is run), and be required by it (i.e. can't load the service if driver sigining fails).
All that said, grafting a modified version of the above code into the '/usr/lib/virtualbox/vboxdrv.sh' script to be executed during module installation (check to see if signed, if not then sign) and compilation (sign immediately after compiling) would also do the trick.
So, for now, you can use the above workaround. This should work fine in other Linux distributions that also use systemd and mokutil. Please note that the path that the service unit needs to be created in may change for different Linux distributions.
Part of the problem is that any automatic way to sign kernel modules is probably only marginally safer than disabling signing altogether. Of course, it is hard to say for sure, just as it is hard to say for sure how much security benefit signing modules even provides, particularly on a desktop system.
This is fixed for Ubuntu as of the current (they will be available in 30 minutes or so) 6.0 and trunk test builds. The reason it was possible to do it for Ubuntu is that they already provide a mechanism of their own for use with DKMS modules. The problems I mentioned in my last comment still apply, but since Ubuntu has decided to provide this themselves this was their decision not ours.
A suggestion for anyone who wants this fixed for other host distributions: ask your distributions to provide a mechanism we can use. If the mechanism is compatible with Ubuntu's one then it will be automatically supported, as we only check for the mechanism, not the distribution.
After further testing, my problem is the same as #14, except that my computer has the correct files. The problem is that (for whatever reason) it's not enrolled, cutting me off with the same unconditional "return 0".
Yes. Indeed, I have a some issue with drivers of virtualbox 6.0.10. I solved the updated issue of linux-headers for VBox 6.0.10 but I am problem with drivers. The OS I using is Ubuntu 18.04 Bionic at x64.How must I proceed? The virtualBox open, compile but not running. My hardware architecture is a Intel i5 with UEFI.
In the interface of VBox show the other one joint that information - you're use EFI SECURE BOOT. Yes, indeed, it onboard my architecture. The news architectures are coming with this UEFI secure boot. But I did try off that and the VBox following reporting me about Error: KERNEL DRIVE NOT INSTALLED (rc=1908)
The ticket says that this is specifically fixed for recent Ubuntu and Debian10 installations, it doesn't cover everything. Does OpenSUSE provide the infrastructure required, as this was laid out by 'michael' on comments 10 and especially 12?
This is fixed for Ubuntu as of the current 6.0 and trunk test builds. The reason it was possible to do it for Ubuntu is that they already provide a mechanism of their own for use with DKMS modules. The problems I mentioned in my last comment still apply, but since Ubuntu has decided to provide this themselves this was their decision not ours.
I think I would count this as the same problem if the system is using secure boot and the kernel modules now fail to build, and if removing the two "return 0" lines from /sbin/rcvboxdrv as pointed out in zardoz's patch fix the problem.
Commenting the return 0 in /usr/lib/virtualbox/vboxdrv.sh line 280 helped me out in that the script at least compiled the kernel modules. Since I already had some module signing script in place and using it for months I was not interested in fixing this part of vboxdrv.sh.
Here is a slightly other situation: I am running a vanilla Ubuntu 18.04 with Secure Boot enabled in BIOS. This is a stock Ubuntu kernel and I have *not* set up anything for signing self compiled modules, and I don't *want* to do that unless I'm forced to. VirtualBox installed from official repo just worked out-of-the box until 6.0.8, and with those changes in 6.0.10 it tried to force me into creating and enrolling signing keys.
The problem seems to be that vboxdrv.sh only checks the output of "mokutil --sb-state" to decide if it needs to create/enroll a key and kmodsign the modules. In my case mokutil prints "SecureBoot enabled", but everything is working fine *without* signing! I think vboxdrv.sh needs to check something else in addition to "mokutil --sb-state" to make sure it is *really* neccessary to mess around with UEFI variables.
I fixed that by moving the "return 0" from line 280 to line 493, right before the signing procedure. BTW, that "update-secureboot-policy --new-key" curses tool has *no* way to cancel. Had to kill it manually.
I effectively reverted and everything is working fine for me. Don't need self signed modules and don't want them. Especially since it does not provide any significant security benefit when the key is right there on the target system...
The module signing tool to be run at a build. Two arguments will be passed to the signing tool. The first argument is the target kernel version, the second is the module file path. If the tool exits with a non-zero value, the build will be aborted.
My partner just ran into an issue after updating his SteamDeck to the latest SteamOS version (3.4.x to 3.5.7).He has a dual boot setup running using rEFInd, and while that survived the OS update just fine, when he wanted to return to SteamOS after a quick stint in Windows today, he was greeted by a GRUB boot menu.Detective foosel to the rescue.Attempting to boot the SteamOS entry in grub resulted in an error like this (with another device UUID):...
I recently did a software update on my laptop running Fedora 38, and that also brought in a kernel update. Starting my Win10 VirtualBox VM afterwards no longer worked as it needed the kernel module to be recompiled. However, that failed:$ sudo /sbin/vboxconfig [sudo] password for gina: vboxdrv.sh: Stopping VirtualBox services. depmod: WARNING: could not open modules.order at /lib/modules/6.3.8-200.fc38.x86_64: No such file or directory depmod: WARNING: could not open modules....
For accounting and some windows only software (? Affinity Designer) I have a Windows 10 VM running in VirtualBox on my Framework running Fedora 38. Apparently I got a kernel update recently and as of this morning the VM refused to start. It just hung, and a look into journalctl showed something like this:Jun 13 10:23:50 draper kernel: traps: Missing ENDBR: 0xffff9b688c308f30 After some searching I came across this thread on the VirtualBox forums which explained the issue and also includes the solution....
Update:
I uninstalled everything again. I also uninstalled my virus scanner. Then I re-installed the Docker Toolbox and started the Docker Quickstart Terminal and it worked!
Next, I followed the instructions here to edit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VBoxDrv in the registry from 1 to 3 before rebooting. Then I rebooted.
After rebooting Docker Quickstart Terminal no longer works and produces the error:
Update 2:
It turned out I first had to run sc.exe start vboxdrv in the Windows Command Prompt, before running the Docker Quickstart Terminal. Now it works, also after reboot. So the following worked for me: