Quantcast
Channel: Debian User Forums
Viewing all articles
Browse latest Browse all 3200

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

$
0
0
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:

Disk /dev/sdb: 238.47 GiB, 256060514304 bytes, 500118192 sectorsDisk model: LITEON CV3-8D256Units: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: gptDisk identifier: 9ED0EB21-3FE3-4A48-84A2-66E30D1507C2Device     Start       End   Sectors   Size Type/dev/sdb1   2048 500118158 500116111 238.5G Linux filesystemDisk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectorsDisk model: ST1000LM048-2E71Units: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 4096 bytesI/O size (minimum/optimal): 4096 bytes / 4096 bytesDisklabel type: gptDisk identifier: 5F05E1D1-73AA-4F6B-8D9D-6E4BBB1133D5Device        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 filesystemDisk /dev/loop0: 984.42 MiB, 1032241152 bytes, 2016096 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytes
This is the machine's /etc/fstab file:

Code:

# <file system> <mount point>   <type>  <options>       <dump>  <pass># / was on /dev/sdb2 during installationUUID=35bfaa48-481b-4e23-9dc0-5ab10f5275b6 /               ext4    errors=remount-ro 0       1# /boot/efi was on /dev/sdb1 during installationUUID=1E40-9CBB  /boot/efi       vfat    umask=0077      0       1# /home was on /dev/sdb4 during installationUUID=8335af82-ff86-421d-9c7b-62ad0b314d11 /home           ext4    defaults        0       2# swap was on /dev/sdb3 during installationUUID=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.

Statistics: Posted by klaamanit — 2025-01-16 19:35 — Replies 0 — Views 15



Viewing all articles
Browse latest Browse all 3200

Trending Articles