Heads became grub centric

[tlaurion]

Can't seem to boot the main OS for some reason, is just doesn't see any files in my boot partition and refuses to sign anything.

It just prints this to stdout and then fails with "Failed to update checksums/sign default config":

sha256sum: /tmp/kexec/kexec_hashes.txt: No such file or directory
/etc/functions: line 1010: /tmp/kexec/kexec_tree.txt: No such file or directory
diff: can't stat '/tmp/kexec/kexec_tree.txt.user': No such file or directory
Unable to locate /boot files on any mounted disk
mount: can't find /boot in /proc/mounts

I've tried reflashing multiple times and resetting everything to no avail. My /boot is an ext4-formatted /dev/sda1 with kexec_menu.txt, initramfs-linux.img and vmlinuz-linux, I can mount it manually just fine. It also gets mounted by Heads if I set the boot device to /dev/sda1 with the "Change the /boot device" option. This setup worked perfectly with an older build from #1723, not sure what's changed... /dev/sda2 is a LUKS2-encrypted btrfs root, I don't need Heads to touch it

---

Ah, I see. mount_possible_boot_device is hardcoded to look for files starting with grub. But why..? I get the ease of use part of this, but I feel Heads should respect whatever I set as /boot and not try probing every partition for grub files (that aren't even there).

Originally posted by @pcm720 in https://github.com/linuxboot/heads/issues/1908#issuecomment-2692407117

[tlaurion]

@pcm720 can you give a little mode output of content of /boot and what is missing? if not grub, syslinux?

also provide debug logs

• mount-usb --mode rw
• cp /tmp/debug.log /media
• umount /media

and provide debug.log here please.

[pcm720]

@pcm720 can you give a little mode output of content of /boot and what is missing? if not grub, syslinux?

My distro of choice (Arch) doesn't require a bootloader, it's up to the user to decide whether they need one. So I don't use any bootloaders on all of my systems. For UEFI systems, I simply build a signed UKI and add it to EFI vars with efibootmgr. For Heads, I wrote my kexec_menu.txt entry by hand. It simply loads Linux kernel with initramfs, so my /boot contains only Heads files, initramfs and the Linux kernel:

Arch Linux|elf|kernel /vmlinuz-linux|initrd /initramfs-linux.img|append cryptdevice=UUID=<UUID>:cryptroot root=/dev/mapper/cryptroot rw quiet loglevel=3 cryptkey=rootfs:/secret.key

To replicate this issue, I simulated a fresh /boot by removing all kexec* files from /boot except kexec_menu.txt:

/boot
├── initramfs-linux.img
├── kexec_menu.txt
├── lost+found
└── vmlinuz-linux

Then I ran Options -> Update checksums and sign all files in /boot from Heads' GUI. Here's the log: debug.log

The main issue here seems to be that the mount_possible_boot_device in /etc/functions always tries to probe partitions for boot files even if the user manually sets the /boot partition in Heads configuration menu. If I run touch grub in my /boot and re-run everything, Heads finds the partition and everything works just like with previous builds.

[tlaurion]

@pcm720 can you give a little mode output of content of /boot and what is missing? if not grub, syslinux?

My distro of choice (Arch) doesn't require a bootloader, it's up to the user to decide whether they need one. So I don't use any bootloaders on all of my systems.

What I meant here, is that Heads is playing the role of the bootloader. I'm not sure what to do here; the end user normally installs an OS which deploys either grub or syslinux; I was expecting you to use the latter.

For UEFI systems, I simply build a signed UKI and add it to EFI vars with efibootmgr. For Heads, I wrote my kexec_menu.txt entry by hand. It simply loads Linux kernel with initramfs, so my /boot contains only Heads files, initramfs and the Linux kernel:

Arch Linux|elf|kernel /vmlinuz-linux|initrd /initramfs-linux.img|append cryptdevice=UUID=<UUID>:cryptroot root=/dev/mapper/cryptroot rw quiet loglevel=3 cryptkey=rootfs:/secret.key

To replicate this issue, I simulated a fresh /boot by removing all kexec* files from /boot except kexec_menu.txt:

/boot
├── initramfs-linux.img
├── kexec_menu.txt
├── lost+found
└── vmlinuz-linux

Then I ran Options -> Update checksums and sign all files in /boot from Heads' GUI. Here's the log: debug.log

The main issue here seems to be that the mount_possible_boot_device in /etc/functions always tries to probe partitions for boot files even if the user manually sets the /boot partition in Heads configuration menu. If I run touch grub in my /boot and re-run everything, Heads finds the partition and everything works just like with previous builds.

TBH, for your typical issue, deploying grub at install would make arch deploy grub.cfg where intended, where arch maintained grub binaries and libs, just as qubesos, under /boot, are never used. Only grub/grub.cfg, being the result of OS deploment's xen/kernel/initrd, as maintained by OS, is picked up, parsed and used.

@pcm720 what would you want Heads to change here? What would be the exemption needed here to highly technical users going completely manual have their workflow respected?

[pcm720]

TBH, for your typical issue, deploying grub at install would make arch deploy grub.cfg where intended, where arch maintained grub binaries and libs, just as qubesos, under /boot, are never used. Only grub/grub.cfg, being the result of OS deploment's xen/kernel/initrd, as maintained by OS, is picked up, parsed and used.

I don't like this workaround because it hooks into the initrd generation process and adds more complexity. For me, creating empty grub file is much simpler than installing GRUB as my cmdline is static :)

what would you want Heads to change here? What would be the exemption needed here to highly technical users going completely manual have their workflow respected?

I see two possible solutions:

1. Checking if kexec_menu.txt exists before testing for GRUB files when searching for possible /boot partition. If kexec_menu.txt exists, we can be 99% sure that this partition is the boot one.
2. There's an option that allows the user to set the /boot partition manually. I'm not sure what it does since all the probing is still performed as if it wasn't set. What I'm suggesting is skipping the probing if the user has manually set the /boot partition in Heads' configuration and just using what's ever in there.

Any of these two solutions would solve the issue.