You are not logged in.
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)
Offline
I am experiencing the same issue. Not sure what the fix is.
It takes a very unusual mind to undertake the analysis of the obvious - A N Whitehead
Offline
The fix is manually creating EFI boot entry as described here, but we should not have to do this.
Offline
The drive should boot anyway if there are no specific NVRAM entries because systemd-boot hijacks /EFI/Boot/bootx64.efi on the ESP.
Para todos todo, para nosotros nada
Offline
Not in my case, only boot entry after updating the motherboard firmware was my Windows system somehow.
Offline
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.
Para todos todo, para nosotros nada
Offline
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.
Offline
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.
Offline
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.
Offline
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.
Offline
Please stop with the +1 posts, they don't help anybody in any way.
Has anybody reported this as a bug upstream?
Para todos todo, para nosotros nada
Offline