Re: weird issue after -p8 update

Julien Cigar wrote:
> On Fri, Mar 18, 2022 at 09:15:40PM -0700, David Christensen wrote:
>> On 3/18/22 05:55, Julien Cigar wrote:
>>> Hello,
>>>
>>> I've updated an old HPE Microserver Gen8 from FreeBSD 13.0-p7 to 13.0-p8
>>> and since I'm unable to boot. I thought it was the bootcode but even
>>> after updating I'm getting this: https://pasteboard.co/WesqiS5Lrw56.png
>>>
>>> (this is classical non-uefi bios)
>>>
>>> any idea? I'm lost.
>>>
>>> Thanks,
>>> Julien
>>
>>
>> The BIOS sees 4 drives.
>>
>>
>> It looks like the FreeBSD bootloader (?) is having trouble reading the
>> drive(s) that contain the pool "zroot_jupiler" (is that supposed to be
>> "zroot_jupiter"?), which contains the / (root) and /boot filesystems (?).
> 
> yes it is supposed to be zroot_jupiler.
> 
>>
>>
>> I would boot a 13.0-R installer USB stick into a live system, start a root
>> shell, and try to determine if the disks, partitions, ZFS pools, etc., are
>> okay.  If you run a 'zpool import ...',  consider using the "altroot=..."
>> and "readonly=on" properties.
>>
> 
> I tried, zpool import -NR /foo zroot_jupiler works, no error, scrub
> works well too.
> 
> I finally reinstalled the machine and I think there is a serious issue
> with that latest -p8 ZFS updates as the machine is unbootable again
> (this is what I'm getting: https://gist.github.com/silenius/e7c14d639c058f2734e6ffc078a43646
> 
> any idea?

Seeing as how the previous thread on the list ("Use specific FreeBSD
patch version with poudriere") seems to report similar issue with -p8, I
was going to ask you to get this reported somewhere developers would be
looking (e.g. fs@ or stable@, not questions@), but then I noticed the
following commit that came in just now that might be related to your
problem:

The branch releng/13.0 has been updated by markj:

URL:
https://cgit.FreeBSD.org/src/commit/?id=b8ae329db949868b8275091da0844ffbff50c65a

commit b8ae329db949868b8275091da0844ffbff50c65a
Author:     Brian Behlendorf <behlendorf1@llnl.gov>
AuthorDate: 2021-11-11 00:14:32 +0000
Commit:     Mark Johnston <markj@FreeBSD.org>
CommitDate: 2022-03-20 14:10:36 +0000

    Restore dirty dnode detection logic

    In addition to flushing memory mapped regions when checking holes,
    commit de198f2d95 modified the dirty dnode detection logic to check
    the dn->dn_dirty_records instead of the dn->dn_dirty_link.  Relying
    on the dirty record has not be reliable, switch back to the previous
    method.

    Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
    Issue #11900
    Closes #12745
    (cherry picked from commit d7e640cf95f72deeca501d34afed59a0bc9d7940)

    Approved by:    so
    Security:       FreeBSD-EN-22:13.zfs

If it's not please use the lists I mentioned above to report this.