Date: Sun, 24 Jan 2016 12:25:34 -0500 From: Allan Jude <allanjude@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: ZFSROOT UEFI boot Message-ID: <56A5090E.4080508@freebsd.org> In-Reply-To: <20160124215300.4cd7f1207f5a4c7b28ef7ffc@dec.sakura.ne.jp> References: <CALfReyeY3=L9O81AX7xMKj3Ai2DTvBpXtbqepTZc2%2BGEsrT3vA@mail.gmail.com> <8991747525093115430@unknownmsgid> <20160124215300.4cd7f1207f5a4c7b28ef7ffc@dec.sakura.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x1HCUnBCk2hcfMs6OHUx1vhIPiG205Ow6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016-01-24 07:53, Tomoaki AOKI wrote: > Unfortunately, this (and its committed successor and original for UFS) > fails to boot in some situation, like below. OTOH, gptzfsboot (and > maybe gptboot for UFS, too) is OK. >=20 > When I select Disk1 from UEFI firmware, bootx64.efi in Disk1 EFI > partition is used and it searches /boot/loader.efi from Disk2 (in ZFS, > if none, in UFS) only. > And when I select Disk2, bootx64.efi in Disk2 EFI partition is used and= > it searches /boot/loader.efi from Disk1 only. >=20 >=20 > In fact, this is a long-standing and living problem. > At past, USB memstick with head memstick.img (UEFI enabled, but > without root-on-ZFS support) booted fine, but after I added UFS2 > partition in internal disk, the USB memstick didn't boot anymore. > It searches /boot/loader.efi from internal UFS and fails as it was > blank (only newfs'ed) at that time. Another USB memstick with stable/10= > memstick.img is still fine, as it's still ancient BIOS based. >=20 In the past I have seen this same behaviour when testing UEFI. I booted from the memstick, and installed the OS. I then used the 'boot select menu', and selected the hard drive, and it booted the system from the USB memstick. If I rebooted and selected the memstick, it booted from the hard drive. It seemed that altering the intended boot drive always caused the opposite of the desired behaviour. > Possibly, it's not a fault of boot1.efi but caused by differense in > implementation of UEFI firmware. If that's it, different boot1.efi > would be needed for each implementation. >=20 > A bit more details of tests are as below. Not all combinations are > covered, but would be sufficient to determine above conclusion. >=20 >=20 > Common configurations for all tests: > *Each disk has one EFI partition (p1), one freebsd-boot partition > (p2), one swap partition (p3), one UFS partition (p4), and one > ZFS pool (p5) with this order. >=20 > *Each partition has different GEOM label. >=20 > *In each disk, FreeBSD is installed as root on ZFS. No other OS. >=20 > *stable/10 (r294614) is installed in Disk1. >=20 > *head (r294567) is installed in Disk2. >=20 > *ZFS-enabled boot1.efi (head r294567) is used as bootx64.efi. >=20 >=20 > Set 1: Boot from Disk1 (select it in UEFI firmware). > In all tests, /boot/loader.efi in Disk1 (both UFS and ZFS) > are NOT searched at all. >=20 > 1-1) Both UFS and ZFS has no /boot/loader.efi > -> Fail to boot. Fall back to boot1 prompt. >=20 > 1-2) Disk2 UFS only has /boot/loader.efi, whole /boot of Disk2 ZFS > is copied to UFS. > -> head in Disk2 boots fine. >=20 > 1-3) Same as 1-2, except its /boot/loader.efi is overwritten by the > one of stable/10. > -> head in Disk2 boots fine, as loader.efi loads kernel from > /boot/kernel/kernel in UFS and kernel with zfs.ko can mount > root on ZFS specified by vfs.root.mountfrom. >=20 > 1-4) Disk2 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS > is copied to UFS and its /boot/loader.efi is overwritten by > the one of head. > -> stable/10 in Disk1 ZFS boots fine. >=20 > 1-5) Disk2 ZFS only has /boot/loader.efi. > -> head in Disk2 ZFS boots fine. >=20 > 1-6) Both UFS and ZFS in Disk2 has /boot/loader.efi. > (Mix of 1-4 and 1-5) > -> head in Disk2 ZFS boots fine. >=20 >=20 > Set 2: Boot from Disk2 (select it in UEFI firmware). > In all tests, /boot/loader.efi in Disk2 (both UFS and ZFS) > are NOT searched at all. >=20 > 2-1) Both UFS and ZFS has no /boot/loader.efi > -> Fail to boot. Fall back to boot1 prompt. > ZFS pool in Disk2 is shown before one in Disk1. >=20 > 2-2) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk2 ZFS > is copied to UFS. > -> head in Disk2 ZFS boots fine. >=20 > 2-3) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS > is copied to UFS. > -> stable/10 in Disk1 ZFS boots fine, as loader.efi loads > kernel from /boot/kernel/kernel in UFS and kernel with zfs.k= o > can mount root on ZFS specified by vfs.root.mountfrom. >=20 > 2-4) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS > is copied to UFS and its /boot/loader.efi is overwritten by > the one of head. > -> stable/10 in Disk1 ZFS boots fine. >=20 > 2-5) Disk1 ZFS only has /boot/loader.efi of stable/10 itself. > -> Fail to boot. Fall back to boot1 prompt. > ZFS pool in Disk2 is shown before one in Disk1. >=20 > 2-6) Disk1 ZFS only has /boot/loader.efi of head. > -> stable/10 in Disk1 ZFS boots fine. >=20 > 2-7) Both UFS and ZFS in Disk1 has /boot/loader.efi of head. > (Mix of 2-2 and 2-6) > -> stable/10 in Disk1 ZFS boots fine. >=20 > 2-8) UFS has /boot/loader.efi of head (head kernel copied), but ZFS > has /boot/loader.efi of stable/10 itself. (Mix of 2-2 and 2-5) > -> Same as 2-5. Fail to boot. Fall back to boot1 prompt. > ZFS pool in Disk2 is shown before one in Disk1. >=20 > Set 3: Disk2 is removed. (Disk1 only environment) >=20 > 3-1) ZFS only has /boot/loader.efi of head. > -> stable/10 in Disk1 ZFS boots fine. >=20 > 3-2) Same as 2-2 without Disk2. > -> Fail to boot. Fall back to loader prompt. > (Of course. Specified root device doesn't exists.) >=20 > 3-3) Same as 2-4 without Disk2. > -> stable/10 in Disk1 ZFS boots fine. >=20 > 3-4) Both UFS and ZFS have /boot/loader.efi of head. > -> stable/10 in Disk1 ZFS boots fine. >=20 >=20 > Regards. >=20 >=20 --=20 Allan Jude --x1HCUnBCk2hcfMs6OHUx1vhIPiG205Ow6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWpQkSAAoJEBmVNT4SmAt+ztAP/2O7qWtc1oOGA5J00jLDPqDT z1S7FiZ7mSMk8s6Gbl1UZ1YNDIxwPkOdojlCHO2jqxEK1o7Nty0dAE6rw7vABHPS HvxDIPNEKWK/pkMuIM5TM7vUCZzORLoVwJnZPElH9PL8YmsU5Xv9fNYoPpjYTgee SG5ptQjLbwE+3vrm1PG5e60IlLaL6gep9ZuKz28v8W4ZKYsfNt9ACjAk/17hsEsz VaiwvnA4TgsT+nEeq2oRKqwryK2PRvVQbQPzM9A3z4kPRWMcY7Ruz2DwlOgDwElA iEHnFqRUEECZCG0qeE0O+9Cuw/ZJyzTPRB7VFYlGrAdkVzrsDuvygfJ6nhlZLm8t NPFJkdJtNDUisY87GRw6PC0vqQBFz80jL4g9+S8BdJBCg9HyLFaRiaxjwsC9n53b 4wI//zDnWytJiNYvCSvU1fPwxqGs4LLOIolZpGXFbEwwpcKU6gcOZU/o6wYbJ7+F LFhuAs8PrR+43iY2gIeg1wvprJFajoUm9q+vR7HVYXHp13sglJx+78LXPT0wpztk aEuWglqu0CcX8zLggZDjU1Xbdw3MlVQqmeEYO9U8txIA+whu5jkEOAGascJ6ZWNO PcJvLdXtqGhKpAPrrC6vVQwTW1+8W6HT8bAaylYciGdYMczdnvo/I5R9sWlDBnw9 tIf8PwixRGr9j07t3x1H =6bFz -----END PGP SIGNATURE----- --x1HCUnBCk2hcfMs6OHUx1vhIPiG205Ow6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56A5090E.4080508>