[Bug 211767] boot1.efi probing doesn't find ZFS pool unless delaying execution of boot1 a few seconds after power on

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211767

            Bug ID: 211767
           Summary: boot1.efi probing doesn't find ZFS pool unless
                    delaying execution of boot1 a few seconds after power
                    on
           Product: Base System
           Version: 11.0-BETA4
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: joel at lopes-da-silva.com
                CC: freebsd-amd64 at FreeBSD.org
                CC: freebsd-amd64 at FreeBSD.org

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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.