CFT EFI Boot Refactoring

[Eric McCorkle]

(Re-adding -hackers, to document the diagnosis)

You're freezing at the same point as where tsoome saw it freeze.

Basically, what's happening at that point in the code is it's probing
all device handles, trying to attach filesystem drivers.  Hanging here
means that it's crashing somewhere in that process.

The boot loader is going to hit every single partition and try all the
filesystem drivers until one works.  It will bail on the ESP, since that
will have an EFI_SIMPLE_FILESYSTEM_PROTOCOL driver courtesy of the EFI
firmware.

Here's the diagnostic information I have so far:

* My setup is a positive example (works): two disks, disk 1 has ESP and
freebsd-zfs, disk 2 has a partition that's held both an msdosfs and a
UFS (it was originally a swap partition that I've been creating various
filesystems on to test the boot process), a zfs intent log, and a zfs
l2arc cache.  All ZFS stuff is part of the same pool, which holds the
root fs.

* Your setup is a negative example (fails).

* tsoome's setup is also a negative example: "The VM has 4 disks,
illumos mirror zfs on first 2, third has fbsd, 4th (for this test) has
EFI system partition, and zfs and ufs partitions, zfs partition has
bootfs with /boot directory."


You don't have a UFS filesystem anywhere, so we can rule that out.  It
might be tsoome's bug, and it might just be that the bug is sporadic,
which would explain why I'm not seeing it on my setup with a dosfs.

The only other obvious commonality between you and tsoome that doesn't
overlap my setup is multiple ZFS datasets, or ZFS data vdevs (mirrors,
stripes, etc) spread across multiple disks (my setup only has a log and
a cache on the ssd).


Here's what I'll do.  I'll create an "extra_logging" branch off of
efize_new in my github repo, wherein I'll add a bunch of extra logging
into the detection process.  It ought to be enough to print out device
paths and filesystem drivers just before it tries them.



On 12/03/2016 21:06, Ben Woods wrote:
> Hi Eric,
> 
> That is correct. Each drive has an EFI partition, which uses msdosfs. My
> FreeBSD drive does not have a UFS partition, as I solely use ZFS on root.
> 
> One thing to note is that in the process of testing your efize_new, I
> did not touch my freebsd-boot partition, and I am not even sure if it is
> being used by the loader. My /boot lives in my ZFS zroot partition, and
> freebsd-boot is not mounted in anyway. Could this have an impact on the
> testing?
> 
> Regards,
> Ben
> 
> --
> From: Benjamin Woods
> woodsb02 at gmail.com <mailto:woodsb02 at gmail.com>
> 
> On 4 December 2016 at 06:06, Eric McCorkle <eric at metricspace.net
> <mailto:eric at metricspace.net>> wrote:
> 
>     So, you have no UFS partitions, but you do have an MSDOSFS partition on
>     each drive?
> 
>     If so, that lends support to tsoome's suspicion that it may be a bug
>     he's working on.
> 

-------------- 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/20161203/a10f680e/attachment.sig>