Slow boot when installing rEFInd on macbook boot partition

[Romeo Van Snick]

I've successfully managed to set up rEFInd in the /EFI folder of my OS X partition, this works really good and the laptop boots into rEFInd in less than 1sec.

However, I'd like to set up rEFInd in the EFI boot partition of my laptop, because this allows me to manage it from other operating systems. But when I do this, the boot time increases dramatically (it takes 30sec to go into rEFInd, the rest of the boots take equal time as before).

Has anyone else had this problem, and know how to fix it?

[Roderick W. Smith]

I've received a few reports of similar problems, but I've never encountered it myself, so it's something I've been unable to fully investigate. As far as I can tell, though, it's an issue of the firmware being sluggish. I've seen one report of a fix in an Ubuntu forum, but I've not tested it, and I must emphasize that it uses the efibootmgr utility in Linux, which some other sources suggest is risky (but some claim that the risk is reduced with recent kernels). In any event, if you care to try it (at your own risk), the procedure is described here:

http://ubuntuforums.org/showpost.php?p=12256273&postcount=200

[Romeo Van Snick]

I'd rather not use efibootmgr. Isn't there a method that allows refind to run from the apple partition but where I put the linux boot files (initramfs etc.) in the efi boot partition? this way I can safely update the linux boot files without having to mount the mac partition (which requires disabling of journaling).

[Roderick W. Smith]

Yes, you can run rEFInd from the OS X boot partition and it should detect and run a Linux boot loader (GRUB, ELILO, or the kernel's own EFI stub loader) from the ESP. No special configuration should be required to do this, since rEFInd automatically scans every disk it can read for boot loader files in the root directory or in most EFI/{subdirname} directories.

Alternatively, if you've got a separate Linux /boot partition, you can place your boot loader there if you use ReiserFS, ext2fs, or ext3fs (but not ext4fs) on /boot. To do this, you'll need to install the relevant filesystem driver (included with rEFInd, but not installed by the install.sh script). Uncommenting the scan_all_linux_kernels option may be desirable if you do this; this option tells it to treat any file with a name that begins with "vmlinuz" or "bzImage" as a boot loader. This method can be particularly handy if you use the EFI stub loader. Since most distributions place the kernel in /boot and include the kernel version number in the filenames for both the kernel and its initrd file, an appropriate rEFInd configuration will auto-detect new kernels when you upgrade, with no need to copy the kernel or initrd file to a new location or edit any configuration file.

[Gaetano Giunta]

I can confirm that putting refind on ESP adds a few (...) seconds to the boot process.
It is at the very beginning: grey screen, before refind icons show up.
This however seems to be somehow tied to the contents of the mbr - or to something else which I did not identify correctly: at some point f.e. the slowness went away (iirc after installing ubuntu), but (after resetting nvram) it came back.

Q1: how does one inspect nvram contents to find out if there is any info there about current boot-device/loader?

Q2: how can we tell if the slowness is due to refind scanning disks or if it is due to stuff the mac does before loading refind?

[Roderick W. Smith]

At the moment, I don't know of any good user-friendly tools for examining NVRAM contents on EFI systems. You can extract some information from Linux by using the efibootmgr utility and by examining the contents of /sys/firmware/efi/vars. The latter is very low-level stuff, though, and the former is intended for standard EFI/UEFI systems, not the Mac's weird variant. Also, any OS-level tool will only give you access to the EFI's runtime variables, not the boot variables. The best way to examine EFI variables is likely to use the dmpstore command in an EFI shell. Type dmpstore -b to see them all in a pager. Type ? dmpstore -b to see help information. Understanding the variables is another matter, and a greater challenge. I can't really help on that score, since I have yet to study EFI variables on this level.

One non-definitive test you could try to determine where a delay is occurring is to reconfigure rEFInd to use text mode rather than graphics mode (uncomment the textonly line in refind.conf). The video mode is set before disks are scanned, so if disk scanning were causing a delay, the delay would occur after the screen clears to black if you run in text mode. You could also insert Print() statements in the efi_main() function in rEFInd's main.c file to determine where a delay is occurring, if it's happening within rEFInd. (On a Mac, you'd need to run in text mode to see the Print() statements' output.)

[Sean]

Hi guys,

I have a delay of 60s or more before refind displays the boot menu. I just replaced refit with refind in an attempt to fix the issue, without success. I'm running OS-X 10.7 and Xubuntu on a Macbook Pro 8.1. I am using full disk encryption in OS-X, so I used the --esp flag with the install script (really smooth install by the way, kudos!). I have the same reluctance to try the steps suggested on the ubuntu forum, though I may recant in desperation if I can't find another solution.

I'll post back with the results of a textonly boot.

[Sean]

...and we're back. With textonly, I see the white / grey screen (no apple logo) right up until the rEFInd black screen (showing boot options). Incidentally, I made sure to shutdown (rather than restart) from OS-X and now the delay has reduced to ~30s.

Is it generally thought that this delay is caused by waiting around to test other boot options before booting with rEFInd? If so, could we use efibootmgr to adjust the boot order, without deleting any existing entries? I might try that from OS-X.

[Roderick W. Smith]

I really don't know what the precise cause is, except that I strongly suspect it's a problem in the firmware, not in rEFInd. Using efibootmgr to fiddle with settings might work, but be aware that efibootmgr is a Linux tool, not an OS X tool. (Unless there's an OS X port of which I'm unaware.) Some sources suggest that efibootmgr can damage some Macs' firmware, although I've seen suggestions that this is restricted to pre-3.0 kernels. Sorry I can't be more definitive about any of this; solid information on such matters is hard to find.

[joevt]

Here's a test you can try. Create two new partitions 50 MB each, one FAT and one HFS. Put rEFInd on both. Give them a different banner or add a unique stanza for each of them so you can be sure which is booted. For each of those two partitions, bless rEFInd, then reboot. The FAT one will take 30 seconds. The HFS one will be instant. The EFI partition is also a FAT partition. This problem doesn't appear on all Macs though...

[qammm]

With rEFInd 0.6.8 installed in ESP of my MacBook Air 3,1 I also had that "30 secs pause" before rEFInd menu shows up. With rEFInd 0.6.4 installed in the same ESP the rEFInd menu shows up almost immediately. From my point of view that seems to be related to some code change introduced after 0.6.4 that causes this long pause...

[Roderick W. Smith]

As noted in this thread, the 30-second delay problem existed prior to version 0.6.4 -- in fact, it's been reported in rEFIt. Some users have reported not having the problem, and it then appearing when upgrading or even when re-installing the same version. This suggests to me that the root cause is something to do with the way the Mac's firmware stores boot loader information or launches programs from a FAT partition. Testing with an unrelated boot loader, such as gummiboot or GRUB, might help clarify the issue. Unfortunately, since I've never encountered the problem myself, I'm unable to perform such tests myself. This is one of the frustrating aspects of rEFInd development; EFIs vary greatly from one machine to another, so bugs often turn up in some environments but not in others, which makes debugging certain problems quite difficult.

[joevt]

I managed to recreate the 30 second delay problem with my HFS+ partition (I have never been able to remove the 30 second delay problem with my FAT partition).

1) Use the "bless --folder --file --verbose" command to bless refind.efi on the HFS partition. This stores the UUID of the disk in the efi-boot-device nvram parameter. It also sets the blessed folder and blessed file node IDs in the HFS+ Volume Header.

2) Duplicate refind.efi, delete the original (Empty Trash if you put it in the Trash), and rename the copy to refind.efi. This makes the blessed file node ID invalid in the HFS+ Volume Header because the file was deleted.

3) Use the "bless --mount --file --verbose" command to bless refined.efi on the HFS partition. This sets efi-boot-device the same as step 1 except it also adds an EFI path to refind.efi. This will not change the HFS+ Volume Header.

The --verbose option will tell you what the bless command is doing. The man page for bless mentions the HFS+ Volume Header.

The information in the nvram parameter is also mirrored in efi-boot-device-data as binary data.

Using "bless --mount" on HFS+ partitions won't cause the 30 second delay as long as the Volume Header still contains a correct value for the blessed file.

Maybe Apple made a fix to the firmware to remove the 30 second delay? I'm using a Mac Pro 2008 with EFI firmware 1.3. http://support.apple.com/kb/HT1237
Or maybe the delay doesn't exist with older firmwares?

I have available some old Mac minis and an iMac that I could try.

[Uncle Sam]

Just adding my experiences on the slow startup issues on Mac:
I originally had rEFInd installed into the esp of an external drive. Always had slow bootup, even with the external drive disconnected.

I then tried installing rEFInd into my internal drive's esp, and I now get the rEFInd menu screen as soon as the startup chime finishes - its great - so much faster! Wish I'd done it ages ago. The only difference this time is that I renamed the path and binary to /EFI/BOOT/bootx64.efi

I made some a simple script to make it easier to update the rEFInd binary and configs too (I like to do things manually):

1 2 3 4 5 6 7 8 9 10 11 12 13

#!/bin/bash sudo mkdir /Volumes/esp read -p "Press [Enter] key to continue..." sudo mount -t msdos /dev/disk0s1 /Volumes/esp read -p "Press [Enter] key to continue..." sudo bless --mount /Volumes/esp --setBoot \ --file /Volumes/esp/EFI/BOOT/bootx64.efi --verbose read -p "Press [Enter] key to continue..." sudo umount /Volumes/esp read -p "Press [Enter] key to continue..."

If anyone is looking to compare, I'm using a macbook pro 8,2 (late 2011 with SSD)

@Rod, maybe it would make sense to install rEFInd on Mac's using the path and binary name /EFI/BOOT/bootx64.efi as the default?

[Thomas Engelschmidt]

Hi Sam,

Your fix, worked like a charm.
Booted up on a recovery osx usb, entered the terminal and followed your instructions.

Instant booting of the refind bootmgr :) instead of ~20s.
Cheers
Thomas

[Roderick W. Smith]

The default behavior of install.sh is to install rEFInd to the OS X root (/) partition, not to the ESP, because this seems to work more reliably on most systems. I'll consider changing the behavior when using the --esp option to install to EFI/BOOT/bootx64.efi, but the problem with that is that this is a fallback boot filename that might already be in use by another program. Using that filename is already documented as a possible workaround.