I am attempting to directly boot the openSUSE kernels via rEFInd. I am using Tumbleweed with btrfs. The issue I am having is that rEFInd does not detect the symlink files associated with the kernels located in /usr/lib/modules. REFInd boots the grub efi file as intended, and it will also detect any kernel image I copy to the efi boot directory.
Is there any way I can workaround this issue without doing any manual editing or copying each time the kernel receives an update?
I have never used “refind”, so my advice might be bad.
As far as I know, “refind” requires that the kernel be in the EFI partition.
You could try mounting the EFI partition at “/boot” (instead of at “/boot/efi”). Kernel updates should then copy the kernel to “/boot”, and thus to the EFI partition. But if you try that, then you probably also need to reinstall grub or skip using grub.
@nrickert I don’t think you could get away with mounting ESP to /boot, because:
Pretend you are using RAID. 
Create a separate EXTx filesystem for mounting on /boot/. Then the actual kernel files and symlinks traditionally hosted there will be put there by package management.
I used rEFInd on a Mac for a year or so with two Leap installations, but found its inclusion in the system was unneeded complication. MacOS is in the Grub menu and MacOS boots when selected from there.
KaOS linux mounts it to “/boot” and uses grub for booting.
The scripts that create symlinks in “/boot” are likely to have fallbacks to copy the file if it cannot be symlinked.
Why? What problem are you trying to solve?
You can add rEFInd support to update-bootloader script which is called when kernel package is installed/removed. See /usr/lib/bootloader.
I’m aware some other distros do at least support it. I doubt TW as it currently exists would support it, which was one reason for “I don’t think”. soundprizm is new blood here, and I didn’t want him to expect too much. IMO, unless absolutely nothing else works, rEFInd is just in the way of understanding what’s happening, and keeping things moving along nicely. Like arvidjaar, I’d like to know why OP is using rEFInd. I don’t recall any of the reasons why people find they need or want it.
Thanks for all the replies!
Thank you for the reply!
It’s possible to include any directory by manually editing the refind.conf file. For example, if I include, /usr/lib/modules/6.1.3-1-default refind would detect any kernel image contained in that directory.
As far as I know, my EFI partition is mounted at /boot, and all openSUSE kernels updates are symlinks installed into /boot directory.
Thanks for the reply!
If I understand you correctly, if I use an EXT filesystem for /boot instead of btrfs, openSUSE’s package management will install the kernel images into /boot instead of symlinks to said images?
My main reason for using rEFInd is for the touch capability; which is lacking in all other bootloaders. It’s just a matter of uncommenting one line in refind.conf, and bam, touch works. It kind of defeats the purpose if I use one bootloader (rEFInd) to boot into another bootloader (grub) to boot the OS of choice.
Thank you for the reply!
As stated in my reply to mrmazda, my main issue would be with grub and its lack of touch support.
This looks promising and is something I had no idea about! Is there any documentation anywhere on adding support for rEFInd (or any other bootloader) to the script?
The closest is perl-bootloader/new_pbl.txt at master · openSUSE/perl-bootloader · GitHub
There are more possible actions than just install and config, so your best bet is to look at existing implementations.
BTW since recently update-bootloader supports systemd-boot which does copy kernel and initrd to ESP, so you may simply try setting loader to systemd-boot if that is enough (LOADER_TYPE in /etc/sysconfig/bootloader).
Awesome! Great info! Thank you very much!
Actually, rEFInd comes with EFI drivers for several filesystems including btrfs ( The rEFInd Boot Manager: Using EFI Drivers (rodsbooks.com)) and there are other independent projects, based on grub2 drivers. So I suspect something else is going on. My best guess is some confusion around whether links should be resolved relative to default subvolume or to the filesystem root. I would rather contact rEFInd developers, may be there is already an option to control it.
The point was/is a separate partition for the /boot/ filesystem, to which the package management system installs kernel images, and symlinks, just as it had in the past 3 or so decades. You can use any native filesystem for the purpose. Mine have no journals, as they don’t get written to terribly often, and are smallish, sized long ago when kernels and especially initrds were considerably smaller.
Note: I consider rEFInd to be beta-quality software! That said, rEFInd is a usable program in its current form on many systems. If you have problems, feel free to drop me a line.
You may tell them to fix the issue.
OK, I got curious, so …
/boot (even if they point into /boot itself). It may work if those links are explicitly listed in configuration file, not sure. This could be worked around by adding additional directory to scan, except each kernel directory under /usr/lib/modules must be listed, so rEFInd configuration still has to be updated for each kernel./boot and will be missing.I will be reaching out to the developer directly to inquire. I started a discussion on the rEFInd sourceforge discussion page last week with no response yet, so perhaps a direct email might better suited—especially with the feedback I received from you guys. 
I’ll report back if I hear anything.
I’ll just add my 2 cent opinion here and say that I agree with @mrmazda et al in saying that rEFInd adds a layer of complication, that historically was needed–in the time before linux had “EFI boot” capacity–then it was needed, now it is not.
I’m also vaguely recalling that rodbooks “stopped development” on the project??
Back in the day, if this is for a Mac, OSX had “Bootcamp” which was the way to set up the machine to install Windows AND keep all of the functions of the machine. I did that waay back when, but then I found that BC locked the drive, so I couldn’t add any more distro partitions . . . ??? I had to wipe the drive and start over.
These days, just using the “EFI” option from the linux iso provides the “direct way to boot the system” . . . and grub alone does an adequate job . . . .
I hope not! Last release was April 2022, and it looks like there’s been a consistent release yearly; however, I haven’t received a reply via email or the Sourceforge discussion just yet, so that may be the case.
Can anyone confirm?
I agree; however, it gets a little muddy when you throw in multiple OS’s, snapshots, and touch input into the mix. I can definitely get by with just using Grub and calling it a day (it’s what I currently do), but my goal is to create a polished OpenSUSE spin that works well on a 2-in-1… rEFInd seems the best option to do so.
So, I guess the first question I have is: what hardware are you running this on?
If it’s an x86-64-based Mac, I never really found much use for it. It gives you a nice, pretty startup menu, but Macs let you hold the ⌥ (or Option) key down on boot and then you can pick whatever device you want from there. Of course, I only ever at most had Mac OS X and one Linux distro installed, so perhaps if you had multiple Linux distros it might make it visually easier to distinguish between them.
From what I understand, and as pointed out on Rod Smith’s web page, there are a lot of regular PCs out there with fairly poor BIOSs and problematic implementations of uEFI, so as the saying goes, “Your mileage may vary” and then I guess rEFInd comes in handy.
This is not only a problem of rEFInd. Its a microOS readonly snapshot+seperate boot partition+kernelupdate problem.
I get a new kernel update/installl problem with grub2 as well.
On a seperate /boot ext2 partition, kernel and initrd etc are created as symlinks on the “next boot” BTRFS snapshot, probably because on the snapshot the /boot appears as on the same filesystem as /.snapshots/…/usr/lib/modules//
instead of a /boot partition mounted on the snapshot.
What I do to fix it is to copy the /boot files from the new snapshot created by transactional-update/tukit to the real /boot manually before reboot. And/or boot with kexec instead. But this means I have to turn off rebootmgr.service or boot from a emergency boot disk
Am I explaining it right? I hope the right person reads this.
The start a new topic for your problem. Nobody is going to read rEFInd topic for grub issues.
I think it’s “on topic” as far as issues that would drive someone to see rEFInd as an option, i.e., problems with grub2 . . . of which I can attest do exist and are prevalent, such that rEFInd might seem like a way out . . . . Personally I think it adds a layer of complication.
I don’t have any “touch” machines, so I can’t add anything into the discussion on that topic. But, most laptops have a “touch pad” so it seems like linux can handle that aspect of function within reason. I still get problems with my touchpad in my new linux laptop when I type . . . so I could see that maybe there could be room for improvement for a 2 in 1 . . . .
But, I have 8 distros running in my Mac and grub2 lists them and will boot them, up until a new kernel is added in one of them. Then I have to run “#update-bootloader” in the system that controls grub. Only one distro should have grub installed and os-prober set to find the other systems. There IS some maintenance required when running multi-boot; but that is far easier than getting rEFInd installed and running. Did not fact-check my suggestion that rEFInd was “out of development” . . . .