I made regular update of my 14-CURRENT amd64 system from main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in boot hangup as following. https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png If I restore previous loader file (that is, loader.efi of main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then system boots successfully.
According the result of bisect the problem happens with base c32dde31669 and later.
Created attachment 235907 [details] Photograph: main-n257332-3179bb273749 with GELI encryption Somewhat different from (a) <https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png> (comment #0) and (b) Stefan Eßer's photograph at <http://markmail.org/message/hnxmw74vcorwph6h>: > … > Attempt to find boot zone recovery data: failed > Attempted recovery for standard superblock: failed > Attempted extraction of recovery data from standard superblock: failed > … – and so on. GELI encryption. From after the subsequent successful boot: % lsblk DEVICE MAJ:MIN SIZE TYPE LABEL MOUNT ada0 0:119 932G GPT - - ada0p1 0:121 260M efi gpt/efiboot0 - <FREE> -:- 1.0M - - - ada0p2 0:123 16G freebsd-swap gpt/swap0 SWAP ada0p2.eli 2:40 16G freebsd-swap - SWAP ada0p3 0:125 915G freebsd-zfs gpt/zfs0 <ZFS> ada0p3.eli 0:132 915G - - - <FREE> -:- 708K - - - da0 0:148 14G GPT - - <FREE> -:- 1.0M - - - da0p1 0:149 14G freebsd-zfs gpt/cache3-august <ZFS> <FREE> -:- 1.0M - - - da1 0:191 466G GPT - - <FREE> -:- 1.0M - - - da1p1 0:192 466G freebsd-zfs gpt/Transcend <ZFS> da2 0:193 29G GPT - - <FREE> -:- 1.0M - - - da2p1 0:197 29G freebsd-zfs gpt/cache-august <ZFS> da3 0:204 14G GPT - - <FREE> -:- 1.0M - - - da3p1 0:205 14G freebsd-zfs gpt/cache2-august <ZFS> <FREE> -:- 1.0M - - - % date ; uname -aKU Sun 14 Aug 2022 16:16:29 BST FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #18 main-n257332-3179bb273749: Sun Aug 14 09:01:52 BST 2022 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400065 1400065 % That is, <https://cgit.freebsd.org/src/log/?qt=range&q=3179bb273749> from around twenty hours ago. (I set aside a copy of a working bootx64.efi before producing this.)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=d98de7440507aea1648c8f4bc302bf88c0eb9458 commit d98de7440507aea1648c8f4bc302bf88c0eb9458 Author: Toomas Soome <tsoome@FreeBSD.org> AuthorDate: 2022-08-14 21:49:50 +0000 Commit: Toomas Soome <tsoome@FreeBSD.org> CommitDate: 2022-08-15 18:07:23 +0000 loader: zfs reader should only store devdesc in f_devdata Use d_opendata for device specific data. PR: 265825 Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D36202 stand/libsa/zfs/zfs.c | 30 +++++++++++++----------------- 1 file changed, 13 insertions(+), 17 deletions(-)
I took following steps. 1. Check out base d98de7440507aea1648c8f4bc302bf88c0eb9458. 2. cd /usr/src/stand 3. make 4. make install 5. install -m 755 -p /bool/loader.efi /bool/efi/efi/freebsd 6. shutdown -r now Then system boots successfully. But while efi loader is working a lot of messages are displayed as following. https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-loader-message.png
(In reply to Yasuhiro Kimura from comment #4) > … messages are displayed as following. > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64.20220816.efi-loader-message.png At a glance, the same three lines (repeatedly) as were seen in the attachment at comment 2: > … > Attempt to find boot zone recovery data: failed > Attempted recovery for standard superblock: failed > Attempted extraction of recovery data from standard superblock: failed > …
<http://markmail.org/message/k7dtsw5dcg7skhud> imp@ wrote: > Would you be able to share camcontrol devlist output? Privately if need be. > And have any of these disks ever held ufs filesystems?? > > Warner % camcontrol devlist <HGST HTS721010A9E630 JB0OA3T0> at scbus0 target 0 lun 0 (ada0,pass0) <AHCI SGPIO Enclosure 2.00 0001> at scbus2 target 0 lun 0 (ses0,pass1) <Kingston DataTraveler 3.0 > at scbus3 target 0 lun 0 (da0,pass2) <Kingston DataTraveler 3.0 PMAP> at scbus4 target 0 lun 0 (da1,pass3) <Kingston DataTraveler 3.0 1.00> at scbus5 target 0 lun 0 (da2,pass4) % Comment 2 includes output from lsblk. If I recall correctly: ada0 originated from a ZFS send-and-receive, when I migrated from one HDD to another (larger) HDD, so the answer to the UFS question is probably "No".
After updating to base 97be6fced7d loader.efi works fine without extra messages.
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=03c44354fc9e82f89d6e323d5f20ab953854812d commit 03c44354fc9e82f89d6e323d5f20ab953854812d Author: Toomas Soome <tsoome@FreeBSD.org> AuthorDate: 2022-08-14 21:49:50 +0000 Commit: Warner Losh <imp@FreeBSD.org> CommitDate: 2023-01-24 21:49:32 +0000 loader: zfs reader should only store devdesc in f_devdata Use d_opendata for device specific data. PR: 265825 Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D36202 (cherry picked from commit d98de7440507aea1648c8f4bc302bf88c0eb9458) stand/libsa/zfs/zfs.c | 30 +++++++++++++----------------- 1 file changed, 13 insertions(+), 17 deletions(-)