My knowledge about initramfs and Kernel is limited. I am practically a noob in this. All I know is that Kernel (/boot/vmlinuz-linux-*) gets loaded first, then the system initialization is run (/boot/initramfs-linux-*.img), then the root file system is loaded and finally the init program (in case of EOS it is systemd) is run. So please bear with me if I ask a stupid or rookie question.
EOS creates a fall back initramfs for each and every kernel that we install. If we use LTS kernel there will be a backup initramfs created for it, i.e. /boot/initramfs-linux-lts-fallback.img. If use a the mainline kernel than similarly a backup initramfs for that is created too.
So my questions are as follows
Firstly if we update to say the latest mainline Linux kernel, which happens to be as on today 6.16.3, then while installing it can we also create the old fallback mainline kernel image, i.e. ver 6.16.2? This will help to isolate any issues that happen. Right now the recommended practice is to use the Linux LTS kernel (6.12/6.6/6.1) as the fallback. If this option to boot from the latest version - 1 is added to the “Advanced boot options” then it will help in troubleshooting.
Secondly when the fallback initramfs is created, how is it different than the normal initramfs? What items are omitted? What is added?
Thirdly and finally many other distributions mention the version number in the Linux Kernel file, i.e. vmlinuz-linux-* as well as the initramfs file, i.e. initramfs-linux-*.img. So the Linux Kernel file will be named vmlinuz-linux-6.16.3 and the initramfs file will be named initramfs-linux-6.16.3.img EOS does not do this. Was there some benefit in doing so? I am not saying that EOS should not do this. Nor am I saying that it is bad. I am just curious.
Having the release number appended to both Kernel and initramfs filename does have some obvious advantages.
In an Arch-based distro, that would be difficult as Arch uses the same package for each kernel version. This means, you can’t easily have two different versions installed at the same time. For use to change that on EOS would require us to either repackage all the kernels or do something very hacky like add hooks to copy all the old kernel files around before and after an upgrade. Neither of those things really make sense.
It has additional drivers and omits certain host-specific config files.
If you use systemd-boot, we put them in directories that have the version numbers and we add the version numbers to the boot menu. For other bootloaders, we could rename the kernel and initrds and append the version to the name but I don’t see any obvious benefit in doing so. It seems like mostly downsides from my perspective.
Many of us use GRUB2 for booting. And having the version of the Linux Kernel and initramfs mentioned in their filename would actually help us a lot.
Is it possible to modify a file either in /etc/grub.d/ or in /etc/dracut.conf.d/ or some other directory to have the kernel and initramfs created with the version number? On every update? I believe that GRUB configuration would have to be modified so that the BOOT_IMAGE key picks up the modified filename.
Also one more question, in the /etc/dracut.conf.d/eos-defaults.conf file there is a key omit_dracutmodules. Can we add btrfs, lvm to this, if we do not use them? Or will it be better to put them in another conf file inside /etc/dracut.conf.d/?
Both the kernels in /boot and the initrds are generated by pacman hooks. You can override the hooks in eos-dracut and your kernel package to give them whatever name you want.
You should put your own changes in a separate file.
However, if you are trying to limit what is in your initrd it would probably make more sense to set hostonly_mode=strict which will only bring the drivers present on your system. Although, again, you should think through if that really helps in you in any way.
Only having mainline and LTS kernels needs getting used to, I found. These sometimes can be quite a few versions apart.
Having used (and still also using) Mint for many years, I quite liked their system to keep the current plus the last two installed kernels (depending on settings). Sometimes saved my butt.
In case of emergency, for those not using systemd-boot, just looking at the files present in the /boot directory would give info on what Linux Kernels were present. Secondly when we uninstall any Kernel, by just looking at the file names we can confirm which version was removed and which are left.
It makes it easy to use the ls -al or eza to get the relevant information at a glance.
Thanks. Will look at that.
Thanks for the tip about putting the changes in a separate file. Will follow it.
I did not know that we can limit what is there in initramfs. I assumed it was fixed based on the kernel in use. Thanks for the info on hostonly_mode. Will dig a bit deeper on that.
I did not know that about Mint. Thanks. Have not used Mint. Have heard a lot of good about it, but never dipped my toes in it. Two things put me off. First was lack of KDE. It had Cinnamon, XFCe and MATE. And offcourse Mint did not have the rolling distro characteristics of Arch/EOS. Both of these were deal killers for me.
Yes, I can see how having Linux Kernels 6.16.3 and 6.13.2 would be useful to fix issues caused by rolling updates. But why does Mint keep last two installed kernels? Isnt that a overkill? One would suffice IMHO. So if Mint were to have Linux Krenel 6.13.3 installed then keep 6.13.2 too. If required it might make more sense to defer to the EOS recommendation to use the Linux LTS Kernel, i.e. 6.12.x/6.6.x/6.1.x. So Mint should have Linux Kernl 6.13.3, 6.13.2 and LTS 6.12.x/6.6.x/6.1.x.
I am not saying that what Mint is doing is wrong. Nor am I saying that EOS should follow this.
@Moonbase59 If you are using Mint would it be possible for you to compare the initramfs of both Mint and EOS? How do they differ? Does Mint use the version number in the kernel and initramfs file too?
Thanks @dalto. Thanks @Moonbase59. I learn a ton of stuff by just being on this forum. The community is just awesome.
You can get the information with ls without that. The kernels in /boot are a just a copy. The kernels are actually installed to /usr/lib/modules/ so can easily just ls that to see what kernels are installed.
