Maybe you can help me clear some things up. $ENTRY_DIR_ABS is exactly the same with both packages, see this diff from a clean install.
As I said in my comment, EndeavourOS’s overwrite of this file in /etc/ allows their kernel to not have this bug, since reverting this to default systemd shows this problem with core/linux as well:
# Boot Loader Specification type#1 entry
# File created by /usr/lib/kernel/install.d/90-loaderentry.install (systemd 253.1-3-arch)
title EndeavourOS
version 6.2.8-arch1-1
machine-id a6fa17c9e3f141f98c9e4891c216117c
sort-key endeavouros
options nvme_load=YES nowatchdog rw rootflags=subvol=/@ root=UUID=045a88e8-4ecf-4e2b-a24a-d57c50bc616c systemd.machine_id=a6fa17c9e3f141f98c9e4891c216117c
linux /efi/a6fa17c9e3f141f98c9e4891c216117c/6.2.8-arch1-1/linux
initrd /efi/a6fa17c9e3f141f98c9e4891c216117c/6.2.8-arch1-1/initrd
Not sure what to make of this, since ALHP does not change the kernel package besides the versioning and buildflags.
Here I have a simple workaround until it gets fixed, not ideal but works:
Create a file under /etc/kernel/install.d/ with the name starts with 91- and ends with .install, I’ll use 91-fix_loaderentry.install
Copy these to /etc/kernel/install.d/91-fix_loaderentry.install
#!/bin/sh
for entry in /efi/loader/entries/$(cat /etc/machine-id)-*.conf
do
sed -i 's/linux \/efi/linux /g' "$entry"
sed -i 's/initrd \/efi/initrd /g' "$entry"
done
I added the ALHP v3 repo to my installation to try and I am not hit by this issue.
No packages in IgnorePkg. Using dracut and systemd-boot. Even had a kernel update now after the initial big update of all packages.
The only difference: I migrated an “old” grub+mkinitcpio install to dracut+systemd-boot and kept my EFI partition mounted at /boot/efi/ instead of remounting it to the now EndeavourOS-default /efi. @anonfunc maybe this helps in debugging.
Just did a fresh install. Issue persists, the additional “/efi” in linux and linuxrd path in the loader is always created if I use ALHP repo and eos standard scripts/hooks for kernel updates.
There is not much we can do about this on our end. We did the testing and identified the packages that behave differently when installed from ALHP. Someone from ALHP needs to investigate further.
I did some tests and found out that the problem was caused by coreutils and not util-linux*. To be specific, stat -c %m "$BOOT_ROOT" gives different outputs for ESP mountpoint which breaks some variables. I posted a more detailed post at ALHP issues, can be found at