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-b...@freebsd.org
Reporter: j...@lopes-da-silva.com
CC: freebsd-amd64@FreeBSD.org
CC: freebsd-amd64@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.
_______________________________________________
freebsd-amd64@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
