@dalto @joekamprad
since I can no longer answer in this thread because closed.
you are right, it doesnt works. had kernel updates today and after the first restart i had to select, after the second restart the previously selected kernel was saved in the boot menu
that leads to another question @dalto - why do we tell dracut to add the Kernel version number to the initramfs for systemd-boot, while it is possible to omit it, like can be seen when using dracut for grub/refind?
If we omit the version number with dracut for systemd-boot, the @saved - config would work even with kernel updates.
If set to “@saved” the chosen entry will be saved as an EFI variable on every boot and automatically selected the next time the boot loader starts.
So from this (not much of information) it will save the last used entry it does not say by what identification mechanism it does this… but I bet it uses /efi/loader/entries/ these are looking like this:
/efi/loader/entries/02c16dd8469bXXXXXX490266c65-6.1.11-arch1-1.conf so on kernel updates the entry will not be present anymore but variable is still the old… what will lead to not be able to boot that entry. What you say looks like it is not able to remove that variable anymore and always boot the last selected and now non existing entry? or it is replacing with the one selected on non working boot?
It has nothing to do with dracut or the naming of initrds. It has to do with the name of the entries changing. If you want to alter the names, you can do so by changing the functionality of the kernel-install scripts by modifying them or overriding them in /etc/kernel/install.d. The original files are in /usr/lib/kernel/install.d
❯ /efi/loader/entries
26fdf41f32ee4458b1e35805529ff120-5.15.94-1-lts-fallback.conf 26fdf41f32ee4458b1e35805529ff120-6.1.12-arch1-1.conf
26fdf41f32ee4458b1e35805529ff120-5.15.94-1-lts.conf 26fdf41f32ee4458b1e35805529ff120-6.1.12-zen1-1-zen-fallback.conf
26fdf41f32ee4458b1e35805529ff120-6.1.12-arch1-1-fallback.conf 26fdf41f32ee4458b1e35805529ff120-6.1.12-zen1-1-zen.conf
/efi/loader/loader.conf:
default @saved
timeout 5
console-mode auto
reboot-for-bitlocker 1
the systemd boot menu starts with
arch
lts
zen
It has arch kernel as default. i could choose which kernel i wanted to start. I selected zen kernel, started it and after a reboot zen-kernel was the default. so the kernel which was started last.
what you say about variables is beyond my knowledge
If all you want to do is pick a kernel to boot by default, that is easily achieved by modifying /efi/loader/loader.conf. The instructions for that are in our wiki.
The thing that is challenging is if you frequently change kernels and want it to remember the one you picked last.
Exactly!
That’s why:
Why is the EndeavourOS default a default that breaks systemd-boot functionality?
if that was named:
26fdf41f32ee4458b1e35805529ff120-lts.conf the feature would work.
it is not a big problem for me to make a selection after a kernel update. i just wanted to point out to @dalto that he is right in his post from yesterday
That is the systemd-boot default, not the EndeavourOS default.
the problematic part is coming from here:
dracut --force --hostonly --no-hostonly-cmdline${DRACUT_EXTRA_PARAMS} "${INITRD_PATH}/initrd ${kernelversion}"
if it would read "${INITRD_PATH}/initrd ${pkgbase}" like it does here:
the @saved parameter will work because the version numbers don’t appear, or do I read that wrong?
That script doesn’t get called when kernels are removed added. That is a helper script that is built to help you rebuild the initrds without calling kernel-install. It is using the same locations as kernel-install uses by default.
You can modify or delete that script, it would have no impact on what happens when you add/update/remove kernels.
This is correct.
after an update, systemd loads the first kernel in the queue. when i selected a kernel, it always loads the selected one
then change the remove/add script to the same way - you are the one that wrote it, I am just a user trying to hint you into getting the defaults into a way that it does not break features (e.g. the @saved paramter that works on a native arch install, because there they omit the version numbers when generating the initramfs and the following conf-files for systemd-boot …)
you read that statement out of context and before my edit to clarify it.
What breaks the @saved config is the fact that EndeavourOS adds the version number to the initramfs file which in return adds the version number to the .conf file. Removing the version number from the initramfs also removes the version number from the following .conf file - which in return leads to the @saved entry working even after kernel updates - because the .conf file name does not change anymore with kernel updates, the rest of the functionality and flexibility that systemd-boot offers stays the same.
That is what I am saying, I didn’t write it. I made some minor modifications to the way that systemd-boot works by default. What you are wanting changed is how systemd-boot/kernel-install works by default.
please excuse me, i didn’t mean to cause any trouble. please keep in mind that english is not my native language. i have to translate everything (most of it).
i’m just a simple user. i’m not even able to read any scripts. here in this forum and since i’m using eos i’ve learned more than ever in my life about linux and what it means. i’ve never absorbed so much information as here about kernel systemd.
the primary goal was just to point out to dalto that he was right in his post from yesterday.
no problems. I wrote you a message
But systemd-boot/kernel-install works in the way that I explained here, doesn’t it? If it does not work that way, that is a bug because the @saved entry couldn’t possibly work on any distribution
I think the only thing that I am changing in the file is the sort order.
This is from the unmodified file that comes with the package from upstream:
LOADER_ENTRY="$BOOT_ROOT/loader/entries/$ENTRY_TOKEN-$KERNEL_VERSION.conf"
i tried in a VM install, the behaviour is, that the @saved - entry is not present anymore after a kernel update, so systemd-boot chooses the first entry in the boot menu again, but saves the then used entry successfully. Practically speaking: On a kernel update, on the next boot, one has to choose the wanted entry again and after that it remembers that decision until the next kernel update happens or the user decides to use another entry. (Which for my usecase would be enough, sometimes I have to use Windows or another kernel and I want that to be the same for several reboots - especially when my only 5 or 6 times per year used Windows wants to do several updates with reboots in a row … )
Thanks.
With the tinkering in my VM install, I found out that I was wrong. The initramfs-file actually does not contain the version number at all (except for when one runs the dracut-rebuild tool manually, the automatic tools don’t add the version number?!?)
But the loader entry .conf file still contains the version number, maybe because the version number is existing on a filesystem-level (folder and file):
[vbox@virtualbox 6.1.12-arch1-1]$ file *
initrd: ASCII cpio archive (SVR4 with no CRC)
initrd-fallback: ASCII cpio archive (SVR4 with no CRC)
linux: Linux kernel x86 boot executable bzImage, version 6.1.12-arch1-1 (linux@archlinux) #1 SMP PREEMPT_DYNAMIC Tue, 14 Feb 2023 22:08:08 +0000, RO-rootFS, swap_dev 0XA, Normal VGA
so for the @saved entry to fully work across kernel updates, the generation of the .conf files has to be modified to not contain the version number, only the kernel name (arch, zen, lts, ck or whatever) which still makes it configureable as a fixed default, but also leads to a never-changing file name. Unfortunately, I don’t have time anymore to tinker with that, but most likely on the weekend I will continue and try to reach that, and also check if that can be done in a way that could be added to EndeavourOS.
I think this is what you are saying but just to be totally clear. It isn’t a problem if the conf file contains the version information in the paths inside the conf file. That is expected. So options, initrd and linux lines don’t need to change.
Exactly. Only the filenames of the UUID-VERSION-KERNELNAME(fallback).conf files inside esp/loader/entries should need to be changed to remove the VERSION number sequence from their name. The contents shouldn’t matter. Still have to try if that is enough but most likely will have time on the weekend.