ALHP
/
ALHP.GO
6
34
Fork 9
Code Issues 30 Pull Requests Projects Releases Wiki Activity

Kernel update breaks systemd boot config #174

New Issue
Open
opened 2023-03-25 11:02:10 +01:00 by alatikus · 9 comments
alatikus commented 2023-03-25 11:02:10 +01:00
Copy Link

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.

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.
anonfunc commented 2023-03-26 12:38:53 +02:00
Owner
Copy Link

Do you generate these entries with something?

Do you generate these entries with something?
anonfunc added the
support
 label 2023-03-26 12:38:58 +02:00
alatikus commented 2023-03-26 13:24:34 +02:00
Author
Copy Link

I do this with the systemd script kernel-install.

After installing the kernel with pacman, the vorresponding hook is called automatically.

I do this with the systemd script kernel-install. After installing the kernel with pacman, the vorresponding hook is called automatically.
dataprolet commented 2023-03-26 13:49:44 +02:00
Copy Link

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?

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?
alatikus commented 2023-03-26 14:20:25 +02:00
Author
Copy Link

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.

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.
anonfunc commented 2023-03-27 00:11:22 +02:00
Owner
Copy Link

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 from kernel-install-from-dracut) to default to systemd's own version in /usr/lib/kernel/install.d/90-loaderentry.install, even core/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.

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 from `kernel-install-from-dracut`) to default to systemd's own version in `/usr/lib/kernel/install.d/90-loaderentry.install`, even `core/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.
alatikus commented 2023-07-05 20:01:14 +02:00
Author
Copy Link

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.

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.
onurmercury commented 2023-09-17 19:35:16 +02:00
Copy Link

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 on ENTRY_DIR variable. ENTRY_DIR variable defines with this code

if [ "$BOOT_MNT" = '/' ]; then
    ENTRY_DIR="$ENTRY_DIR_ABS"
else
    ENTRY_DIR="${ENTRY_DIR_ABS#"$BOOT_MNT"}"
fi

and it also depends on other variables, BOOT_MNT and ENTRY_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 if BOOT_MNT is a non-empty variable (it's not) and if it's not, it sets BOOT_MNT to mount point of ESP directory. The command returns the expected output (e.g. /efi, /boot) with core/coreutils package but with core-x86-64-v3/coreutils package it prefixes output with an extra slash (/) (e.g. //efi, //boot).

BOOT_MNT's value is not / so ENTRY_DIR variable defines with "${ENTRY_DIR_ABS#"$BOOT_MNT"}". Now the problem is shell can't cut //efi string from ENTRY_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 the BOOT_ROOT variable instead of BOOT_MNT for ENTRY_DIR.

This problem might be more than a coreutils problem because as far as I can tell stat -c %m /efi just prints the mountpoint.

Values used by systemd's 90-loaderentry.install w/ core/coreutils & Arch Linux

BOOT_ROOT: /boot
--
BOOT_MNT is empty or not defined
BOOT_MNT if it's empty: /boot
--
ENTRY_DIR_ABS: /boot/_machine-id_/6.5.3-arch1-1.1
ENTRY_DIR_ABS but BOOT_MNT got cut: /_machine-id_/6.5.3-arch1-1.1
ENTRY_DIR: /_machine-id_/6.5.3-arch1-1.1
--
KERNEL_ENTRY: /_machine-id_/6.5.3-arch1-1.1/linux
initrd: /_machine-id_/6.5.3-arch1-1.1/initrd

Values used by systemd's 90-loaderentry.install w/ core-x86-64-v3/coreutils & Arch Linux

BOOT_ROOT: /boot
--
BOOT_MNT is empty or not defined
BOOT_MNT if it's empty: //boot
--
ENTRY_DIR_ABS: /boot/_machine-id_/6.5.3-arch1-1.1
ENTRY_DIR_ABS but BOOT_MNT got cut: /boot/_machine-id_/6.5.3-arch1-1.1
ENTRY_DIR: /boot/_machine-id_/6.5.3-arch1-1.1
--
KERNEL_ENTRY: /boot/_machine-id_/6.5.3-arch1-1.1/linux
initrd: /boot/_machine-id_/6.5.3-arch1-1.1/initrd

Values used by EndeavourOS'es 90-loaderentry.install w/ core/coreutils & EndeavourOS

BOOT_ROOT: /efi
--
BOOT_MNT is empty or not defined
BOOT_MNT if it's empty: /efi
--
ENTRY_DIR_ABS: /efi/_machine-id_/6.5.3-AMD-znver3
ENTRY_DIR_ABS but BOOT_MNT got cut: /_machine-id_/6.5.3-AMD-znver3
ENTRY_DIR: /_machine-id_/6.5.3-AMD-znver3
--
KERNEL_ENTRY: /_machine-id_/6.5.3-AMD-znver3/linux
initrd: /_machine-id_/6.5.3-AMD-znver3/initrd

Values used by EndeavourOS'es 90-loaderentry.install w/ core-x86-64-v3/coreutils & EndeavourOS

BOOT_ROOT: /efi
--
BOOT_MNT is empty or not defined
BOOT_MNT if it's empty: //efi
--
ENTRY_DIR_ABS: /efi/_machine-id_/6.5.3-AMD-znver3
ENTRY_DIR_ABS but BOOT_MNT got cut: /efi/_machine-id_/6.5.3-AMD-znver3
ENTRY_DIR: /efi/_machine-id_/6.5.3-AMD-znver3
--
KERNEL_ENTRY: /efi/_machine-id_/6.5.3-AMD-znver3/linux
initrd: /efi/_machine-id_/6.5.3-AMD-znver3/initrd

Similar outputs can be achieved by appling this patch to 90-loaderentry.install.

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 on `ENTRY_DIR` variable. `ENTRY_DIR` variable defines with this code ``` if [ "$BOOT_MNT" = '/' ]; then ENTRY_DIR="$ENTRY_DIR_ABS" else ENTRY_DIR="${ENTRY_DIR_ABS#"$BOOT_MNT"}" fi ``` and it also depends on other variables, `BOOT_MNT` and `ENTRY_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 if `BOOT_MNT` is a non-empty variable (it's not) and if it's not, it sets `BOOT_MNT` to mount point of `ESP` directory. The command returns the expected output (e.g. /efi, /boot) with `core/coreutils` package but with `core-x86-64-v3/coreutils` package it prefixes output with an extra slash (/) (e.g. //efi, //boot). `BOOT_MNT`'s value is not `/` so `ENTRY_DIR` variable defines with `"${ENTRY_DIR_ABS#"$BOOT_MNT"}"`. Now the problem is shell can't cut `//efi` string from `ENTRY_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](https://forum.endeavouros.com/t/kernel-install-generates-wrong-configs-alhp-repo/38908/48?u=ripsivis) that runs after `90-loaderentry.install` to remove extra `/efi` strings or using the `BOOT_ROOT` variable instead of `BOOT_MNT` for `ENTRY_DIR`. This problem might be more than a `coreutils` problem because as far as I can tell `stat -c %m /efi` just prints the mountpoint. --- Values used by systemd's `90-loaderentry.install` w/ `core/coreutils` & Arch Linux ``` BOOT_ROOT: /boot -- BOOT_MNT is empty or not defined BOOT_MNT if it's empty: /boot -- ENTRY_DIR_ABS: /boot/_machine-id_/6.5.3-arch1-1.1 ENTRY_DIR_ABS but BOOT_MNT got cut: /_machine-id_/6.5.3-arch1-1.1 ENTRY_DIR: /_machine-id_/6.5.3-arch1-1.1 -- KERNEL_ENTRY: /_machine-id_/6.5.3-arch1-1.1/linux initrd: /_machine-id_/6.5.3-arch1-1.1/initrd ``` Values used by systemd's `90-loaderentry.install` w/ `core-x86-64-v3/coreutils` & Arch Linux ``` BOOT_ROOT: /boot -- BOOT_MNT is empty or not defined BOOT_MNT if it's empty: //boot -- ENTRY_DIR_ABS: /boot/_machine-id_/6.5.3-arch1-1.1 ENTRY_DIR_ABS but BOOT_MNT got cut: /boot/_machine-id_/6.5.3-arch1-1.1 ENTRY_DIR: /boot/_machine-id_/6.5.3-arch1-1.1 -- KERNEL_ENTRY: /boot/_machine-id_/6.5.3-arch1-1.1/linux initrd: /boot/_machine-id_/6.5.3-arch1-1.1/initrd ``` Values used by EndeavourOS'es `90-loaderentry.install` w/ `core/coreutils` & EndeavourOS ``` BOOT_ROOT: /efi -- BOOT_MNT is empty or not defined BOOT_MNT if it's empty: /efi -- ENTRY_DIR_ABS: /efi/_machine-id_/6.5.3-AMD-znver3 ENTRY_DIR_ABS but BOOT_MNT got cut: /_machine-id_/6.5.3-AMD-znver3 ENTRY_DIR: /_machine-id_/6.5.3-AMD-znver3 -- KERNEL_ENTRY: /_machine-id_/6.5.3-AMD-znver3/linux initrd: /_machine-id_/6.5.3-AMD-znver3/initrd ``` Values used by EndeavourOS'es `90-loaderentry.install` w/ `core-x86-64-v3/coreutils` & EndeavourOS ``` BOOT_ROOT: /efi -- BOOT_MNT is empty or not defined BOOT_MNT if it's empty: //efi -- ENTRY_DIR_ABS: /efi/_machine-id_/6.5.3-AMD-znver3 ENTRY_DIR_ABS but BOOT_MNT got cut: /efi/_machine-id_/6.5.3-AMD-znver3 ENTRY_DIR: /efi/_machine-id_/6.5.3-AMD-znver3 -- KERNEL_ENTRY: /efi/_machine-id_/6.5.3-AMD-znver3/linux initrd: /efi/_machine-id_/6.5.3-AMD-znver3/initrd ``` Similar outputs can be achieved by appling [this patch](https://gist.github.com/onurmercury/b08117b9b314af57f32c06b079ae8b27) to `90-loaderentry.install`.
anonfunc commented 2023-09-18 12:38:37 +02:00
Owner
Copy Link

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.

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.
👍 1
anonfunc commented 2023-09-22 18:00:58 +02:00
Owner
Copy Link

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.

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.
👍 1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
Labels
Clear labels   
blocked upstream

   
bug

Something is not working

  
build-failure

package build fails because of our added buildflags

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
help wanted

Need some help

  
informational

Provides information about something

  
invalid

Something is wrong

  
invalid/corrupt package

Package needs to be rebuild

  
packaging issue

   
priority: high

High priority

  
question

More information is needed

  
support

   
wontfix

This won't be fixed

No Label
blocked upstream
bug
build-failure
duplicate
enhancement
help wanted
informational
invalid
invalid/corrupt package
packaging issue
priority: high
question
support
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: ALHP/ALHP.GO#174
No description provided.
Delete Branch "%!s(<nil>)"

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?