[SOLVED] How to get the UEFI to detect Debian 12 boot partition?

Framework Laptop 13
,
1

Hey everyone, I have the Framework 13 laptop (AMD edition).

I’m trying to understand this new BIOS (UEFI) that I’ve never really worked with before. If I understand, the laptop is running something called “Insyde”.

So I did the Debian 12 Bookworm install, and am applying the AMDGPU and backported kernel fixes as I speak. But I’m having problems booting it up normally. It says, “Default Boot Device Missing or Boot Failed”. I have to go into the Boot from File menu and then select the path <VOLUME LABEL>/<EFI>/<debian> and then select either shimx64.efi or grubx64.efi.

The thing is, I did the Expert Install of Debian, because I needed just a little more control over partition layout and stuff. But the installer did ask me a confusing question about whether or not to install GRUB to the NVRAM. Again, not sure what this is about. I am so used to BIOS stuff since I grew up with computers in the 90’s, and dealing with UEFI stuff is generally much more confusing to me.

So how do I fix it? I just basically want to add it to the UEFI boot menu I guess. I already made sure os-prober was enabled too (though I likely won’t dual boot). GRUB is already installed to the EFI System Partition (ESP), so why is the UEFI not detecting it? I made sure the flags esp,boot are on the partition. What’s going on?

I only have separate Btrfs /boot (unencrypted for now so I can encrypt later), and Btrfs encrypted root /. Bootup works just fine after I select the boot image.

2

That’s just the name of the ‘manufacturer’ of the BIOS that Framework use.

GRUB is a bootloader interface that I use to dual boot as I bought a pre-build with Windows and then Installed Ubuntu. So it being on the main memory i.e. NVMe SSD gives the boot somewhere to start beyond the BIOS

3

Hmm…

You know, I had figured somewhere that EFI GRUB is kind of limited. We do have systemd-boot now, as well as rEFInd. I think rEFInd is unnecessary though for most users, because GRUB is still a bit better…

The big problem is GRUB cannot use an encrypted boot partition unless it is specifically either LUKS1, or does not use Argon2 as the KDF/cipher or whatever. And that made me think… does systemd-boot actually support encrypted boot with LUKS2 and Argon2id?

I’ve been seeing these instructions here for those of us who want to use only Btrfs subvolumes (and avoid LVM),

Link here - For installing Debian Sid with LUKS2 encrypted BTRFS filesystem with Systemd-boot and rEFInd bootloaders plus an option for dualboot to Windows · GitHub

Although this uses a whole Debootstrap method, and it’s for Sid, but could be adapted for Stable probably. As you can see, they include /boot on root, something that both the regular and live Calamares installer complain about if the user tries to set up a single encrypted Btrfs partition. The installers also insist on installing GRUB2.

But it would be nice if I could just replace GRUB2 with systemd-boot and just have my cake and eat it too basically. Have encrypted /boot as one partition. Though I have no idea how the EFI system partition would access /boot though. Wouldn’t the boot need to still be decrypted first?

Still gonna do some more research about this. But for the meantime, sure, I think I just want to get this working with GRUB at the moment, and not worry too much about setting up a new thing for me like systemd-boot, because it could make the system unbootable if I change around where /boot is.

I am also really trying to avoid using LVM because it adds unnecessary complexion, and I don’t want to use two LUKS passwords to unlock my system (one for root, the other for boot). Btrfs subvolumes are powerful, and I’m stubborn, so I want to use them.

1 Like
4

Okay, it was a pretty simple “fix”. I just copied the directory as root from /boot/efi/EFI/debian/ to /boot/efi/EFI/boot/ and that works just fine. Does this file need to be updated much? I hope Debian knows what to do if it needs to update the Secure Boot shim or whatever.

When I do this, the UEFI menu entry shows it as “Linpus lite”, which is really weird, but… alrighty then. Guess that takes care of that particular problem for now!

1 Like
5

I typically tick the ‘also install to fallback path’ when installing Debian – using netinstall expert mode – because of this problem. If you’d not already fixed this, you would be able to re-run the installer in Advanced → Rescue Mode and then step through validating your existing installation before using the ‘Install GRUB’ step with this ‘also install to fallback path’ option.

You may have to watch when grub-efi updates to see if the changes match in these two locations.

For LVM2 unlock, you can add keys so that the password entered in Grub to unlock /boot then uses a keyfile in the initial RAM disk (initrd) to unlock the other partitions. Debian’s crypto team have a guide to set this up for yourself.

(I’ve not thought to raise a bug with Debian about /boot/efi/EFI/debian vs /boot/efi/EFI/BOOT, I only have a few devices and think they’re more likely to be quirky than Debian implement the UEFI spec wrong.)

K3n.

1 Like
6

If I understand it, it is not necessarily Debian’s problem that /boot/efi/EFI/debian does not work. That is a bug in the UEFI BIOS. The BIOS is supposed to support multiple directories in /boot/efi/EFI.

7

It does.

Like all other UEFI-compliant firmware, it needs to be informed about the presence of other bootloaders using the Boot#### and BootOrder NVRAM variables.

Your Linux distribution will typically manage these NVRAM variables for you using something like efibootmgr.

I am not aware of any UEFI firmware that automatically discovers bootloaders outside the failsafe path. They all need to be told—including the one on the Framework Laptop.

1 Like
8

Oh, yes!

I do remember using efibootmgr in the past a few years ago when setting up my PC, but I think it was for a different reason. Either that, or I just forgot how to do it. Yet I remember it being easy to learn.

I am still not sure about the NVRAM technical stuff. Just curious, are the EFI variables stored in /boot/efi somewhere, or on a protected GPT partition/header, or is it stored in the UEFI firmware itself, then exposed to the system with sysfs (/sys/firmware/efi/)?

9

Huh, excellent question. They’re stored on the same flags chip as the firmware, and they’re exposed by the firmware itself. There’s a Linux driver (efivarfs!) that offers them as that filesystem.

1 Like
10

Alright, made a quick shell script:

#!/bin/sh

efibootmgr -q --bootnum 0000 -B

efibootmgr -q --bootnum 0000 --unicode \
--create --disk /dev/nvme0n1p1 \
--part 1 \
--label "Debian GNU/Linux 12 (bookworm)" \
--loader '\EFI\debian\shimx64.efi' \
--unicode 'root=UUID=<xxxx> rw initrd=\initrd.img'

efibootmgr --bootorder 0000,2001,2002,2003

There were leftover entries for Windows bootmgr that I removed.

The bootnums 2001,2002,2003 were already set for other things. When I checked cmdline I noticed /vmlinuz is a symlink for Debian-based distros, even though it showed /vmlinuz-6.10.11+bpo-amd64, and the initrd= line was also missing. Huh… But hopefully that all works as expected. Time to test!

  • EDIT: Okay, I was just blindly copy-pasting. I should have used --loader '\EFI\debian\shimx64.efi' instead of --loader /vmlinuz. When doing it that way, the UEFI does not annoyingly rename the entry to Linpus Lite anymore!

But I get a new error when booting that says: start_image(): Returned not found ...

But yet it continued to boot properly, so maybe it can be treated as a warning, or something I forgot to configure? I don’t know. Also, it changes rw to ro in the cmdline. Not sure why.

Also I realized BOOT_IMAGE= is the same thing as initrd= but for cmdline… :blush: