How do I get rEFInd to provide boot up choices for each of the various kernels I’ve got on my computer (e.g., latest zen, LTS, fallbacks, etc.)?
I’ve tried to make sense of rEFInds (extensive) documentation and have searched here for on-point Q&A but so far come up dry…
This must be an easy one for those in the know.
Background: I typically update to the latest kernel (through yay) weekly or so and I can confirm that various kernels are being updated as seen in my /boot directory. But the only rEFInd choice I’m given is the very most recent zen release.
This is not really a concern as long as the next latest kernel update doesn’t cause any glitches … but using grub on other household computers I can always select which of several kernels to use. For some reason, this is not an option that I’m seeing on my rEFInd-starting machine (the others do not have rEFInd installed).
There must be a simple config fix to achieve this for those who’ve been around this block before. Any guidance would be appreciated!
I followed the specific guidance found in the link you provided (i.e.,un-commenting the “fold” feature and ensuring it is set to false), but upon rebooting the only choice that appeared in the EndeavourOS category was the same a single option and even delving into the sub-choices within EndeavourOS (which presumably would have already been “un-folded” and appearing on the top level) was this …
If you hit F2 or Insert, you’ll see options for all the other kernels. (If refind_linux.conf has more than one line, each kernel will have multiple entries, one for each line in refind_linux.conf.)
I know this doesn’t show them by default, but I’d like to know if pressing it shows them all.
PS: In Grub, the kernel choices are also “folded”, so I’d think this is the default behaviour even in rEFInd where you’d need to do some extra step to see them. Is it that your Grub (when you used to use it) showed all the kernels without needing to press anything?
@anon93652015 Yes I did hit F2, which (as I just reconfirmed) is how I get that first screen image shown above).
What’s intriguing now is that I cannot find a refind_linux.conf file. All I can locate that’s similar is the refind.conf file (which I edited per above).
What also seems odd is that I’ve got an EFI (uppercase) directory beneath an efi (lowercase)… I’m guessing this was a faulty installation of some kind on my part.
After installing rEFInd’s files to the ESP, verify that rEFInd has created refind_linux.conf containing kernel parameters in the same directory as your kernel.
It seems it should be in the same directory as your kernel.
It may be necessary to set the extra_kernel_version_strings option in refind.conf with a comma-delimited list of strings for the different kernels you want detected.
The more complex a particular setup is, the more little gotchas and extra steps are needed to preserve the “easy, automatic setup” method for generating a rEFInd boot option…until finally, it’s not that easy or automatic anymore.
There is kind of a learning curve for setting up a manual boot stanza, but once you get the hang of it I find it to be more extensible and reliable than the automatic method. You have control over exactly how the menu and submenues will be set up, with alternate kernels and images or even another bootloader if you want.
It is written with Garuda Linux in mind so root is in a subvolume named “@”. If you are not using Btrfs with subvolumes you would just use “/” like normal.
Uncommented only these lines in /efi/EFI/refind/refind.conf
textonly
textmode 2
fold_linux_kernels false
During boot a more informative menu shows up and selecting line EFI\systemd\systemd-bootx64.efi from EFI
you can select kernels.
If ‘GRUB-bed’ kernels do not show up in primary menu uncomment and extend line #extra_kernel_version_strings linux-lts,linux,linux-zen,linux-fallback
The graphical rEFInd is good for hiding items after Del, theming is a waste of time for me.
@eso Many thanks for further guidance. I’ve followed it all and - although I’m still not getting those additional kernels to show up anywhere in the rEFInd screen(s) when booting up - you’ve helped me narrow things down a bit further…
I don’t really have an issue with the text vs graphics so, having tried both, I switched back to commenting out the textonly and textmode2 lines.
My fold_linux_kernels false line was already un-commented so that wasn’t an issue.
I also explicitly added all of the linux kernels I’ve got to that extra_kernel_version_strings... line which has also been un-commented all along. (Most had already been listed)
So this leaves me wondering whether rEFInd simply cannot find those additional kernels given where they are located vs where the refind.conf is looking for them.
I don’t want to simply move those kernel files to another directory since where they now reside is where future system updates will likely place them when updating my system.
Instead, I’ve likely got to devote time to figuring out how to get rEFInd to look in the right places for those kernels so they can also be listed as boot-up options.
Well, I think I’m getting warmer Thanks for your reply above.
UPDATE: Noting that all those other kernels are residing directly in my /boot directory, I just added also_scan_dirs boot to the refind.conf file and FINALLY… a whole bunch of additional boot-up choices are found after hitting F2. This is meaningful progress!
Unfortunately they’re offered in cryptic hexadecimal labels (likely, partition IDs?) so I’ve got to do some work to get them to be more human-recognizable.
Yes, I was going to say you probably also need to set also_scan_dirs.
This is what I mean: there can be so much tweaking and prodding involved with the “automatic” method that it can actually be easier and faster to just write a manual boot stanza.
The boot entries can also be named whatever you want in a manual stanza; I’m not sure how much flexibility you will have with what they are named using the other method.
Managed to get access to those various other kernels using the also_scan_dirs boot line, but none of those other kernels will load as I confront the grub-related “shim_lock_enabled” error. To my knowledge I do not have any shim_lock enabled … so it’s off to find a solution to my next obstacle.
Ha! I love change! But perhaps I should only update every 8 years or so.
