Re: git: dae1713419a6 - main - zfs: merge openzfs/zfs@269b5dadc (master) into main

On Wed, Nov 17, 2021 at 12:59:44PM +0100, Marcin Wojtas wrote:
> Hi,
> 
> śr., 17 lis 2021 o 12:48 Emmanuel Vadot <manu@bidouilliste.com> napisał(a):
> >
> > On Wed, 17 Nov 2021 11:43:18 +0000
> > Tom Jones <thj@freebsd.org> wrote:
> >
> > > On Wed, Nov 17, 2021 at 10:24:11AM +0100, Marcin Wojtas wrote:
> > > > Hi,
> > > >
> > > > Thank you for the update.
> > > >
> > > > ?r., 17 lis 2021 o 10:09 Martin Matuska <mm@freebsd.org> napisa?(a):
> > > > >
> > > > > The branch main has been updated by mm:
> > > > >
> > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=dae1713419a669d4f6c7acddf81a21297c809741
> > > > >
> > > > > commit dae1713419a669d4f6c7acddf81a21297c809741
> > > > > Merge: b6cbbcae40b4 269b5dadcfd1
> > > > > Author:     Martin Matuska <mm@FreeBSD.org>
> > > > > AuthorDate: 2021-11-17 08:35:14 +0000
> > > > > Commit:     Martin Matuska <mm@FreeBSD.org>
> > > > > CommitDate: 2021-11-17 08:39:40 +0000
> > > > >
> > > > >     zfs: merge openzfs/zfs@269b5dadc (master) into main
> > > > >
> > > > >     Notable upstream pull request merges:
> > > > >       #12285 Introduce a tunable to exclude special class buffers from L2ARC
> > > > >       #12689 Check l2cache vdevs pending list inside the vdev_inuse()
> > > > >       #12735 Enable edonr in FreeBSD
> > > > >       #12743 FreeBSD: fix world build after de198f2
> > > > >       #12745 Restore dirty dnode detection logic
> > > > >
> > > > >     Obtained from:  OpenZFS
> > > > >     OpenZFS commit: 269b5dadcfd1d5732cf763dddcd46009a332eae4
> > > > >
> > > >
> > > > I have one question to make sure about the guidelines for future. I've
> > > > been using ZFS on my arm64 machine for a while (a HEAD snapshot from
> > > > ~July + custom newer kernels for development) - after trying the
> > > > vanilla kernel after Nov 10 OpenZFS update I could no longer access
> > > > the root partition (even after returning back to the kernel that had
> > > > previously worked).
> > > >
> > > > I repeated the same thing with Nov 4 snapshot:
> > > > - Install system with ZFS
> > > > - Try kernel binary with updated OpenZFS - lose access to root partition.
> > > >
> > > > Is such behavior expected? If yes, is it recommended for the ZFS case
> > > > to use kernel and the world only from the same baseline?
> > > >
> > > > Best regards,
> > > > Marcin
> > >
> > > I don't know if this is related, but I just updated from the 4th
> > > November snapshot to this commit and my zfs on root box can't mount
> > > root.
> > >
> > > Annoyingly I haven't time to debug right now.
> > >
> > > - Tom
> >
> >  I had this problem recently and didn't had much time to debug but what
> > I know is that it's related to recent addition of counter which adds
> > some SYSINIT. I think that something in the zfs code isn't setup
> > properly wrt order and breaks sometimes when SYSINIT are re-arranged by
> > a new compile.
> >  To confirm this just remove a few drivers from GENERIC that you don't
> > use (I've removed stuff like nfs* which adds a lot of SYSINITs) and
> > boot with debug.verbose_sysinit=1 to compare with a working kernel.
> 
> The problem observed in my setup is, that after booting the kernel
> from top of main, there is no such thing as "working kernel" any more,
> i.e. the damage seems to be permanent.
> 
> >  Also on my side typing '?' at mountroot listed the zfs pool so if it's
> > the same for you that might be the same problem as mine (of course
> > selecting the pool at mountroot didn't worked).
> 
> I tried all partitions listed with "?", but none worked. For the time
> being I had to reinstall the system with UFS.
> 

For anyone that tries to debug this issue, in my case I booted
kernel.old and everything was fine.

- Tom