Date: Mon, 5 Dec 2016 09:31:25 -0500 From: Eric McCorkle <eric@metricspace.net> To: Ben Woods <woodsb02@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: CFT EFI Boot Refactoring Message-ID: <6a6e96bf-3380-a28b-622f-5d6777b4afd6@metricspace.net> In-Reply-To: <CAOc73CCgFsPO6DOsM=jx4T04h=8DnTtH%2B0KOzOa-qT9nb_3Pog@mail.gmail.com> References: <d3aad5ef-2d6c-3d79-0fe8-91ee086ed2f8@metricspace.net> <CAOc73CAV5tXa%2BG%2BHfDS5DX-pytwg4XZ7PUSKw4haQ3=0Z=HO%2BQ@mail.gmail.com> <c1ed3afc-fe28-a1e4-743e-4750bf200400@metricspace.net> <CAOc73CBo9apCsHkL41izakpizVzgH4QOoyX2o9CkNt3%2BOMt2GQ@mail.gmail.com> <675cb468-f599-a31b-a82c-c0f892136cfc@metricspace.net> <CAOc73CD69QzYCpYbW5ONd11fnMc9fKnLowX0NdE2fPTr7a4CTQ@mail.gmail.com> <ae806c20-4cf7-4c6b-d18a-6e7a4d21bee9@metricspace.net> <CAOc73CCgFsPO6DOsM=jx4T04h=8DnTtH%2B0KOzOa-qT9nb_3Pog@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P3NHmWQv9U0nrpJKO1AeXWXqU83OhhxdP Content-Type: multipart/mixed; boundary="Q2Bp1fUFFeUdNbmsOTOMuiTa0bOqUQ8bi"; protected-headers="v1" From: Eric McCorkle <eric@metricspace.net> To: Ben Woods <woodsb02@gmail.com> Cc: freebsd-hackers@freebsd.org Message-ID: <6a6e96bf-3380-a28b-622f-5d6777b4afd6@metricspace.net> Subject: Re: CFT EFI Boot Refactoring References: <d3aad5ef-2d6c-3d79-0fe8-91ee086ed2f8@metricspace.net> <CAOc73CAV5tXa+G+HfDS5DX-pytwg4XZ7PUSKw4haQ3=0Z=HO+Q@mail.gmail.com> <c1ed3afc-fe28-a1e4-743e-4750bf200400@metricspace.net> <CAOc73CBo9apCsHkL41izakpizVzgH4QOoyX2o9CkNt3+OMt2GQ@mail.gmail.com> <675cb468-f599-a31b-a82c-c0f892136cfc@metricspace.net> <CAOc73CD69QzYCpYbW5ONd11fnMc9fKnLowX0NdE2fPTr7a4CTQ@mail.gmail.com> <ae806c20-4cf7-4c6b-d18a-6e7a4d21bee9@metricspace.net> <CAOc73CCgFsPO6DOsM=jx4T04h=8DnTtH+0KOzOa-qT9nb_3Pog@mail.gmail.com> In-Reply-To: <CAOc73CCgFsPO6DOsM=jx4T04h=8DnTtH+0KOzOa-qT9nb_3Pog@mail.gmail.com> --Q2Bp1fUFFeUdNbmsOTOMuiTa0bOqUQ8bi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/05/2016 08:43, Ben Woods wrote: > Ok, I have tested with the extra_logging branch, and can report that th= e > text on the screen at the time of the hang was: >=20 >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > 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 > _ >=20 That would strongly suggest that tsoome's bug is the actual cause. >=20 > 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: >=20 >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > 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. >=20 > 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. --Q2Bp1fUFFeUdNbmsOTOMuiTa0bOqUQ8bi-- --P3NHmWQv9U0nrpJKO1AeXWXqU83OhhxdP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF4EARYIAAYFAlhFekIACgkQVsKIQKqABI2dDQEA/y7sWuj+D2g4PsuMg8DeME/6 d0auZW1hVGEjrCaQmt4BAM32lHMWmp3mjtAb9m+1jlX5/WHC+YkduSa7FAka/VUD =ar2n -----END PGP SIGNATURE----- --P3NHmWQv9U0nrpJKO1AeXWXqU83OhhxdP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6a6e96bf-3380-a28b-622f-5d6777b4afd6>