Problem Description:
VirtualBox appears to sense that I accidentally loaded Xubuntu 26.04 on Dell hardware that came set for SecureBoot UEFI from the factory. (Factory preload was Ubuntu 24.04, which I completely wiped.)
Now the VirtualBox package is not completely happy. When I was installing the VirtualBox package (official latest from Oracle) then it complained something about setting a password. That freaked me out. I did not want any further passwords that the Xfce login on this system. I managed to cancel / bomb out of the prompt. Next time I did an IPL of the system, a black screen with white text appears ahead of the Grub menu again asking me to set a password. aaaakkk!!! I managed to cancel out of that screen, dropped me to the Grub menu. Another IPL, and that time no password question, instead the usual straight to the Grub menu.
If we now turn off in the Dell BIOS SecureBooot and just drop back to (I assume) EFI boot…. is that going to render Xubuntu on the drive not bootable since Xubuntu expects the BIOS to be in SecureBoot EFI mode?
When I did the reload then to get a bootable drive I allowed Xubuntu 26.04 to lay down its preferred partition scheme, which was:
EFI partition of 1GB
ext4 partition for / the rest of the SSD
I then changed the ext4 root partition to xfs, left the EFI partition alone. I have used xfs format as my preferred Linux format since 2004…. not changing any time soon.
We only started suspecting something further wrong when we moved the first VM image to the new system. VB will not start the VM. It complains that VB is not completely installed correctly, and mentions if SecureBoot then more complicated steps are needed. aaaakkkk!!! I hate the mess booting the operating system has become.
What you saw was most likely mokutil (MOK = Machine Owner Key), when installing VB, and MOK Manager in the pre-exec (PE) boot environment. VB, IIRC, requires some DKMS module(s) and those need to be signed for Secure Boot (SB) to accept them. MOK updates require physical presence. The way to check that, is, to set a password at install time and ask same at boot time, when the key enrollment is committed. That should only happen once; it’s actually DKMS setting this all up for locally compiled modules.
There should be no need at all to either disable SB nor should doing so negatively impact Xubuntu; you’ll lose boot code authentication, though, if going with the latter.
For the deployment environment, “one more password layer” seems unnecessary and excessive.
This is not an enterprise size client. So I see the nag of a password as “one more thing to forget / loose” and then that causes issues in the future.
I will try to talk through on the phone navigating in the Dell BIOS to shut off the SecureBoot. Thank you for replying that doing so should not hurt Xubuntu’s ability to boot.
Well, those are the requirements of Secure Boot; if you want it, bite the bullet. Or try setting an empty password, see if that works; I think, it just might.
Well, things for this system seem to have gotten even worse….
When we shipped the system to the client, it was correctly pausing at the Grub boot menu for the 10 second count down. Now for the client it is skipping the Grub menu! gggaaa!!!
So, tea-for-one, you unfortunately hit the next nail squarely on the head!
For Grub configuration, I apply these hand fix edits:
#Set a monochromatic theme for Tanglu/Ubuntu.
echo “${1}set menu_color_normal=cyan/blue”
echo “${1}set menu_color_highlight=white/blue”
(I prefer the Debian colors)
These settings were all still in place, so I instructed to sudo update-grub and IPL. The system refuses to pause at Grub, to show Grub at all.
So yes, the only way I knew how to get into the BIOS of new fancy SecureBoot / EFI systems was to select the Grub menu selection, somehow Grub knows how to launch into the motherboard BIOS on such systems.
We have tried pressing Esc / Shift / F10 / F12 during power on, system always boots directly to the Xubuntu login screen.
You should probably start by providing more info, i.e. amend the support template info with machine details, steps you’ve taken, outcomes, screenshots. For me it’s still not quite clear what your machine actually is; VM or bare metal, why Virtualbox, etc.
That means you expect the default to be menu. I don’t know if that’s true. Also don’t forget update-grub; it happens.
BTW, this is the community help forum, where users help users. If you need professional support, this isn’t the way to get it.
Please put all log and other console/terminal output in pre-formatted code blocks (open a new line and click the </> icon in the editor first, then paste into the new element), ideally wrapped in a “Hide Details” element, if it’s more than just a few lines. See items 4 and 5 in the Posting Guide.
Optional helper script
If you are so inclined, I took it upon myself to provide a little helper script for that.
Bare metal Xubuntu 26.04 on a Dell Pro Max 16/16XE MC16250 laptop. Dell shipped it with Ubuntu 24.04 preload. I reimaged to Xubuntu 26.04.
VirtualBox is loaded onto the Xubuntu 26.04 main OS to support legacy operating systems.
VirtualBox on this system only is grouchy that apparently its claws into SecureBoot of the Xubuntu Host OS are not satisfied. I am trying to now troubleshoot without direct access to the system.
Then I found the Grub menu had disappeared… perhaps some update got the Grub menu hidden…
I really seem to have ended up sending this system out to a good friend unaware that Dell had the BIOS set to SecureBoot mode.
Those are not VB’s claws into Secure Boot. VB requires extra modules which need to be signed to satisfy SB requirements; no unsigned code allowed.
If you, or your friend, can make do with what’s on offer in the pure FOSS world, i.e. virt-manager and qemu-system, there is no need for setting up DKMS and hence no MOK.
Perhaps there’s more to the story, because even a hidden menu should show when pressing Esc.
Well, SB is pretty much standard these days, so why did you expect it to be disabled? Don’t project your anger with yourself on poor Ubuntu; it’s only doing what it’s supposed to. If you don’t want SB, there’s an easy way to disable it; no more MOK Util/Manager needed.
Morning has come, we updated the Grub configuration now on the Dell Pro Max 16/16XE MC16250 laptop system, then did sudo update-grub, IPL, and still no Grub menu. I have no idea what changed since I shipped the system that so completely has seemingly bypassed Grub.
I guess we will jump to the kind suggestion of how to instruct the system to enter the BIOS from the Linux command line, above in this thread.
Again about the SecureBoot expectation I am not comfortable with… being asked to supply an additional special password to make SecureBoot work properly. We do not need an additional password, so seems SecureBoot is what is requiring the additional password, so seek disabling SecureBoot for the time being is the solution we will pursue.
And it is not just VirtualBox that needs DKMS drivers… we also use the Nvidia binary drivers. Every Desktop Linux system I consult on has the Nvidia GPU and the system runs the Nvidia binary drivers.
So again, if Linux’s ability to boot on a system with SecureBoot enabled requires setting an additional password on the system, THAT is not very helpful to the countless individuals / small businesses I assist. I would rather disable SecureBoot in the BIOS than plague lots of people with a SecureBoot password “they do not need on a daily basis”, but boy will they need it in a sudden pinch. I refuse to do that to people.
Yes, and those will require MOK signatures as well, which is why DKMS wanted to enroll its key, once and for all; the password is only required once for physical presence approval, as demanded by the Secure Boot spec. That may explain your black screen at boot, actually. No Nvidia driver, because no MOK, no output; it’s SB at work. You’ll have to disable it first.
This is still the users helping users Discourse. Please contact Canonical’s professional support for anything beyond that. There may well be ways to do this in bulk, but you’ll probably not find the info on that here.
Plus, DKMS is required only for proprietary drivers requiring glue modules, which need to be compiled locally because of licensing limitations. Get rid of the dependence on those and no MOK enrollment is required. The Thinkpad, on which I’m writing this, is running without a MOK but Secure Boot enabled, so it can be done.
Friend was able to spot where to shut off Secure Boot.
That made the Grub menu appear at the next IPL! I have no idea what could have changed between the system leaving my hands and getting into my friend’s hands!
And the bottom Grub menu entry that enters UEFI Firmware Settings does land in the Dell BIOS as it is supposed to.
Xubuntu 26.04 boots properly.
APT was able to finish successfully the VirtualBox package installation.
VirtualBox successfully boots up that first VM we were attempting to migrate over to this new computer.
Woo hoo! Perfectly resolved by the Ubuntu community! We are very thankful!
Nay, I did that VirtualBox initial installation here. So that is not the thing that caused the system to “freak out” stop displaying Grub properly.
I just could not migrate any of my friend’s VM’s as I do not have access to those.
Well, the VB modules aren’t required for booting, at least not on bare metal, but the Nvidia modules are. Your friend probably installed the proprietary driver, not knowing that you had cancelled the MOK enrollment, which was the recipe for failure here.
That is precisely my impression. I was very confused and apprehensive why VB would be doing something to the Linux boot process that required setting a password. I did not want the VM software mucking that deep that VB would need to know the SecureBoot password for the entire system! aaaakkk!!!
Technically, it wasn’t VB at all, but one of its dependencies pulls in DKMS, which, on first run, generates and enrolls the MOK, no matter the purpose of the modules. With SB enabled the kernel automatically enters lockdown mode, which makes signed modules mandatory.
aaaakkk!!!