From ArchWiki
Jump to: navigation, search

Is there a more universally applicable method of installation?

As some firmware isn't fussy about the name of the directory after $esp/EFI/ - nor the name of the efi stub contained within it - then logically bootx64.efi in $esp/EFI/boot should work for them as well. If this is the case (I do not have the hardware to test), then the current "standard" automated installation method refind-install could be replaced with refind-install --usedefault /dev/sdxY --alldrivers, which would work on a far broader range of UEFI firmware.

Does anyone have any experience of this? Or the ability to test it? Carlduff (talk) 11:14, 24 September 2014 (UTC)

On page 78 of the spec, it states that "default boot processing behavior may optionally occur" if all of the processes for the "normal system policy" fail. This default processing is what boots the fixed EFI/BOOT/BOOT* path. So I think this makes it clear that this behavior is not guaranteed in UEFI implementations and that it is also a fallback.
It is also conceivable that a user may already have a UEFI executable in their default path and they wish to install rEFInd along side it. I don't think there's going to be a nice catchall solution unless the install script is updated to be much more clever. Silverhammermba (talk) 18:52, 24 September 2014 (UTC)
Agreed. Worth a try. Carlduff (talk) 22:56, 24 September 2014 (UTC)

btrfs subvolume root support

This might be worth adding as another way of getting refind to auto detect Arch on Btrfs

To allow kernel auto detection on a Btrfs partition uncomment and edit also_scan_dirs in refind.conf.

also_scan_dirs subvolume/boot

Then add rootflags=subvol=subvolume to refind_linux.conf and predend subvolume to the initrd path.

"Boot using standard options"  "root=PARTUUID=XXXXXXXX rw rootflags=subvol=subvolume initrd=subvolume/boot/initramfs-linux.img"

7x1x (talk) 02:08, 24 August 2017 (UTC)