Kernel update breaks systemd boot config #174
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I reproduced this on 2 PCs when using ALHP repos
After kernel update, the config for /efi/loader/entries/(magicnumber).conf
This is with vanilla
70c74eda65ce4814be68c45b2fee4edf-6.2.8-zen1-1-zen.conf ✔
title EndeavourOS
version 6.2.8-zen1-1-zen
machine-id 70c74eda65ce4814be68c45b2fee4edf
sort-key endeavouros-6.2.8-zen1-1-zen
options nvidia-drm.modeset=1 nvme_load=YES rw root=UUID=7560cfaa-bc1a-4f03-8827-a736bdbc0bc9 systemd.machine_id=70c74eda65ce4814be68c45b2fee4edf
linux /70c74eda65ce4814be68c45b2fee4edf/6.2.8-zen1-1-zen/linux
initrd /70c74eda65ce4814be68c45b2fee4edf/6.2.8-zen1-1-zen/initrd
This is with ALHP
title Arch Linux
version 6.2.8-zen1-1.1-zen
machine-id 70c74eda65ce4814be68c45b2fee4edf
sort-key arch-6.2.8-zen1-1.1-zen
options nvidia-drm.modeset=1 nvme_load=YES rw root=UUID=7560cfaa-bc1a-4f03-8827-a736bdbc0bc9 systemd.machine_id=70c74eda65ce4814be68c45b2fee4edf
linux /efi/70c74eda65ce4814be68c45b2fee4edf/6.2.8-zen1-1.1-zen/linux
initrd /efi/70c74eda65ce4814be68c45b2fee4edf/6.2.8-zen1-1.1-zen/initrd
The additional "/efi/" in front of linux and initrd is incorrect.
If I switch to ALHP and update/reinstall the kernel this happens.
This does not happen with vanilla arch repo.
Do you generate these entries with something?
I do this with the systemd script kernel-install.
After installing the kernel with pacman, the vorresponding hook is called automatically.
I also use ALHP repos, linux-zen and systemd-boot and I have no issues. But I also don't use the pacman hook, what's the purpose of it?
https://forum.endeavouros.com/t/kernel-install-generates-wrong-configs-alhp-repo/38908
More details here. Afaik the script kernel-install will call dracut to generate initrd and boot entries.
After some debugging on a fresh EndeavourOS install I can confirm this is (at least to some extend) an EndeavourOS specific problem. As soon as you revert their overwrite of
90-loaderentry.install
in/etc/kernel/install.d/90-loaderentry.install
(coming fromkernel-install-from-dracut
) to default to systemd's own version in/usr/lib/kernel/install.d/90-loaderentry.install
, evencore/linux
has the same generation problem.My guess is whatever EndeavourOS modified in
90-loaderentry.install
does somehow break with the ALHP kernel, even tho besides versioning and buildflags, this is the same kernel that Arch (and EndeavourOS) also uses.Sadly I have no time to debug this further today, just wanted to summarize what I found so far.
Seems the issue still persists. I have my ESP partition at /efi and every time I update the kernel with ALHP packages, it breaks loader.conf path just as described above.
It works completely fine with standard arch repo.
I did some tests and found out that this issue is actually not related to EndeavourOS and probably caused by
coreutils
package. To be specific,stat -c %m "$BOOT_ROOT"
gives different outputs for ESP mount point which breaks some variables.The issue is not related to systemd's or EndeavourOS's
90-loaderentry.install
file, nor is it related to custom kernels.Both
KERNEL_ENTRY
variable ("$ENTRY_DIR/linux"
) and initrd location ($ENTRY_DIR/initrd
) depends onENTRY_DIR
variable.ENTRY_DIR
variable defines with this codeand it also depends on other variables,
BOOT_MNT
andENTRY_DIR_ABS
.ENTRY_DIR_ABS
is /ESP/machine-id/kernel-version (e.g. /efi/e607b55c7dbe48bb987073ang984237d/6.5.3-arch1-1.1).BOOT_MNT
defines with[ -n "$BOOT_MNT" ] || BOOT_MNT="$(stat -c %m "$BOOT_ROOT")"
. First it checks ifBOOT_MNT
is a non-empty variable (it's not) and if it's not, it setsBOOT_MNT
to mount point ofESP
directory. The command returns the expected output (e.g. /efi, /boot) withcore/coreutils
package but withcore-x86-64-v3/coreutils
package it prefixes output with an extra slash (/) (e.g. //efi, //boot).BOOT_MNT
's value is not/
soENTRY_DIR
variable defines with"${ENTRY_DIR_ABS#"$BOOT_MNT"}"
. Now the problem is shell can't cut//efi
string fromENTRY_DIR_ABS
because it starts with/efi/....
, not//efi/....
.I tried this with fresh installations of both EndeavourOS and Arch Linux and they both have this problem.
Temporary solutions are either executing a script that runs after
90-loaderentry.install
to remove extra/efi
strings or using theBOOT_ROOT
variable instead ofBOOT_MNT
forENTRY_DIR
.This problem might be more than a
coreutils
problem because as far as I can tellstat -c %m /efi
just prints the mountpoint.Values used by systemd's
90-loaderentry.install
w/core/coreutils
& Arch LinuxValues used by systemd's
90-loaderentry.install
w/core-x86-64-v3/coreutils
& Arch LinuxValues used by EndeavourOS'es
90-loaderentry.install
w/core/coreutils
& EndeavourOSValues used by EndeavourOS'es
90-loaderentry.install
w/core-x86-64-v3/coreutils
& EndeavourOSSimilar outputs can be achieved by appling this patch to
90-loaderentry.install
.Interesting. We could always decide to not build
coreutils
, but that kind of defeats the purpose.Seems like
stat -c %m <mountpoint>
is the real culprit here. Not sure where the extra slash comes from.Cloud not find a related bugreport either. If I find time I can get onto the coreutils ML and check if the folks there have any idea.
In the meantime I have decided to exclude
coreutils
, so that we have a working solution until we find out what exactly is causing this.