bootctl install not creating EFI boot entry when ran in arch-chroot

saymonz · 2024-12-19 15:40:33

Good afternoon Arch folks,

Yesterday I updated my motherboard firmware, so my EFI boot entries were reset. I've been using systemd-boot as my bootloader for a long time now.

No big deal I thought, let's arch-chroot into the system from a live media and run bootctl install I thought, and that's where I began pulling my hair : bootctl is not creating EFI boot entry when I run it from arch-chroot.

The line

Created EFI boot entry "Linux Boot Manager".

is simply missing from the output, with no warning whatsoever: what's the point for an UEFI only bootloader to silently fail on that? If there was an explicit error about it, I would have worked around by manually creating boot entry with efibootmgr way sooner...

That's when I ran bootctl set-oneshot xxx in the chroot that I realized that somehow, when running in chroot, bootctl considers we're not running in UEFI mode (outputs Not booted with UEFI.). arch-chroot seems to mount everything needed in /sys/firmware properly though.

Before making a report upstream, I wanted to check if there is something missing in the way arch-chroot mounts EFI vars that would make bootctl happy? Or is it something specific to my hardware?

Here's a demo replicating the issue on my installed system:

[root@saymonz-pc mnt]# bootctl install # Running on my installed system
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/systemd/systemd-bootx64.efi".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/BOOT/BOOTX64.EFI".
⚠ Mount point '/boot' which backs the random seed file is world accessible, which is a security hole! ⚠
⚠ Random seed file '/boot/loader/random-seed' is world accessible, which is a security hole! ⚠
Random seed file /boot/loader/random-seed successfully refreshed (32 bytes).
Created EFI boot entry "Linux Boot Manager".

[root@saymonz-pc mnt]# mount /dev/nvme2n1p5 /mnt/test/ # Mount installed system root partition
[root@saymonz-pc mnt]# mount /dev/nvme2n1p1 /mnt/test/boot/ # Mount ESP partition
[root@saymonz-pc mnt]# arch-chroot /mnt/test/     
[root@saymonz-pc /]# ls /sys/firmware/efi/
config_table  efivars  esrt  fw_platform_size  fw_vendor  runtime  runtime-map  systab
[root@saymonz-pc /]# bootctl install # Bootctl silently no creating EFI boot entry in arch-chroot
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/systemd/systemd-bootx64.efi".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/BOOT/BOOTX64.EFI".
⚠ Mount point '/boot' which backs the random seed file is world accessible, which is a security hole! ⚠
⚠ Random seed file '/boot/loader/random-seed' is world accessible, which is a security hole! ⚠
Random seed file /boot/loader/random-seed successfully refreshed (32 bytes).
[root@saymonz-pc /]# bootctl set-oneshot auto-windows 
Not booted with UEFI.

Thanks for any insight.

Last edited by saymonz (2024-12-19 15:54:56)

jaydoc · 2024-12-24 03:22:24

I am experiencing the same issue. Not sure what the fix is.

saymonz · 2024-12-24 03:33:45

The fix is manually creating EFI boot entry as described here, but we should not have to do this.

Head_on_a_Stick · 2024-12-24 08:41:35

The drive should boot anyway if there are no specific NVRAM entries because systemd-boot hijacks /EFI/Boot/bootx64.efi on the ESP.

saymonz · 2024-12-24 10:43:54

Not in my case, only boot entry after updating the motherboard firmware was my Windows system somehow.

Head_on_a_Stick · 2024-12-24 10:46:42

The Windows entry will over-ride bootx64.efi. If you didn't have any NVRAM entries for specific .efi loaders then bootx64.efi would be run automatically. That's how live ISO images boot from USB sticks.

saymonz · 2024-12-24 14:15:39

I don't know if my motherboard somehow preserved the Windows boot entry, or if Windows reinstalled itself as the fallback bootloader beforehand then recreated its boot entry itself on next boot.

This is not really relevant to the thread though, once I figured out bootctl was not creating boot entry as expected, I could create boot entry manually.

Issue is, running bootctl install from chroot is the recommended installation way described in the wiki (here, it clearly states that we should run it chrooted in the newly installed system) and this is just not working (this could be an overlook in the way arch-chroot mounts things, that's what I'm trying to figure out here). Also, it fails silently, which is imho problematic and is obviously an upstream issue.

pedrohqb · 2024-12-26 01:54:30

I can confirm the issue. Nonetheless, my Dell Optiplex SFF Plus 7010 was able to detect /boot/bootx64.efi on the ESP so I could boot it and install systemd-boot properly by running # bootctl install.

ZEN1X · 2024-12-26 13:34:41

Same happened during an install on MSI B350 Tomahawk mobo.
Nothing a quick reboot into the installation media and chroot wouldn't fix, but just plain annoying.

I'm 99% sure BOOTX64.efi was systemd-boot (judging by modify date) and my UEFI booted to Windows just like for OP.

tle130475c · 2025-01-05 08:38:16

I was surprised by this issue today while reinstalling my system. No "Linux Boot Manager" was created when running "bootctl install" in arch-chroot. It was working normally before, so perhaps something has changed with recent updates to systemd.
On a system with only Arch Linux, it can boot without the entry. However, on a dual-boot system with Windows, it is impossible to boot. Need to manually create the entry as mentioned in #3.

Head_on_a_Stick · 2025-01-05 11:02:18

Please stop with the +1 posts, they don't help anybody in any way.

Has anybody reported this as a bug upstream?

kk · 2025-01-26 00:20:07

Head_on_a_Stick — I've just filed a bug on GitHub

saymonz — in the linked issue, I provided a link to this post and pasted the terminal output you provided above. I hope that's okay with you.

Trevor_B · 2025-02-01 18:48:40

Hello

For info i had this problem, while testing Arch Install on a second SSD for an upcoming new PC build

These tests, I did about 5 or 6 times, were on a old Asrock MB about 10 years old, I tried Grub or Systemd to no avail I already have Arch running on a another SSD on this PC for the last three years)

Like above to get my test install done I had to run
sudo efibootmgr --create --disk /dev/sda --part 1 --loader '\EFI\systemd\systemd-bootx64.efi' --label "Linux Boot Manager" --unicode
To get the the install to run

I have now just installed a new motherboard and the Arch Installer works fine all by itself, so this bug seems to be linked to the MB or it's Bios

Arch Linux

#1 2024-12-19 15:40:33

bootctl install not creating EFI boot entry when ran in arch-chroot

#2 2024-12-24 03:22:24

Re: bootctl install not creating EFI boot entry when ran in arch-chroot

#3 2024-12-24 03:33:45

Re: bootctl install not creating EFI boot entry when ran in arch-chroot

#4 2024-12-24 08:41:35

Re: bootctl install not creating EFI boot entry when ran in arch-chroot

#5 2024-12-24 10:43:54

Re: bootctl install not creating EFI boot entry when ran in arch-chroot

#6 2024-12-24 10:46:42

Re: bootctl install not creating EFI boot entry when ran in arch-chroot

#7 2024-12-24 14:15:39

Re: bootctl install not creating EFI boot entry when ran in arch-chroot

#8 2024-12-26 01:54:30

Re: bootctl install not creating EFI boot entry when ran in arch-chroot

#9 2024-12-26 13:34:41

Re: bootctl install not creating EFI boot entry when ran in arch-chroot

#10 2025-01-05 08:38:16

Re: bootctl install not creating EFI boot entry when ran in arch-chroot

#11 2025-01-05 11:02:18

Re: bootctl install not creating EFI boot entry when ran in arch-chroot

#12 2025-01-26 00:20:07

Re: bootctl install not creating EFI boot entry when ran in arch-chroot

#13 2025-02-01 18:48:40

Re: bootctl install not creating EFI boot entry when ran in arch-chroot

Board footer