Debian User Forums

Hello,

I have a machine with Secure Boot enabled which I cannot disable. I cannot even enter this machine's BIOS menu [1].

This has severely impacted my choices of OSes that I can run in it, with Ubuntu being my choice for the longest of times. Recently, however, I realized Debian 12 also supported Secure Boot, and so I immediately made my move to install it, as it is my favorite OS.

The netinstall ISO booted flawlessly on this machine, and the installation went perfectly (as perfect as any other Debian install I ever did, at least) without me even thinking that Secure Boot was enabled. On the last step, I rebooted the machine and yanked out the USB drive, thinking that the same way that the installer booted, so it would from the disk.

I was wrong. Instead, the machine showed the message that a Secure Boot signature violation was detected and thus the system would not boot.

I'm completely lost and surprised at this point as to what to do, since I never had to deal with Secure Boot on Linux like this before (usually just disable it). What should I investigate?

Some facts about this machine:

1. It has two drives - a 256GB SSD (no OS, just storage) and a 1TB HDD (where Ubuntu was and now Debian is installed). fdisk:
This is the machine's /etc/fstab file:
2. It previously housed a working Ubuntu 22.04 installation on the same disk

3. In said Ubuntu install, I fiddled around a bit with mokutil to register my own machine owner keys because I wanted to run some virtual machines in it. However, I do not have these keys anymore.

What I have already tried to do:

Reinstalling the fresh OS, not doing LUKS full-disk encryption etc did not work. Same error message.

Asking around in IRC, someone suggested that I chroot into the system through the LiveCD and run update-grub && grub-install --removable as a way to "update the firmware." This did not work either, even though the grub updating itself was successful.

----

And that's pretty much it. I'm stuck, even though live media seem to be working fine. Would love some assistance in it, as I can't bear using Ubuntu anymore there, and gladly will provide more information if needed.

Thank you!

----

[1] Before anyone asks: this machine is NOT employer or school-owned. It's mine, paid for, but I did not receive and do not have ways to ask for the password. I know I could try to reset the CMOS, flash the BIOS and etc, but I would rather not do so to lower the risk of bricking this hardware.

Are you unable to access the secure boot settings and associated keys from within the EFI? You cannot even disable secure boot? Regaining control of your EFI admin access should be your first priority.

What I would try next is disabling validation. It's something the Linux shim team was able to persuade Microsoft to permit, not least because it leaves secure boot in force as regards Windows. What I don't know is whether the procedure will stumble over whatever is preventing boot. Debian is definitely secure boot compatible - I've done it - so this is an issue with your firmware. I'm more puzzled that Ubuntu doesn't have the same problem. Anyhoo, as Ubuntu works, I'd do this from an Ubuntu live session. The command is simple: sudo mokutil --disable-validation. Then the same MOK drill you used previously.

Will be prompted for a password. This is a one-time password - a sort of capcha, actually - so doesn't need to be robust. Eight ones (11111111) will be fine. Reboot. At MOK screen, tap a key (any key) to cancel countdown timer. Read instructions at leisure. Should be a button to click to proceed (something like "change secure boot state"). Will ask for the one-time password; or maybe the X, Y and Z digits of said password (the reason for making them all the same). At next prompt, confirm MOK approval/enrollment. Reboot (again). Double-check procedure worked, e.g., mokutil --sb-state. You're looking for “SecureBoot enabled, SecureBoot validation is disabled in shim.”

Frankly, if that doesn't work, I don't know what to suggest. The admin password you don't have is the intended solution as far as the computer's maker is concerned.

Uptorn wrote: 2025-01-17 01:54 Are you unable to access the secure boot settings and associated keys from within the EFI?

I never even thought to use the EFI shell in such a way before. I guess this is a great time to delve deeper into that topic, given the potential reward

Uptorn wrote: 2025-01-17 01:54 You cannot even disable secure boot? Regaining control of your EFI admin access should be your first priority.

Nope, this machine was sold to me with a locked BIOS, and I can't contact the seller to claim the password. I found this SO answer which sounds like a good start, though:

https://superuser.com/questions/630965/ ... bios-setup

pbear wrote: 2025-01-17 03:17 What I would try next is disabling validation. (...) The command is simple: sudo mokutil --disable-validation. Then the same MOK drill you used previously. (...)

OK, I'll try this suggestion as soon as I can. The only problem is that I don't really remember what were the commands I used when enrolling my keys to use with VirtualBox I copied them from an article somewhere, maybe I can find it again.

Do you think I can do this without further enrolling other MOK keys? I realized just today that I didn't even need to do that enrollment if I just used QEMU, so I regret even doing that a couple of years ago. The more you learn, huh.

pbear wrote: 2025-01-17 03:17 Frankly, if that doesn't work, I don't know what to suggest. The admin password you don't have is the intended solution as far as the computer's maker is concerned.

Agreed. I regret not noticing this until way after I purchased it. Seems to me I'm just doing a big workaround here, but it's a pity to watch a computer get wasted.

klaamanit wrote: 2025-01-17 20:09 Do you think I can do this without further enrolling other MOK keys?

I know to a certainty that MOK keys aren't needed to disable validation. Indeed, the purpose of the latter procedure is to eliminate the need for the former, albeit with the (remote) risks which attend disabling secure boot generally. The only link between the two procedures is that the same one-time password mechanism is used to confirm modification of the firmware settings.

pbear wrote: 2025-01-17 03:17 What I would try next is disabling validation. (...) The command is simple: sudo mokutil --disable-validation.
(...)
Double-check procedure worked, e.g., mokutil --sb-state. You're looking for “SecureBoot enabled, SecureBoot validation is disabled in shim.” (...)

Hey pbear, I tried this procedure and the success was... mixed.

The procedure itself worked flawlessly. Everything downright to the messages appeared correctly. I was able to disable the validation and, during boot, the loader says "booting without validation." However, what I couldn't test yet due to lack of time was that (disk-installed) Debian bootloader passes it. This is because I (in the midst of all these tests) ended up installing Fedora temporarily to investigate further, and deleted that first Debian installation.

What I did try was to boot a non-shimmed Linux distro (Alpine) - which did not work. Which is surprising, I think, since in theory we're not validating anything, right?

On the light of this, I guess my last question is: does this disabling of validation persists even after I remove the original install that I used to do this? Does this setting "persist" within the UEFI firmware for every other OS? As you all may have noticed, I have very little knowledge of the Secure Boot environment.

pbear wrote: 2025-01-17 03:17 Frankly, if that doesn't work, I don't know what to suggest. The admin password you don't have is the intended solution as far as the computer's maker is concerned.

Still crossing fingers, but that seems to be the order of things, indeed...

And the result: no change at all, the problem still persists.

Fresh install of same Debian 12 whose installer booted after disabling SB validation and integrity error yet again.

Guess I have my answer: I will never be able to run Debian in a system with SB enabled.

klaamanit wrote: 2025-01-20 18:34 Which is surprising, I think, since in theory we're not validating anything, right?

No, disabling validation only works if booting from shim. That was the compromise between Team Linux and Team Microsoft. If the user wishes to disable secure boot altogether, that's a different procedure (the one you can't use because you don't have the admin password). Anyhoo, there's probably a solution, but I always disable secure boot and don't know what else to try. Sorry, good luck.

Hello,

klaamanit wrote: 2025-01-21 00:29 I have a machine with Secure Boot enabled which I cannot disable. I cannot even enter this machine's BIOS menu
[..]
Fresh install of same Debian 12 whose installer booted after disabling SB validation and integrity error yet again.

Guess I have my answer: I will never be able to run Debian in a system with SB enabled.

Can you please report:

• the model and manufacturer of your computer

• a video recording of the boot attempt

The error message "Secure boot signature violation" does not seem to be in the Debian source code, so there are two possibilities:
1) the error message is not accurately reported
2) the error message comes from the computer's secure boot firmware
A video recording of the boot attempt with the error might be useful.

Hope this helps.