Append kernel version numbers to those generated in /boot

Hello Endeavour Community,
I am new to this distro (but not to linux) and just wanted to say how awesome and painless it is to get a working system with arch packages!

I am setting up rEFInd to boot my kernel directly rather than going through grub, but it is only detecting my vmlinuz-linux-lts file, plus the grub efi file. In reading the steps outlined here the dev explains that rEFInd searches for matching kernel version strings load the initramfs and vmlinuz. I am pretty sure this is the job mkinitcpio, but I cannot find any flag that adds kernel version numbers.

Am I going about using rEFInd the right way? If I can get version numbers working, I believe it will detect all kernels and provide me with the options outlined in my refind_linux.conf

More info:

~> ls /boot/
-rw------- 1 root root  33M Feb  3 22:19 initramfs-linux-fallback.img
-rw------- 1 root root 8.6M Feb  3 22:19 initramfs-linux.img
-rw------- 1 root root  31M Feb  3 22:19 initramfs-linux-lts-fallback.img
-rw------- 1 root root 8.6M Feb  3 22:18 initramfs-linux-lts.img
-rw-r--r-- 1 root root 4.6M Jun  8  2021 intel-ucode.img
-rw-r--r-- 1 root root  424 Feb  4 10:36 refind_linux.conf
-rw-r--r-- 1 root root  11M Feb  2 22:58 vmlinuz-linux
-rw-r--r-- 1 root root 9.9M Feb  2 23:00 vmlinuz-linux-lts

Contents of refind_linux.conf

"Boot with standard options"  "root=UUID=9758ddc4-5180-4614-bb9b-49dff3e94309 rw rootflags=subvol=@ loglevel=3 nowatchdog nvme_load=YES nvidia-drm.modeset=1 mem_sleep_default=deep"
"Boot to single-user mode"    "root=UUID=9758ddc4-5180-4614-bb9b-49dff3e94309 rw rootflags=subvol=@ loglevel=3 nowatchdog nvme_load=YES nvidia-drm.modeset=1 mem_sleep_default=deep single"
"Boot with minimal options"   "ro root=/dev/nvme0n1p4"

Contents of refind.conf

timeout 7
use_nvram false
screensaver 300
banner 1.png
banner_scale fillscreen
resolution max
scanfor internal,external,optical
menuentry Linux {
    icon EFI/refind/icons/os_linux.png
    volume 904404F8-B481-440C-A1E3-11A5A954E601
    loader bzImage-3.3.0-rc7
    initrd initrd-3.3.0.img
    options "ro root=UUID=5f96cafa-e0a7-4057-b18f-fa709db5b837"
menuentry "Arch Linux" {
    icon     /EFI/refind/icons/os_arch.png
    volume   "Arch Linux"
    loader   /boot/vmlinuz-linux
    initrd   /boot/initramfs-linux.img
    options  "root=PARTUUID=5028fa50-0079-4c40-b240-abfaf28693ea rw add_efi_memmap"
    submenuentry "Boot using fallback initramfs" {
        initrd /boot/initramfs-linux-fallback.img
    submenuentry "Boot to terminal" {
        add_options ""
menuentry Ubuntu {
    loader /EFI/ubuntu/grubx64.efi
    icon /EFI/refind/icons/os_linux.png
menuentry "ELILO" {
    loader \EFI\elilo\elilo.efi
menuentry "Windows 7" {
    loader \EFI\Microsoft\Boot\bootmgfw.efi
menuentry "Windows via shell script" {
    icon \EFI\refind\icons\os_win.png
    loader \EFI\tools\shell.efi
    options "fs0:\EFI\tools\launch_windows.nsh"
menuentry "My macOS" {
    icon \EFI\refind\icons\os_mac.png
    volume "macOS boot"
    loader \System\Library\CoreServices\boot.efi
menuentry "macOS via BootNext" {
    icon /EFI/refind/icons/os_mac.png
    firmware_bootnum 80

TLDR: How to append kernel version numbers to vmlinuz and initrd in /boot/

I have never heard of refind requiring this. However, if you want to do it, you would need to override the hook that calls mkinitcpio and copies the kernel to /boot. You could then parse the version number out of the path.

I do something somewhat similar for systemd-boot if you want a reference:


This is not the root issue.

This is the root issue.

Yes, you are right.

I just got it working this morning.

I appended this and both kernels were detected, and the initrd matched.

extra_kernel_version_strings linux,linux-lts
1 Like

Just for your info - this information is included in the wiki posts on rEFInd here on EndeavourOS forums. you can also ‘hide’ the ones you don’t want to see on a reversible basis anytime. I have (for instance) linux-zen, linux-lts and more all accessible on some of my builds…

1 Like

anything we should add to this?

Unless my memory has completely failed, anything not mentioned in part 1 is covered pretty well in part 2 (the 8-way, all DE’s of the time multi-boot example). I’ll go have a look at it again to make sure, though! :grin:

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.