Possible to migrate from grub.efi to rEFInd?

[Eric Ihli]

I hope I'm using the right terms when I ask if it's possible to migrate from "grub.efi"... I'll explain in more detail, but basically a Manjaro install to an encrypted partition created a grub.efi file that rEFInd can see and launch to, and I can decrypt the luks partition and from that grub menu I can launch Manjaro. I'm trying to cut out the middle man of grub and go straight decrypting luks/launching Manjaro.

Here's more of the details.

I shrunk my Windows partition, created an unencrypted “boot”
partition, and installed Manjaro and Pentoo on two other partitions
and chose the “encrypt” option.

Is it possible to do what I'm trying to do?

I am figuring Manjaro’s install did all the work
of setting up initramfs with mkinitcpio and the right encrypt hooks
since it’s working through grub.efi. I assume it’s just a matter of
getting the right kernel options/parameters into rEFInd.

Do these options look correct?

The volume is correct. I was initially getting an error about not being able to find the loader. Once I got the volume correct, that error went away. The location of the initrd and cryptdevices should be correct. I copied them from the options of the working grub config. I got them by launching into the grub.efi and then pressing “e” to edit/view the parameters. So it’s the same cryptdevice and root that the working grub is using.

menuentry "Manjaro Custom" {
    icon     /EFI/refind/icons/os_arch.png
    volume   BOOT
    loader   /boot-manjaro/vmlinuz-5.10-x86_64
    initrd   "/boot-manjaro/intel-ucode.img /boot-manjaro/initramfs-5.10-x86_64.img"
    options  "cryptdevice=UUID=45a39ae3-123e-4e09-9167-ef88868fe90c:cryptroot root=UUID=16995cba-cabe-4dd1-8220-6b00d93df5fa rw add_efi_memmap"
}

Now, I see a few lines during boot that say it’s loading. The last line prints out the options that it’s loading with, the kernel parameters I guess, that it’s using that initrd and those options, and then it just freezes. I have to re-power the machine to get out of the freeze.

Thanks for any pointers in the right direction.

If its relevant:

# /etc/crypttab: mappings for encrypted partitions.
#
# Each mapped device will be created in /dev/mapper, so your /etc/fstab
# should use the /dev/mapper/<name> paths for encrypted devices.
#
# See crypttab(5) for the supported syntax.
#
# NOTE: Do not list your root (/) partition here, it must be set up
#       beforehand by the initramfs (/etc/mkinitcpio.conf). The same applies
#       to encrypted swap, which should be set up with mkinitcpio-openswap
#       for resume support.
#
# <name>               <device>                         <password> <options>
luks-45a39ae3-123e-4e09-9167-ef88868fe90c UUID=45a39ae3-123e-4e09-9167-ef88868fe90c     /crypto_keyfile.bin luks

And a relevant part of mkinitcpio:

HOOKS="base udev autodetect modconf block keyboard keymap encrypt filesystems fsck"

[Eric Ihli]

I have a cross-post on the Manjaro forums with additional discussion and details in case that's useful to reference. https://wiki.archlinux.org/title/dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs

[Roderick W. Smith]

First, understand that rEFInd relies on the EFI for all file I/O. Thus, rEFInd can read a Linux kernel if and only if it's on a filesystem that the EFI can read. Natively, all EFIs can read FAT filesystems. A few can read HFS+, APFS, ISO-9660, and/or NTFS, but these implementations are rare. The usual way to get rEFInd to read a Linux kernel is to add an EFI filesystem driver, as described in the rEFInd documentation. If the filesystem that holds the Linux kernel is an a RAID or LVM setup, or if it's encrypted, then an additional EFI driver to handle this extra layer would be required; but AFAIK, no such EFI driver exists. Thus, as a practical matter, the Linux kernel must exist on an unencrypted filesystem for which an EFI filesystem driver exists. rEFInd ships with drivers for ext2/3fs, ext4fs, Btrfs, and ReiserFS.

Second, I strongly recommend against using manual boot stanzas unless you absolutely must. It's too easy to get some tiny detail wrong (as in a typo), in which case the whole thing comes crashing down. rEFInd's auto-scan feature works fine in most cases, and if it's not working, chances are a manual boot stanza won't work any better -- or if a manual boot stanza would work, some simpler adjustment (like adding an also_scan_dirs line) would be a simpler solution. There are exceptions to this rule, but they're rare. Manual boot stanzas also give you more control over the naming of the boot entry, but IMHO that's a trivial issue compared to getting the computer to boot.

If your current configuration is booting from an unencrypted /boot partition, then rEFInd should be able to boot it. If rEFInd is not detecting the kernels, and if you're using a stock refind.conf file (or at least, have not changed the relevant scanning options), then the most likely explanation is that you haven't installed the necessary EFI filesystem driver. If rEFInd is showing the kernel(s) on the /boot partition, but selecting the kernel in rEFInd is not booting the system, then there's another problem, which can likely be overcome by editing /boot/refind_linux.conf to add the necessary options. You should be able to copy options over from your working GRUB configuration -- but be aware that grub.cfg uses some syntax that's incompatible with the syntax used in refind_linux.conf, so you may need to translate it.

[Eric Ihli]

Update: I recreated refind_linux.conf using the mkrlconf script and the kernel found with auto-scan works! But now... I realize Manjaro embedded the crypto_keyfile.bin in initramfs defeating the point of encryption (https://wiki.archlinux.org/title/dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs).

But I at least made progress and have a direction to go. Thanks!

Update #2: For the archives

Got it working with the manual config using options copied straight from the refind-linux.conf config that was automatically generated. Aside from those options, it was just a matter of making sure the volume correctly had the label of the unencrypted "boot" partition and the paths to the initrd and loader were accurate. Note: the initrd= of the menuentry gets appended to any innitrd= passed in the option string (is my understanding).

---

Thanks for the notes. I ran into the filesystem drivers problem but solved that.

Here's an thought that might be the issue that's not directly related to rEFInd config but I would be super appreciative of any thoughts.

During the install of my Linux flavor, I didn't specify a separate /boot partition. So originally, /boot was encrypted on the same partition as everything else. My attempted solution was to create a FAT32 partition after linux was already installed and then copy all of the files from /boot over to that new partition.

Are there any "gotchas" that would cause that to fail and any specific changes I'd need to make to fix the issue?

I thought it would just work, because rEFInd detects the kernels and, as I mentioned, I can boot from rEFInd -> Grub -> Linux, just not from rEFInd -> Linux. So I thought the issue was that I was missing a particular bit of config that existed in Grub and not in rEFInd. But perhaps copying over /boot from the encrypted partition to a new unencrypted FAT32 partition is not OK?

[Roderick W. Smith]

rEFInd can boot Linux from a kernel stored on a FAT partition. In fact, users of some distributions (like Arch Linux) often mount the (FAT) ESP at /boot to facilitate kernel updates on a FAT partition, and this works fine for them. Some distributions, though, expect to be able to use Unix-style filesystem features (particularly symbolic links) on /boot, and as FAT doesn't support these features, this approach may fail, either immediately or after a while. (Ubuntu's kernel updates sometimes, but not always, use symbolic links, for instance.) Typically, the problem is that installing a new kernel package will fail.

Keep in mind that you may need to copy more than just the kernel files to a FAT partition. In most cases you'll need to copy the initial RAM disk (initrd* or initramfs*) file that matches the kernel you want to boot. rEFInd may also need a refind_linux.conf file to hold kernel options. In rare cases, you may need something else (some distributions use two initrd files, for instance).