Kernel-install generates wrong configs (ALHP repo)

so it now happens with arch standard repo?

I don’t know, I only have systemd from arch, most of the stuff is from ALHP

It is just weird. Have to tried reverting everything to standard arch?

No, it will take A LOT of time. But if it’s their problem, then let them fix it. I have another machine though, with vanilla repos, let me try that one

1 Like

Sooo, vanilla indeed does work as expected. That’s nice. Some package in ALHP is goofy

I have never used the ALHP repos, so this is a legit question, I am not trying to be snarky.
What are the advantages of using ALHP over the standard Archlinux repos?


if so this is not a BUG on EndeavourOS and should get reported where it belongs too :wink:


Performance. The binaries are optimized for more modern CPUs.


Thank you.


How does kernel-install generate the boot entries?
It seems weird to me that with ALHP the kernel is called “Arch Linux” while with vanilla repo it is called “EndeavourOS”

title EndeavourOS
in the loader conf files…

endeavouros/kernel-install-for-dracut 1.7-5 (15.4 KiB 19.3 KiB) (Installiert)
    Enables systemd-boot automation using kernel-install with dracut

Enables systemd-boot automation using kernel-install with dracut

1 Like

kernel-install is part of systemd. I am not sure where it gets the name from but presumably it is a standard location like os-release or similar.

EDIT: I just looked, it does come from /etc/os-release

Yes, that is strange. I am not sure what is going on there as I have never used ALHP.

could be it fails to run hooks or hooks are not installed so it shows archlinux in os-release ?

Maybe. Although if they weren’t installed, switching back to Arch packages wouldn’t fix it.

i could think of one possibility… if package name is different… it could be the hook is not getting the trigger…

I suppose it is theoretically possible but that seems highly unlikely since the ALHP repo should just be the same packages built with a different target.

If they were changing package names, that would cause all sorts of chaos.

and if so… this file is not installed by a package anyway i think? :melting_face:

It is part of filesystem. That is a symlink to the actual file.

FYI, I posted this on ALHP site under

They are still debugging this, but it is related to 90-loaderentry.install script.

1 Like

That script is what creates the entries so it would be hard to argue it isn’t related to that.

However, that script is just accessing the variable $ENTRY_DIR_ABS which is passed into the script.