rEFInd autodetect and avoiding GRUB

Hi all,

I’ll skip the usual introduction for now (though EnOS was indeed the end of my distro-hopping) and get straight to the point; I’ve been tinkering with rEFInd for a few days now and am nearing the end of my tether.

After confirming that some specialised software (joystick firmware configurator, for those wondering) works in a virtualised environment, I recently retired my long-standing yet decreasingly-used Windows backup drive to free up space to house a replacement VM as well as some other experiments. I went to check that the Windows Boot Manager entry had disappeared from my rEFInd install, which had sat unused for months as I hadn’t needed to swap boot device, only to find there was no entry for rEFInd at all. A quick reinstall and run of refind-install fixed that, but only provided an option to boot via GRUB, the option I had already been using directly from the motherboard’s firmware.

I’ve been wanting to move away from GRUB for a while (years of distro-hopping has given me plenty of time to devise a slick rEFInd theme) so I set to work on making an option to boot EnOS directly. No matter what I tried, though, stanzas using /boot/vmlinuz-linux and /boot/initramfs-linux.img never worked, giving a ‘not found’ error. As a troubleshooting measure, I tried copying the files (and microcode) to /boot/efi/EFI/EndeavourOS, and sure enough stanzas using this path work fine. What I really wanted though was to have rEFInd’s autodetect abilities generate an entry with the kernel and ramdisk in their default place, else I’d have to recopy them everytime they get updated - failed boots after an update yesterday was proof enough of that. TL;DR: Direct boot with rEFInd works manually, but I’m fairly sure there’s an easier and more official way to go about it.

My only theory was that rEFInd can’t read any higher than it’s own location, so /boot is inaccessible. Examples on the web all suggest this isn’t the case though, and given refind_linux.conf lives at this level, I’m fairly sure that has nothing to do with it. I ask those more versed in EFI dabbling than I for help in getting the easy way working. A copy of my attempted fixes in refind_linux.conf is available here (partition data available if needed) and refind.conf is here. I appreciate any help, though I understand the issue is neither important nor urgent - I can still use GRUB, after all.

Troubleshooting steps I’ve tried:

Replicating the refind_linux.conf setup of the Arch Wiki.
Changing loader and initrd paths from /boot/… to just /
Disabling the dont_scan_dirs setting in refind.conf (used to hide the GRUB entry.)
Installing another copy of EnOS to a different system disk (the new GRUB entry was detected, but there was no option for stub booting.)
Resetting rEFInd by uninstalling completely and reinstalling.

I’ve now got a completely stock install of rEFInd, which detects grubx64.efi in /boot/efi/EFI/EndeavourOS as well as my manually copied vmlinuz-linux, initramfs-linux.img and amd-ucode.img, the latter three are currently unbootable pending a recopy from /boot/. Still no further towards having rEFInd autodetect the versions in the ‘normal’ location of /boot/, though.

In your manual stanzas, are you setting the volume to the partition containing /boot? If not, it will only look in the ESP.

I hadn’t been, but adding it as described by Rod himself hasn’t changed anything; selecting the entry just cuts to a black screen then returns to the selection menu. Just for sanity, Dolphin says /boot is mounted from /dev/nvme0n1p2, the PARTUUID of which has been used below. Now working with this stanza:

menuentry "EndeavourOS, TEST" {
   icon     EFI/refind/themes/endeavouros-theme/icons/os_endeavouros.png
   volume   C4683945-8149-6F41-9CB2-BF179DF88B06
   loader   /boot/vmlinuz-linux
   initrd   /boot/initramfs-linux.img
   options  "root=PARTUUID=c4683945-8149-6f41-9cb2-bf179df88b06 rw add_efi_memmap initrd=boot\amd-ucode.img resume=PARTUUID=cfb748f4-d5c9-7b4c-8622-2e40c3ef7eec graphics=on"
   submenuentry "Boot using fallback initramfs" {
       initrd /boot/initramfs-linux-fallback.img
   }
   submenuentry "Boot to terminal" {
       add_options "systemd.unit=multi-user.target"
   }
}

Can you share lsblk -o name,type,fstype,size,mountpoint,uuid,partuuid

Sure thing:

[bradleyr@Maelstrom ~]$ lsblk -o name,type,fstype,size,mountpoint,uuid,partuuid
NAME        TYPE FSTYPE     SIZE MOUNTPOINT                                   UUID                                 PARTUUID
loop0       loop squashfs   5.8M /var/lib/snapd/snap/ascii-image-converter/31                                      
loop1       loop squashfs   5.8M /var/lib/snapd/snap/ascii-image-converter/30                                      
loop2       loop squashfs  32.3M /var/lib/snapd/snap/snapd/12704                                                   
loop3       loop squashfs  55.4M /var/lib/snapd/snap/core18/2074                                                   
loop4       loop squashfs  55.4M /var/lib/snapd/snap/core18/2128                                                   
loop5       loop squashfs  65.1M /var/lib/snapd/snap/gtk-common-themes/1515                                        
loop6       loop squashfs  32.3M /var/lib/snapd/snap/snapd/12883                                                   
loop7       loop squashfs 164.8M /var/lib/snapd/snap/gnome-3-28-1804/161                                           
loop8       loop squashfs  70.8M /var/lib/snapd/snap/teams-for-linux/182                                           
sda         disk          894.3G                                                                                   
└─sda1      part ext4     894.2G /mnt/Tempest SSD                             382b0b2d-fc00-4f73-9885-5af1c0706742 153d8144-ba5c-ae48-9235-7965d3c51a0f
sdb         disk          111.8G                                                                                   
└─sdb1      part ext4     111.8G /mnt/Typhoon SSD                             beeff2cc-a260-4e29-bd83-1d098d834598 a2f300bf-fadc-7d44-b38a-94976b9df640
sdc         disk              0B                                                                                   
nvme0n1     disk          476.9G                                                                                   
├─nvme0n1p1 part vfat       300M /boot/efi                                    C269-60E7                            b899cf64-e163-2a4d-a2a7-d2c8dc3ef791
├─nvme0n1p2 part ext4     467.8G /                                            1bcc7401-5e26-46f0-b4d1-936f08e119bd c4683945-8149-6f41-9cb2-bf179df88b06
└─nvme0n1p3 part swap       8.8G [SWAP]                                       d826956f-de76-4bc2-b4f1-b4ecfd4119b1 cfb748f4-d5c9-7b4c-8622-2e40c3ef7eec