Updated refind breaks boot on my system

[ddt3]

Hi all,

Posting this in case anyone else is hitting the same issue and to leave a record for the maintainers.

Symptom

After a recent system update that included a rEFInd package update to 0.14.2-2, my machine no longer boots normally. The rEFInd screen appears but stays empty — no boot entries are displayed, and the menu never finishes initializing. The timeout never fires either, so it does not fall through to a default boot. Basically means I can no longer boot my system.

My setup

• Manjaro KDE
• rEFInd as bootloader, installed to the ESP at /boot/efi/EFI/refind/
• Root filesystem on btrfs with subvolumes @, @home, @swap
• Two NVMe drives:
  • 2 TB Samsung 990 EVO
    • ESP labeled EVO990p1
    • btrfs root labeled EVO990p2
@, @home, @swap
  • 1 TB Samsung 970 EVO Plus
    • btrfs, label EVO970PLUSp1
@games, @images
• Multiple kernels installed (5.15, 6.12, 6.18) with Intel microcode
• refind-btrfs-snapshots for snapshot booting
• The btrfs_x64.efi driver is installed in EFI/refind/drivers_x64/ on the ESP (the one from the current package)
• Firmware: American Megatrends 5.17, UEFI mode, Secure Boot off

What happened, step by step

1. System was working perfectly with the previous refind package version. rEFInd was displaying all entries (auto-detected kernels, snapshot submenu, manual stanzas) and boot was reliable.
2. I ran a system update that included a refind package update to 0.14.2-2.
3. On the next reboot, the rEFInd screen came up empty as described above. I use a background from a theme and only that background is showing. Even manual stanzas are not showing.
4. I booted from a live USB and replaced only the file EFI/refind/refind_x64.efi on the ESP with a copy taken from a btrfs snapshot dated April 30 (i.e. the version from before the update). I did not touch btrfs_x64.efi, the rEFInd config, the themes, the drivers directory, the kernel images, the initramfs, or anything else.
5. After that single file replacement, rEFInd booted normally again, displayed all entries, and the system reached the desktop without any further intervention.
6. To confirm, I ran refind-install (that installs the current version of refind to the ESP). The empty-boot-screen problem returned on the next reboot.
7. Replacing refind_x64.efi once more with the older copy fixed it again.

The behaviour toggles cleanly with that one file. Replacing refind_x64.efi is the only change between the working and non-working states in both directions.

Log files

Both binaries report themselves as rEFInd 0.14.2 built with GNU-EFI in the log header (the upstream version string is the same — only the package revision differs), so to compare them I set log_level 1 in refind.conf and captured refind.log from the ESP under each binary. The hardware, firmware, ESP layout, refind configuration, themes, drivers, and btrfs_x64.efi are all identical between the two captures — only refind_x64.efi differs. (and yes my refind.conf needs claning up)

• refind_ok.log — captured with the older refind_x64.efi (April 30 snapshot copy)
• refind_nok.log — captured with the new refind_x64.efi from the 0.14.2-2 package

Looking at the log files it appears in the NOK situation none of the BTRFS volumes are found:

==========Scanning for volumes==========
09:20:39 - Could not locate device path for volume
09:20:39 - Identified volume ' whole disk volume', of type whole disk
09:20:39 - Could not locate device path for volume
09:20:39 - Identified volume 'Ventoy', of type
09:20:39 - Could not locate device path for volume
09:20:39 - Identified volume 'VTOYEFI', of type FAT
09:20:39 - Identified volume ' whole disk volume', of type whole disk
09:20:39 - Identified volume 'EVO990p1', of type FAT
09:20:39 - Identified volume ' Btrfs volume', of type Btrfs
09:20:39 - Identified volume ' whole disk volume', of type whole disk
09:20:39 - Identified volume ' Btrfs volume', of type Btrfs
09:20:39 - Identified 8 volumes

The OK version of the log:

==========Scanning for volumes==========
09:14:59 - Could not locate device path for volume
09:14:59 - Identified volume ' whole disk volume', of type whole disk
09:14:59 - Could not locate device path for volume
09:14:59 - Identified volume 'Ventoy', of type
09:14:59 - Could not locate device path for volume
09:14:59 - Identified volume 'VTOYEFI', of type FAT
09:14:59 - Identified volume ' whole disk volume', of type whole disk
09:14:59 - Identified volume 'EVO990p1', of type FAT
09:14:59 - Identified volume 'EVO990p2', of type Btrfs
09:14:59 - Identified volume ' whole disk volume', of type whole disk
09:14:59 - Identified volume 'EVO970PLUSp1', of type Btrfs
09:14:59 - Identified 8 volumes

Both files added below.

Help

I need to keep the older refind_x64.efi in place on the ESP and avoid running refind-install (or anything else that would write /usr/share/refind/refind_x64.efi to the ESP).

• Has anyone else with a btrfs setup run into this on the latest update?
• Has anyone be able to solve it using the current version of refind?

refind.ok.log

==========System information==========
09:14:58 - rEFInd 0.14.2 built with GNU-EFI
09:14:58 - rEFInd boot partition GUID: 7FB93800-CE49-452D-8EB5-B871FC94A4D7
09:14:58 - Platform: x86-64/X64/AMD64 (64-bit)
09:14:58 - Log level is 1
09:14:58 - Menu timeout is 10
09:14:58 - Firmware: American Megatrends 5.17
09:14:58 - EFI Revision 2.70
09:14:58 - Secure Boot inactive
09:14:58 - Shim is not available
09:14:58 - CSM type: UEFI
09:14:58 - EFI non-volatile storage:
09:14:58 -    Total storage: 196608
09:14:58 -    Remaining available: 115208
09:14:58 -    Maximum variable size: 65509
09:14:58 - System does support text mode
09:14:58 - System does not support UGA Draw graphics mode
09:14:58 - System does support GOP graphics mode
09:14:58 - Setting up Secure Boot (if applicable)

==========Loading drivers==========
09:14:58 - Starting btrfs_x64.efi
09:14:58 - Using load options ''
09:14:58 - Note: btrfs_x64.efi is a driver
09:14:58 - 'EFI\REFIND\drivers_x64\btrfs_x64.efi' is a valid loader file
09:14:58 - Launching 'btrfs_x64.efi'
09:14:58 - Program has returned 0

----------Next loader----------
09:14:58 - Starting iso9660_x64.efi
09:14:58 - Using load options ''
09:14:58 - Note: iso9660_x64.efi is a driver
09:14:58 - 'EFI\REFIND\drivers_x64\iso9660_x64.efi' is a valid loader file
09:14:58 - Launching 'iso9660_x64.efi'
09:14:58 - Program has returned 0

----------Next loader----------

==========Scanning for volumes==========
09:14:59 - Could not locate device path for volume
09:14:59 - Identified volume ' whole disk volume', of type whole disk
09:14:59 - Could not locate device path for volume
09:14:59 - Identified volume 'Ventoy', of type
09:14:59 - Could not locate device path for volume
09:14:59 - Identified volume 'VTOYEFI', of type FAT
09:14:59 - Identified volume ' whole disk volume', of type whole disk
09:14:59 - Identified volume 'EVO990p1', of type FAT
09:14:59 - Identified volume 'EVO990p2', of type Btrfs
09:14:59 - Identified volume ' whole disk volume', of type whole disk
09:14:59 - Identified volume 'EVO970PLUSp1', of type Btrfs
09:14:59 - Identified 8 volumes

==========Initializing basic features==========
09:14:59 - Adjusting default_selection with PreviousBoot values
09:14:59 - Trying to create a 'vars' directory in which to hold variables
09:14:59 - Entering InitScreen()
09:14:59 - Setting watchdog timer
09:14:59 - Setting screen resolution and mode
09:14:59 - Setting volume icons....

==========Scanning for boot loaders==========

----------Scanning for internal EFI-mode boot loaders----------
09:14:59 - Called ScanEfiFiles() on an invalid volume
09:14:59 - Scanning EFI files on 
09:14:59 - 'EFI\hdoktest\test.efi' is a valid loader file
09:14:59 - 'EFI\hdoktest\example.efi' is a valid loader file
09:14:59 - 'EFI\hdoktest\ipxe-usb.efi' is a valid loader file
09:14:59 - 'EFI\hdoktest\ipxe-usb-local.efi' is a valid loader file
09:14:59 - Adding loader entry for 'EFI\hdoktest\ipxe-usb-local.efi'
09:14:59 - Adding loader entry for 'EFI\hdoktest\ipxe-usb.efi'
09:14:59 - Adding loader entry for 'EFI\hdoktest\example.efi'
09:15:00 - Adding loader entry for 'EFI\hdoktest\test.efi'
09:15:00 - 'EFI\netboot.xyz\netboot.xyz.efi' is a valid loader file
09:15:00 - Adding loader entry for 'EFI\netboot.xyz\netboot.xyz.efi'
09:15:00 - 'EFI\memtest\shellx64.efi' is a valid loader file
09:15:00 - Adding loader entry for 'EFI\memtest\shellx64.efi'
09:15:00 - Adding loader entry for 'Fallback boot loader'
09:15:00 - Scanning EFI files on 
09:15:00 - '@\boot\vmlinuz-6.18-x86_64' is a valid loader file
09:15:01 - '@\boot\vmlinuz-5.15-x86_64' is a valid loader file
09:15:01 - '@\boot\vmlinuz-6.12-x86_64' is a valid loader file
09:15:02 - Adding loader entry for '@\boot\vmlinuz-6.18-x86_64'
09:15:02 - Searching for an initrd to match '@\boot\vmlinuz-6.18-x86_64' on 'EVO990p2'
09:15:02 - Located initrd is '@\boot\initramfs-6.18-x86_64.img'
09:15:02 - Searching for an initrd to match '\@\boot\vmlinuz-6.18-x86_64' on 'EVO990p2'
09:15:03 - Located initrd is '\@\boot\initramfs-6.18-x86_64.img'
09:15:03 - Searching for an initrd to match '@\boot\vmlinuz-6.12-x86_64' on 'EVO990p2'
09:15:04 - Located initrd is '@\boot\initramfs-6.12-x86_64.img'
09:15:04 - Searching for an initrd to match '@\boot\vmlinuz-5.15-x86_64' on 'EVO990p2'
09:15:04 - Located initrd is '@\boot\initramfs-5.15-x86_64.img'
09:15:05 - '@\boot\vmlinuz-6.18-x86_64' is a valid loader file
09:15:05 - '@\boot\vmlinuz-5.15-x86_64' is a valid loader file
09:15:05 - '@\boot\vmlinuz-6.12-x86_64' is a valid loader file
09:15:06 - Adding loader entry for '@\boot\vmlinuz-6.18-x86_64'
09:15:06 - Searching for an initrd to match '@\boot\vmlinuz-6.18-x86_64' on 'EVO990p2'
09:15:06 - Located initrd is '@\boot\initramfs-6.18-x86_64.img'
09:15:06 - Searching for an initrd to match '\@\boot\vmlinuz-6.18-x86_64' on 'EVO990p2'
09:15:07 - Located initrd is '\@\boot\initramfs-6.18-x86_64.img'
09:15:07 - Searching for an initrd to match '@\boot\vmlinuz-6.12-x86_64' on 'EVO990p2'
09:15:08 - Located initrd is '@\boot\initramfs-6.12-x86_64.img'
09:15:08 - Searching for an initrd to match '@\boot\vmlinuz-5.15-x86_64' on 'EVO990p2'
09:15:08 - Located initrd is '@\boot\initramfs-5.15-x86_64.img'
09:15:08 - Called ScanEfiFiles() on an invalid volume
09:15:08 - Scanning EFI files on 

----------Scanning for external EFI-mode boot loaders----------
09:15:08 - Called ScanEfiFiles() on an invalid volume
09:15:08 - Scanning EFI files on Ventoy
09:15:08 - Scanning EFI files on VTOYEFI
09:15:08 - 'EFI\BOOT\grubia32.efi' is an invalid loader file
09:15:08 - 'EFI\BOOT\BOOTAA64.EFI' is an invalid loader file
09:15:08 - 'EFI\BOOT\BOOTMIPS.EFI' is an invalid loader file
09:15:08 - 'EFI\BOOT\mmia32.efi' is an invalid loader file
09:15:08 - 'EFI\BOOT\BOOTIA32.EFI' is an invalid loader file
09:15:08 - 'EFI\BOOT\MokManager.efi' is a valid loader file
09:15:09 - 'EFI\BOOT\grubia32_real.efi' is an invalid loader file
09:15:09 - Adding loader entry for 'EFI\BOOT\MokManager.efi'
09:15:09 - Adding loader entry for 'Fallback boot loader'

----------Scanning for user-configured boot stanzas----------
09:15:09 - Adding manual loader for 'bzImage-3.3.0-rc7'
09:15:09 - Searching for an initrd to match 'bzImage-3.3.0-rc7' on 'EVO990p1'
09:15:09 - Located initrd is '(null)'
09:15:09 - Entry is disabled
09:15:09 - Adding manual loader for '\boot\vmlinuz-linux'
09:15:09 - Searching for an initrd to match '\boot\vmlinuz-linux' on 'EVO990p1'
09:15:09 - Located initrd is '(null)'
09:15:09 - Entry is disabled
09:15:09 - Adding manual loader for '\EFI\ubuntu\grubx64.efi'
09:15:09 - Entry is disabled
09:15:09 - Adding manual loader for '\EFI\elilo\elilo.efi'
09:15:09 - Entry is disabled
09:15:09 - Adding manual loader for '\EFI\Microsoft\Boot\bootmgfw.efi'
09:15:09 - Entry is disabled
09:15:09 - Adding manual loader for '\EFI\tools\shell.efi'
09:15:09 - Entry is disabled
09:15:09 - Adding manual loader for '\System\Library\CoreServices\boot.efi'
09:15:09 - Entry is disabled
09:15:09 - Entry is disabled
09:15:09 - Adding manual loader for '\EFI\netboot.xyz\netboot.xyz.efi'
09:15:09 - Adding manual loader for '\EFI\hdoktest\example.efi'
09:15:09 - Entry is disabled
09:15:09 - Adding manual loader for '\EFI\hdoktest\ipxe-usb.efi'
09:15:09 - Entry is disabled
09:15:09 - Adding manual loader for '\EFI\hdoktest\ipxe-usb-local.efi'
09:15:09 - Adding manual loader for '\@\boot\vmlinuz-6.12-x86_64'
09:15:09 - Searching for an initrd to match '\@\boot\vmlinuz-6.12-x86_64' on 'EVO990p1'
09:15:09 - Located initrd is '(null)'

----------Scanning for user-configured boot stanzas----------

==========Scanning for tools==========
09:15:09 - Scanning for tools 'memtest86.efi,memtest86_x64.efi,memtest86x64.efi,memtest86+x64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,@\boot,EFI\BOOT,EFI\REFIND'
09:15:09 - Scanning for tools 'ipxe.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,@\boot,EFI\BOOT,EFI\REFIND'
09:15:09 - 'EFI\tools\ipxe.efi' is a valid loader file
09:15:09 - Adding tag for 'ipxe.efi' on 'EVO990p1'
09:15:09 - Scanning for tools 'fwupx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,@\boot,EFI\BOOT,EFI\REFIND'

==========Entering main loop==========

==========Displaying About/Info screen==========

==========Launching 'Boot @\boot\vmlinuz-6.18-x86_64 from EVO990p2 '==========
09:16:09 - Starting vmlinuz-6.18-x86_64
09:16:09 - Using load options 'root=LABEL=EVO990p2 rw rootflags=subvol=@  quiet apparmor=1 security=apparmor udev.log_priority=3 initrd=\@\boot\intel-ucode.img initrd=\@\boot\initramfs-6.18-x86_64.img'
09:16:09 - '\@\boot\vmlinuz-6.18-x86_64' is a valid loader file
09:16:09 - Launching 'vmlinuz-6.18-x86_64'

refind.nok.log

==========System information==========
09:20:32 - rEFInd 0.14.2 built with GNU-EFI
09:20:32 - rEFInd boot partition GUID: 7FB93800-CE49-452D-8EB5-B871FC94A4D7
09:20:32 - Platform: x86-64/X64/AMD64 (64-bit)
09:20:32 - Log level is 1
09:20:32 - Menu timeout is 10
09:20:32 - Firmware: American Megatrends 5.17
09:20:32 - EFI Revision 2.70
09:20:32 - Secure Boot inactive
09:20:32 - Shim is not available
09:20:32 - CSM type: UEFI
09:20:32 - EFI non-volatile storage:
09:20:32 -    Total storage: 196608
09:20:32 -    Remaining available: 115208
09:20:32 -    Maximum variable size: 65509
09:20:32 - System does support text mode
09:20:32 - System does not support UGA Draw graphics mode
09:20:32 - System does support GOP graphics mode
09:20:32 - Setting up Secure Boot (if applicable)

==========Loading drivers==========
09:20:32 - Starting btrfs_x64.efi
09:20:32 - Using load options ''
09:20:32 - Note: btrfs_x64.efi is a driver
09:20:32 - 'EFI\REFIND\drivers_x64\btrfs_x64.efi' is a valid loader file
09:20:32 - Launching 'btrfs_x64.efi'
09:20:32 - Program has returned 0

----------Next loader----------
09:20:32 - Starting iso9660_x64.efi
09:20:32 - Using load options ''
09:20:32 - Note: iso9660_x64.efi is a driver
09:20:32 - 'EFI\REFIND\drivers_x64\iso9660_x64.efi' is a valid loader file
09:20:32 - Launching 'iso9660_x64.efi'
09:20:32 - Program has returned 0

----------Next loader----------

==========Scanning for volumes==========
09:20:39 - Could not locate device path for volume
09:20:39 - Identified volume ' whole disk volume', of type whole disk
09:20:39 - Could not locate device path for volume
09:20:39 - Identified volume 'Ventoy', of type
09:20:39 - Could not locate device path for volume
09:20:39 - Identified volume 'VTOYEFI', of type FAT
09:20:39 - Identified volume ' whole disk volume', of type whole disk
09:20:39 - Identified volume 'EVO990p1', of type FAT
09:20:39 - Identified volume ' Btrfs volume', of type Btrfs
09:20:39 - Identified volume ' whole disk volume', of type whole disk
09:20:39 - Identified volume ' Btrfs volume', of type Btrfs
09:20:39 - Identified 8 volumes

==========Initializing basic features==========
09:20:39 - Adjusting default_selection with PreviousBoot values
09:20:39 - Trying to create a 'vars' directory in which to hold variables
09:20:39 - Entering InitScreen()
09:20:39 - Setting watchdog timer
09:20:39 - Setting screen resolution and mode
09:20:40 - Setting volume icons....

==========Scanning for boot loaders==========

----------Scanning for internal EFI-mode boot loaders----------
09:20:40 - Called ScanEfiFiles() on an invalid volume
09:20:40 - Scanning EFI files on 
09:20:40 - 'EFI\hdoktest\test.efi' is a valid loader file
09:20:40 - 'EFI\hdoktest\example.efi' is a valid loader file
09:20:40 - 'EFI\hdoktest\ipxe-usb.efi' is a valid loader file
09:20:40 - 'EFI\hdoktest\ipxe-usb-local.efi' is a valid loader file
09:20:40 - Adding loader entry for 'EFI\hdoktest\ipxe-usb-local.efi'
09:20:40 - Adding loader entry for 'EFI\hdoktest\ipxe-usb.efi'
09:20:40 - Adding loader entry for 'EFI\hdoktest\example.efi'
09:20:40 - Adding loader entry for 'EFI\hdoktest\test.efi'
09:20:40 - 'EFI\netboot.xyz\netboot.xyz.efi' is a valid loader file
09:20:40 - Adding loader entry for 'EFI\netboot.xyz\netboot.xyz.efi'
09:20:40 - 'EFI\memtest\shellx64.efi' is a valid loader file
09:20:40 - Adding loader entry for 'EFI\memtest\shellx64.efi'
09:20:40 - Adding loader entry for 'Fallback boot loader'
09:20:40 - Called ScanEfiFiles() on an invalid volume
09:20:40 - Called ScanEfiFiles() on an invalid volume
09:20:40 - Called ScanEfiFiles() on an invalid volume

----------Scanning for external EFI-mode boot loaders----------
09:20:40 - Called ScanEfiFiles() on an invalid volume
09:20:40 - Scanning EFI files on Ventoy
09:20:40 - Scanning EFI files on VTOYEFI
09:20:40 - 'EFI\BOOT\grubia32.efi' is an invalid loader file
09:20:40 - 'EFI\BOOT\BOOTAA64.EFI' is an invalid loader file
09:20:40 - 'EFI\BOOT\BOOTMIPS.EFI' is an invalid loader file
09:20:40 - 'EFI\BOOT\mmia32.efi' is an invalid loader file
09:20:40 - 'EFI\BOOT\BOOTIA32.EFI' is an invalid loader file
09:20:40 - 'EFI\BOOT\MokManager.efi' is a valid loader file
09:20:40 - 'EFI\BOOT\grubia32_real.efi' is an invalid loader file
09:20:40 - Adding loader entry for 'EFI\BOOT\MokManager.efi'
09:20:40 - Adding loader entry for 'Fallback boot loader'

----------Scanning for user-configured boot stanzas----------
09:20:40 - Adding manual loader for 'bzImage-3.3.0-rc7'
09:20:40 - Searching for an initrd to match 'bzImage-3.3.0-rc7' on 'EVO990p1'
09:20:40 - Located initrd is '(null)'
09:20:40 - Entry is disabled
09:20:40 - Adding manual loader for '\boot\vmlinuz-linux'
09:20:40 - Searching for an initrd to match '\boot\vmlinuz-linux' on 'EVO990p1'
09:20:40 - Located initrd is '(null)'
09:20:40 - Entry is disabled
09:20:40 - Adding manual loader for '\EFI\ubuntu\grubx64.efi'
09:20:40 - Entry is disabled
09:20:40 - Adding manual loader for '\EFI\elilo\elilo.efi'
09:20:40 - Entry is disabled
09:20:40 - Adding manual loader for '\EFI\Microsoft\Boot\bootmgfw.efi'
09:20:40 - Entry is disabled
09:20:40 - Adding manual loader for '\EFI\tools\shell.efi'
09:20:40 - Entry is disabled
09:20:40 - Adding manual loader for '\System\Library\CoreServices\boot.efi'
09:20:40 - Entry is disabled
09:20:40 - Entry is disabled
09:20:40 - Adding manual loader for '\EFI\netboot.xyz\netboot.xyz.efi'
09:20:40 - Adding manual loader for '\EFI\hdoktest\example.efi'
09:20:40 - Entry is disabled
09:20:40 - Adding manual loader for '\EFI\hdoktest\ipxe-usb.efi'
09:20:41 - Entry is disabled
09:20:41 - Adding manual loader for '\EFI\hdoktest\ipxe-usb-local.efi'
09:20:41 - Adding manual loader for '\@\boot\vmlinuz-6.12-x86_64'
09:20:41 - Searching for an initrd to match '\@\boot\vmlinuz-6.12-x86_64' on 'EVO990p1'
09:20:41 - Located initrd is '(null)'

----------Scanning for user-configured boot stanzas----------

==========Scanning for tools==========
09:20:41 - Scanning for tools 'memtest86.efi,memtest86_x64.efi,memtest86x64.efi,memtest86+x64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:41 - Scanning for tools 'ipxe.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:41 - 'EFI\tools\ipxe.efi' is a valid loader file
09:20:41 - Adding tag for 'ipxe.efi' on 'EVO990p1'
09:20:42 - Scanning for tools 'gptsync.efi,gptsync_x64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:42 - Scanning for tools 'gptsync.efi,gptsync_x64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:42 - Scanning for tools 'fwupx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:42 - Scanning for tools 'gptsync.efi,gptsync_x64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:42 - Scanning for tools 'fwupx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:42 - Scanning for tools 'fwupx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:42 - Scanning for tools 'gptsync.efi,gptsync_x64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:42 - Scanning for tools 'gptsync.efi,gptsync_x64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:42 - Scanning for tools 'shell.efi,shellx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:42 - 'EFI\memtest\shellx64.efi' is a valid loader file
09:20:42 - Adding tag for 'shellx64.efi' on 'EVO990p1'
09:20:42 - Finding boot order entries
09:20:42 - Scanning for tools 'shell.efi,shellx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:42 - 'EFI\memtest\shellx64.efi' is a valid loader file
09:20:42 - Adding tag for 'shellx64.efi' on 'EVO990p1'
09:20:42 - Finding boot order entries
09:20:42 - Scanning for tools 'shell.efi,shellx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:42 - 'EFI\memtest\shellx64.efi' is a valid loader file
09:20:42 - Adding tag for 'shellx64.efi' on 'EVO990p1'
09:20:42 - Finding boot order entries
09:20:42 - Scanning for tools 'shell.efi,shellx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:42 - 'EFI\memtest\shellx64.efi' is a valid loader file
09:20:42 - Adding tag for 'shellx64.efi' on 'EVO990p1'
09:20:42 - Finding boot order entries
09:20:42 - Scanning for tools 'shell.efi,shellx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:42 - 'EFI\memtest\shellx64.efi' is a valid loader file
09:20:42 - Adding tag for 'shellx64.efi' on 'EVO990p1'
09:20:42 - Finding boot order entries
09:20:43 - Scanning for tools 'shell.efi,shellx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:43 - 'EFI\memtest\shellx64.efi' is a valid loader file
09:20:43 - Adding tag for 'shellx64.efi' on 'EVO990p1'
09:20:43 - Finding boot order entries
09:20:43 - Scanning for tools 'shell.efi,shellx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:43 - 'EFI\memtest\shellx64.efi' is a valid loader file
09:20:43 - Adding tag for 'shellx64.efi' on 'EVO990p1'
09:20:43 - Finding boot order entries
09:20:43 - Scanning for tools 'shell.efi,shellx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:43 - 'EFI\memtest\shellx64.efi' is a valid loader file
09:20:43 - Adding tag for 'shellx64.efi' on 'EVO990p1'
09:20:43 - Finding boot order entries
09:20:43 - Scanning for tools 'shell.efi,shellx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:43 - 'EFI\memtest\shellx64.efi' is a valid loader file
09:20:43 - Adding tag for 'shellx64.efi' on 'EVO990p1'
09:20:43 - Finding boot order entries
09:20:43 - Scanning for tools 'shell.efi,shellx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:43 - 'EFI\memtest\shellx64.efi' is a valid loader file
09:20:43 - Adding tag for 'shellx64.efi' on 'EVO990p1'
09:20:43 - Finding boot order entries
09:20:43 - Scanning for tools 'shell.efi,shellx64.efi' in 'EFI\tools,EFI\hdoktest,EFI\netboot.xyz,EFI\memtest,EFI\BOOT,EFI\REFIND'
09:20:43 - 'EFI\memtest\shellx64.efi' is a valid loader file
09:20:43 - Adding tag for 'shellx64.efi' on 'EVO990p1'

[Teo]

You are the second to report this in the last days i think. I tried to reproduce it, but refind isn’t the primary loader in my case (which means, update hook is disabled and i verified the date of the .efi file, it was old) and i use ext4.

But that gives you an idea for a workaround until it’s fixed: disable the pacman update hook, so that it doesn’t automatically change the .efi version on the ESP on system updates.

[linux-aarhus]

rEFInd can only boot efi programs with .efi extension or a linux kernel directly if it is on a file system readable by rEFInd.

Using rEFInd to boot from a subvolume may not be ideal and as you have experienced it may be somewhat unreliable.

I would not bother to troubleshoot btrfs and rEFInd but instead change the system to use a unified kernel.

Edit the /etc/mkinitcpio.d/<kernel>.preset to create an UKI (Unified Kernel Image)

EDIT:

If you don’t want to use UKI stored on the $esp then perhaps you should verify the kernel argumant something like rootflags=subvol=@

There is this topic from a couple of years ago Seeking help with rEFInd config for root on Btrfs subvolume / Installation / Arch Linux Forums

Still - pointing rEFInd to the correct subvolume would be difficult especially when you have implemented shapshots.

I have given this a lot of thought - I still think that your best option is to use UKI - this will ensure you always have complete kernel to load - even if your @ root subvolume should act up.

[ddt3]

Thanks for your reply but I think the response misses what I reported.

The issue is not that rEFInd can’t boot from a btrfs subvolume. It has been doing exactly that, reliably, on this system for a long time. The issue is a problem in a specific package build.

A few facts from my report that I’d ask you to consider:

• The system booted correctly with the previous refind_x64.efi. Nothing else changed.
• Replacing only refind_x64.efi with the pre-update binary restores full functionality immediately.
• Reinstalling the 0.14.2-2 package, which puts the new refind_x64.efi back, breaks it again immediately.
• Both binaries identify themselves as rEFInd 0.14.2 built with GNU-EFI — the upstream version string is identical. Only the package revision differs.
• The two log files show that the new binary fails to read the labels of the btrfs volumes during the volume scan phase. The old binary reads them correctly. The btrfs_x64.efi driver is unchanged between both captures.
• The new binary also appears to enters an infinite tool-scanning loop and never reaches the main menu. The old binary completes initialization cleanly and enters the main loop.

None of this is a btrfs/rEFInd architectural incompatibility. It worked before, and it works again the moment the old binary is restored. The logs document this in detail.

@linux-aarhus

Using rEFInd to boot from a subvolume may not be ideal and as you have experienced it may be somewhat unreliable.

I can’t find any information on why this might be unreliable. Actually the refind page on the Arch wiki has a specific section named “Btrfs subvolume support”.

EDIT:
For booting snapshots, I use an AUR package: refind-btrfs-snapshots-bin, it automatically generated the snapshot boot entries. Almost in the same way as refind_linux.conf does for the standard kernel entries.

[linux-aarhus]

@ddt3

I can’t find any information on why this might be unreliable. Actually the refind page on the Arch wiki has a specific section named “Btrfs subvolume support”.

If you are confident with btrfs - what can I say - great

I don’t use refind - I boot my systems directly from UEFI using UKI - but am I correct in the assumption that all refind binaries are stored on the $esp?

I am perhaps a bit opinionated as I see btrfs is a great invention but it complicates the file system structure.

On one hand it is great because it remove the boundaries of partitions.

On the other hand - for a personal computer - it has to be closely watched as to not become pure garbage.

It is great for SAN where data is the commodity and you simply keep adding storage.

I have tried having btrfs puke on me a couple of times - so I am not a huge fan.

That is why my suggestion is to use a unified kernel instead of loading from a subvolume.

As for refind package - it is inherited from Arch Linux - so there is not much Manjaro will/can do about it.

rEFInd is the same version across Arch and Manjaro branches

 $ mbn info refind -q
Branch         : archlinux
Name           : refind
Version        : 0.14.2-2
Repository     : extra
Build Date     : Fri 13 Mar 2026 18:55:06 
Packager       : Campbell Jones <serebit@archlinux.org>
Branch         : unstable
Name           : refind
Version        : 0.14.2-2
Repository     : extra
Build Date     : Fri 13 Mar 2026 18:55:06 
Packager       : Campbell Jones <serebit@archlinux.org>
Branch         : testing
Name           : refind
Version        : 0.14.2-2
Repository     : extra
Build Date     : Fri 13 Mar 2026 18:55:06 
Packager       : Campbell Jones <serebit@archlinux.org>
Branch         : stable
Name           : refind
Version        : 0.14.2-2
Repository     : extra
Build Date     : Fri 13 Mar 2026 18:55:06 
Packager       : Campbell Jones <serebit@archlinux.org>

I have experimented with refind and systemd-boot when topics on the forum requires it - my preferred method is UKI directly from the EFI firmware.

[ddt3]

I have the opposite experience btrfs snapshots have saved me a few times.

A couple of clarifications on my setup: my subvolumes do not cross a disk boundary. I have 2 NVMe drives, both formatted as btrfs, but no subvolume or volume spans across both disks. I do admit that btrfs still confuses me at times when dealing with a mounted btrfs “root” and its subvolumes — they look like directories but are not.

On the UKI suggestion: it would only work as a fallback in my case if the UKI is stored on the ESP. The reason is that in this failure the new refind_x64.efi hung completely before reaching the main menu — no manual stanzas were shown, nothing was launched. So rEFInd could not have reached a UKI stored anywhere other than the ESP.

Storing the UKI on the ESP would get me back to a bootable system after a bad rEFInd update, which is useful. However, it would not give me the ability to roll back to a previous snapshot when a kernel update causes issues, or when I want to compare system state to “how did this work before that update”. That use case — booting a previous snapshot with its original kernel and initramfs — is exactly what I rely on btrfs snapshots for, and a single UKI on the ESP cannot replicate that.

EDIT:
I am now adding a UKI to ESP as an easier backup than booting a live Manjaro USB.

[linux-aarhus]

I have found this

refind-0.14.2-2 issues / System Administration / Arch Linux Forums

pointing to

No loaders found on ext4 XBOOTLDR partition with 0.14.2-2 (works with...

In any case you should really look into mounting the $esp at /boot which makes the kernels available on a FAT file system.

[ddt3]

Thank you for that, I did some googling but did not find those: the second link actually states that 0.14.2-3 is now in [extra-testing] so will probably make it’s way to Manjaro too

Thanks for you replies and insights: Now back to why I booted up my system in the first place

[soundofthunder]

@ddt3

Posting this in case anyone else is hitting the same issue and to leave a record for the maintainers.

It’s important to monitor the respective Update Announcements thread – including the comments – having done so, you might at least have found a workaround sooner.

I experienced the same issue:

@soundofthunder

rEFInd was updated to 0.14.2-2 as a part of the 2026-05-02 Stable Update.

On reboot, I encountered: WARNING: SelfVolume not found

At that point, the boot process halted. My quickest resolve was to boot using a Manjaro Live ISO and enter a chroot environment; install manjaro-downgrade install the previous rEFInd iteration; use the refind-install command to update files in the $ESP.

The immediate issue was resolved, however after testing a few times with the later version, the result was the same each time. Something was afoot. I noticed the rEFInd maintainer has changed – whether that has any bearing on this issue I can’t say, but is could be a factor.

I haven’t found anything definitive on this, so am hopeful this comment may trigger a response from anyone experiencing the same. Perhaps there’s a packaging issue (I believe it’s inherited from Arch) that’s been missed; at this time, anything is possible.

Is anyone able to reproduce?

→ rEFInd v0.14.2-2 ←

And a comment from @philm pointed me in the right direction:

@philm

Most likely might be fixed in 0.14.2-3 which you can find in Arch-Testing. There are issues with gnu-efi 4.x: Add further fixes when built against gnu-efi 4.x (b2b1c4f0) · Commits · Arch Linux / Packaging / Packages / refind · GitLab

Downgrading to the previous iteration of refind allowed me to continue using my machine, and safely await the “fixed” version release when available.

Regards.

---

@linux-aarhus

In any case you should really look into mounting the $esp at /boot which makes the kernels available on a FAT file system.

This should not be required (I do recall it was commonly suggested, several years ago) – refind provides efi file system drivers for both ext4 and btrfs and these negate the need for taking such a step.