Kernel-install generates wrong configs (ALHP repo)

General system
43

Hi guys, ALHP dev here.

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.

3 Likes
44

I cannot duplicate your results. I am not sure what your testing methodology is.

Here is what I get on a non-ALHP EOS install after removing kernel-install-for-dracut and reverting to a stock systemd-boot setup.

# 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 e0c7ce7d722a410298a066e0c778bdcf
sort-key   endeavouros
options    nvme_load=YES nowatchdog rw root=UUID=f8634b0c-aed0-470e-9136-e98dfaf5914c systemd.machine_id=e0c7ce7d722a410298a066e0c778bdcf
linux      /e0c7ce7d722a410298a066e0c778bdcf/6.2.8-arch1-1/linux
initrd     /e0c7ce7d722a410298a066e0c778bdcf/6.2.8-arch1-1/initrd

Here is my testing methodology:

sudo pacman -Rc kernel-install-for-dracut
sudo rm /efi/loader/entries/*
sudo kernel-install add 6.2.8-arch1-1 /usr/lib/modules/6.2.8-arch1-1/vmlinuz
1 Like
45

I did some further testing with ALHP.

It seems the issue is related to util-linux / util-linux-libs.

Installing removing those packages from ALHP triggers/resolves the issue.

2 Likes
46

Welcome to the EndeavourOS forum. I hope you enjoy your time here.

Thank you for collaborating with us. :handshake:

Pudge

2 Likes
47

That’s interesting. I’ll test this again later to see if I can narrow it down. Thanks for your time debugging/testing :+1:

4 Likes
48

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

Make it executable:

sudo chmod +x /etc/kernel/install.d/91-fix_loaderentry.install

Then execute

sudo reinstall-kernels

Don’t forget to check entries with bootctl list before reboot.

Hope it helps someone

1 Like
49

Wouldn’t it be much easier/more sensible to simply use util-linux and util-linux-libs from the Arch repos until this is resolved?

1 Like
50

Yes, it would. I’d also add these packages to IgnorePkg until the problem is fixed.

1 Like
51

Dear all,

Problem is still present. Is there any solution besides making manual script or putting util-linux and util-linux-libs on ignore list?

52

Since this seems to be an issue with the packages in the 3rd party repo you might ask the repo maintainers.

53

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.

2 Likes
54

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.

55

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.

56

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

1 Like