rEFInd: very slow boot when using EFI Stub Loader

Question

After a recent re-install, I found myself experiencing a very strange problem with rEFInd: while it detects both GRUB and vmlinuz on my /boot partition, using the latter is extremely slow.

Specifically, immediately after selecting "Boot vmlinuz-4.8.0-53-generic from 191 MiB ext2 volume", I'm shown a black screen with the following text:

Starting vmlinuz-4.8.0-53-generic
Using load options 'root=UUID=6641e1e2-6829-49cc-bf88-85ba5eefbff8 ro quiet splash nomodeset vt.handoff=7 initrd=\initrd.img-4.8.0-53-generic'

After about a minute of waiting (!), Linux boots normally (and rather quickly).

If I select GRUB on the other hand, I'm taken to the GRUB boot menu and, after selecting the default option, Linux immediately starts booting.

What could be the reason for this?

My setup includes an SSD (where I have Linux and Windows installed) and an HDD (where my /home is), with a an ext2 /boot partition and the EFI partition (created by Windows initially) mounted on /boot/efi. Here's my /etc/fstab:

UUID=6641e1e2-6829-49cc-bf88-85ba5eefbff8 /               ext4    errors=remount-ro 0       1
UUID=3c804805-c41e-4b9d-af02-118b98858ae4 /boot           ext2    defaults        0       2
UUID=8EA5-5319  /boot/efi       vfat    umask=0077      0       1
UUID=bf088ec8-140d-4829-8de7-deb1d375b0e5 /home           ext4    defaults        0       2
UUID=E2A8CA84A8CA5727 /mnt/Windows    ntfs    defaults,umask=007,gid=46 0       0
UUID=3fb0b28d-87d8-4162-b469-1c157a4d00b0 none            swap    sw              0       0

Answer 1

I'm rEFInd's maintainer.

This is a filesystem driver issue. For reasons I don't fully understand, some of rEFInd's filesystem drivers (especially the ext2_x64.efi driver) are slow on some computers. I added a crude readahead cache to the driver code several years ago, and this helped a lot -- under VirtualBox, the speed improved from about a 3-minute load time to a few tens of seconds, IIRC. Some computers continue to have problems even with this cache, though.

The solution is to change to another filesystem. rEFInd's ext4fs driver is much faster than its ext2/3fs driver, and the Btrfs and ReiserFS drivers are faster still. (Note that the ext4fs driver can read ext2fs, but will provide little or no speed improvement that way; it needs to read an actual ext4 filesystem to provide a speed improvement.) In a worst-case scenario, you could use FAT, which requires no special driver (it's built into all EFIs); or on a Mac, you could use HFS+. (There's also an HFS+ driver that comes with rEFInd, so in principal you could use HFS+ even on a non-Mac PC, but there's little or no point to doing so.) Moving outside of a standard Linux filesystem is inadvisable, though. Ubuntu relies on symbolic links for some (but not all) kernel updates, making FAT a poor choice; and although HFS+ should work, it's not officially supported by Ubuntu. Even ReiserFS is not an option in the Ubuntu installer, so I'd steer clear of it for Ubuntu. That leaves ext4fs and Btrfs.

Switching is fairly straightforward, but not risk-free -- if you make a mistake, your system might be rendered unbootable. The bare-bones procedure is:

1. Copy the new filesystem driver to the rEFInd drivers or drivers_x64 subdirectory (/boot/efi/EFI/refind/drivers or /boot/efi/EFI/refind/drivers_x64, probably). Removing the old ext2_x64.efi file from that location will reduce rEFInd's load time by a second or so.
2. Unmount the ESP (/boot/efi).
3. Back up the /boot partition. You can use zip, tar, cp, or some other file-level tool for this.
4. Unmount /boot.
5. Create a new filesystem on the /boot partition.
6. Type sudo blkid /dev/sda{x} (changing /dev/sda{x} to the identifier for your /boot partition) to learn its new UUID value.
7. Edit /etc/fstab to change the UUID value and filesystem type for the /boot partition.
8. Type sudo mount -a to mount the new /boot partition. (It will likely complain that there's no /boot/efi mount point. You can ignore this warning.)
9. Restore the backed-up /boot files to the new /boot filesystem.

At this point, you should be able to reboot and it will work better. A mistake, though, could cause the system to be unbootable. To reduce that risk, you can copy at least one working kernel, initrd file, and refind_linux.conf from /boot to /boot/efi and test your ability to boot the kernel from the ESP before you begin. This will give you a fallback way of booting in case of a problem. If there are no problems, you can of course delete the kernel from the ESP once you're done.

For more on rEFInd's drivers, see its documentation on this subject:

http://www.rodsbooks.com/refind/drivers.html