CFT EFI Boot Refactoring

[Eric McCorkle]

On 12/05/2016 08:43, Ben Woods wrote:

> Ok, I have tested with the extra_logging branch, and can report that the
> text on the screen at the time of the hang was:
> 
>>> FreeBSD EFI boot block
>    Loader path: /boot/loader.efi
> 
>    Initializing modules: FS BackendProbing all handles for ZFS
> Done
> Binding SIMPLE_FILESYSTEM_PROTOCOL to 0xb85bff18
> Binding SIMPLE_FILESYSTEM_PROTOCOL to 0xb85bfc18
> Binding SIMPLE_FILESYSTEM_PROTOCOL to 0xb85bf998
> Probing all filesystems
> Probing dosfs
> _
> 

That would strongly suggest that tsoome's bug is the actual cause.

> 
> Following that, I tried a combination of the old (unmodified)
> BOOTX64.EFI with the new (modified) files in /boot/.
> This produced the following output on the screen before it also hung:
> 
>>> FreeBSD EFI boot block
>    Loader path: /boot/loader.efi
> 
>    Initializing modules: ZFS UFS
>    Probing 10 block devices............* done
>     ZFS found the following pools: zroot
>     UFS found no paritions
> Consoles: EFI console
> Probing all handles for ZFS
> Done
> Binding SIMPLE_FILESYSTEM_PROTOCOL to 0xb85c9718
> Binding SIMPLE_FILESYSTEM_PROTOCOL to 0xb85c9418
> Binding SIMPLE_FILESYSTEM_PROTOCOL to 0xb85c9198
> Probing all filesystems
> Probing dosfs
> _
>

That's to be expected.  The new loader.efi and boot1.efi both use the
same framework for drivers now.

> 
> Hope this is helpful for debugging this issue. Note that once again I
> did NOT run any command to update my freebsd-boot partition (such as
> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada1). Is this
> required?

That stuff is only for BIOS boot.  EFI doesn't use it.  On a pure EFI
system, you don't even need a freebsd-boot partition.


This actually makes a lot of sense.  The new EFI code tries to bind
filesystem interfaces to everything, whereas the old code just probed
and went with the first thing it found.  So it never would have
attempted to use the dosfs driver, so the bug that was lurking there
wouldn't have been turned up.

Your freebsd-boot partition is a partition, but it doesn't have an fs.
So it's going to try everything and fail, so it would definitely turn up
any existing bugs in filesystem drivers.  This also explains why I
couldn't reproduce it: my UFS partition got detected at UFS, and the
msdosfs partition got detected by the UEFI firmware, so it would have
already had an EFI_SIMPLE_FILESYSTEM interface by the time that the boot
loader ran.

This raises another question, though: since the UEFI spec guarantees
that a driver exists which will bind an EFI_SIMPLE_FILESYSTEM_INTERFACE
to any FAT32 filesystem, do we really need our own dosfs driver in the
EFI boot loader?  I would suspect not.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20161205/5350deae/attachment.sig>