Secure Boot - Installer works flawlessly, but a reboot into new system fails signature integrity

[klaamanit]

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:

Code: Select all

Disk /dev/sdb: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: LITEON CV3-8D256
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 9ED0EB21-3FE3-4A48-84A2-66E30D1507C2

Device     Start       End   Sectors   Size Type
/dev/sdb1   2048 500118158 500116111 238.5G Linux filesystem


Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST1000LM048-2E71
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 5F05E1D1-73AA-4F6B-8D9D-6E4BBB1133D5

Device        Start        End    Sectors   Size Type
/dev/sda1      2048    1050623    1048576   512M EFI System
/dev/sda2   1050624   59643903   58593280  27.9G Linux filesystem
/dev/sda3  59643904   61644799    2000896   977M Linux swap
/dev/sda4  61644800 1953523711 1891878912 902.1G Linux filesystem


Disk /dev/loop0: 984.42 MiB, 1032241152 bytes, 2016096 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

This is the machine's /etc/fstab file:

Code: Select all

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdb2 during installation
UUID=35bfaa48-481b-4e23-9dc0-5ab10f5275b6 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sdb1 during installation
UUID=1E40-9CBB  /boot/efi       vfat    umask=0077      0       1
# /home was on /dev/sdb4 during installation
UUID=8335af82-ff86-421d-9c7b-62ad0b314d11 /home           ext4    defaults        0       2
# swap was on /dev/sdb3 during installation
UUID=413c075a-d76f-4884-8158-325e65dae1e6 none            swap    sw              0       0

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.

[Uptorn]

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.

[pbear]

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.

[klaamanit]

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

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

[klaamanit]

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.

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.

[pbear]

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.