Bug 211767 - boot1.efi probing doesn't find ZFS pool unless delaying execution of boot1 a few seconds after power on
Summary: boot1.efi probing doesn't find ZFS pool unless delaying execution of boot1 a ...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.0-BETA4
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2016-08-12 08:25 UTC by Joel Lopes Da Silva
Modified: 2016-08-14 01:04 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Joel Lopes Da Silva 2016-08-12 08:25:04 UTC
I just installed FreeBSD 11.0-Beta4 on a Mac Mini (Late 2014) with an external Thunderbolt enclosure that contains two WD Red drives. This is a root-on-ZFS setup, where the 2 drives used in a mirror vdev. For more information on my setup, you can find the exact steps I followed in here: https://github.com/JoeKun/freebsd-configuration/blob/master/documentation/freebsd/freebsd.md

After switching to the FreeBSD partition for the Mac Boot Manager, when I reboot the Mac Mini, boot1.efi fails with the following output:

>> FreeBSD EFI boot block
    Loader path: /boot/loader.efi
    Initializing modules: ZFS UFS
    Probing 7 block devices.......... done
     ZFS found no pools
     UFS found no pools
 Failed to load '/boot/loader.efi'
 panic: No bootable partitions found!

However, things behave differently if, right when the Mac Mini starts up, I hold the Option key down so the Mac Boot Manager will not immediately start executing boot1.efi, and instead allow the user to change the partition from which to boot. When I do that, and then I just press Enter to proceed booting from the FreeBSD partition, I get straight into the Beastie screen, and FreeBSD boots flawlessly.

This is 100% reproducible with my hardware setup.

It's as if there's some kind of race condition between /boot/boot1.efi probing the block devices and the devices being fully powered on, or started up, or something like that. The mere introduction of this artificial delay allows boot1.efi to successfully find the ZFS pool.

Is there a way that we can have boot1.efi sleep for a certain amount of time before probing the block devices? Or maybe try again a couple of times if probing didn't yield anything interesting?
Comment 1 Steven Hartland freebsd_committer 2016-08-14 00:36:43 UTC
Tbh this sounds like a hardware problem as all devices should really be fully prepared and powered on by the efi before it starts the boot process.

See if you have a BIOS / firmware updates.

You can get much more verbose boot by build the EFI loader with EFI_DEBUG (don't forget to install the new loader to the boot partition)
Comment 2 Joel Lopes Da Silva 2016-08-14 00:47:52 UTC
I don't have any BIOS / firmware update available, no.

I'm still very new to this; can you point me to instructions on how to "build the EFI loader with EFI_DEBUG"?
Comment 3 Steven Hartland freebsd_committer 2016-08-14 01:04:53 UTC
cd /usr/src
make buildenv -DEFI_DEBUG
cd sys/boot/efi/boot1
make clean

Then install the new boot1.efifat to your efi partition.