EndeavourOS boot entry missing after BIOS update

cybird · May 7, 2025, 8:42pm

Title. Updated my BIOS, and I have followed several threads where I tried the following:

Live USB: arch-chroot into my EOS system > bootctl install > reinstall-kernels; Linux boot manager still does not show in the BIOS, efibootmgr, or Windows bcdedit.
Secure boot is disabled.

Notes: There are two Windows entries when using bcdedit (this is consistent in the BIOS, which also shows two Windows boot entries):

PS C:\Users\elite> bcdedit

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume1
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {142ee43b-bdd9-11ef-a17e-d8bbc19f17d7}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \WINDOWS\system32\winload.efi
description             Windows 11
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {142ee43e-bdd9-11ef-a17e-d8bbc19f17d7}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \WINDOWS
resumeobject            {142ee43b-bdd9-11ef-a17e-d8bbc19f17d7}
nx                      OptIn
bootmenupolicy          Standard

Please let me know if more information is needed, thanks.

EDIT: I used systemd-boot, not GRUB, and btrfs for EOS.

cybird · May 8, 2025, 1:27am

Fixed. For those who have a similar problem, I had to manually add the boot entry for systemd-boot as such:

sudo mount /dev/nvme0n1p2 /mnt 
sudo mount /dev/nvme0n1p1 /mnt/boot 
sudo arch-chroot /mnt

bootctl --path=/boot install

efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "EndeavourOS" --loader /EFI/systemd/systemd-bootx64.efi

Make sure you match the /dev/nvme1n1p1 and --part 1 information to match your drive & ESP number. Also verify that the directories exist before running commands.

Keywords for those searching for this issue/fix: BIOS update, after BIOS update, EndeavourOS not in boot loader, EndeavourOS missing, reinstall-kernels, two Windows boot entries.

cactux · May 9, 2025, 7:54am

When running in pid namespace (which is the case for arch-chroot(8)), bootctl does not create the UEFI boot entry in NVRAM anymore since systemd v257. (Discuss in User talk:Scimmia#Revert on systemd-boot about sd-boot not creating EFI entries inside chroot)

https://wiki.archlinux.org/title/Systemd-boot#Installing_the_UEFI_boot_manager

github.com/systemd/systemd

[bootctl] Regression: Silent failure to create EFI boot entry from within chroot

opened 12:06AM - 26 Jan 25 UTC

closed 11:39AM - 16 Apr 25 UTC

kjkent

bug 🐛 sd-boot/sd-stub/bootctl

### systemd version the issue has been seen with 257.2-2-arch ### Used distrib…ution Arch Linux ### Linux kernel version used 6.12.7-arch1-1 ### CPU architectures issue was seen on x86_64 ### Component bootctl ### Expected behaviour you didn't see 1) `bootctl {install,update}` creates an entry in the EFI. 2) If this fails, it should produce a warning. ### Unexpected behaviour you saw Finalising a new Arch Linux install (within a chroot from live installation media), running `bootctl install` appears to succeed, with no warnings generated. However, `bootctl` does not identify the EFI in this circumstance, leading to no boot entry being created. A user on the Arch forums reproduced this from within a chroot on their running system. It's possible that the common use of `arch-chroot` could be implicated; however, manually creating the entry with `efibootmgr` succeeds, suggesting that the EFI vars are accessible in the chroot. `/sys/firmware` is mounted from the host. ### Steps to reproduce the problem 1. From an Arch live media or installed system, use `arch-chroot` to chroot into a mounted root partition, with a boot partition mounted within. 2. `bootctl install` or `bootctl update` produces normal output (with the omission of the line `Created EFI boot entry "Linux Boot Manager"` in the case of the former). 3. `bootctl status` reports "Not booted with EFI" ### Additional program output to the terminal or log subsystem illustrating the issue There's a thread with others experiencing a similar issue on the [Arch Linux Forums](https://bbs.archlinux.org/viewtopic.php?id=301920). Here's console output from the initial first post there, first illustrating a successful EFI boot entry install, and then a failed one from within a chroot: ```Shell [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 all the hard work 🙏🏻

Similar issue:

Systemd-boot - Only windows as boot option