Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Jul 2020 14:48:28 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Peter Jeremy <peter@rulingia.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: svn commit: r362848 - in stable/12/sys: net netinet sys
Message-ID:  <20200719114828.GD44314@kib.kiev.ua>
In-Reply-To: <20200719112102.GA15535@server.rulingia.com>
References:  <202007011803.061I3cTs089322@repo.freebsd.org> <20200719112102.GA15535@server.rulingia.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 19, 2020 at 09:21:02PM +1000, Peter Jeremy wrote:
> I'm sending this to -stable, rather than the src groups because I
> don't believe the problem is the commit itself, rather the commit
> has uncovered a latent problem elsewhere.
> 
> On 2020-Jul-01 18:03:38 +0000, Michael Tuexen <tuexen@FreeBSD.org> wrote:
> >Author: tuexen
> >Date: Wed Jul  1 18:03:38 2020
> >New Revision: 362848
> >URL: https://svnweb.freebsd.org/changeset/base/362848
> >
> >Log:
> >  MFC r353480: Use event handler in SCTP
> 
> I have no idea how, but this update breaks booting amd64 for me (r362847
> works and this doesn't).  I have a custom kernel with ZFS but no SCTP so I
> have no real idea how this could break booting - presumably the
> eventhandler change has uncovered a bug somewhere else.
> 
> The symptoms are that I get:
> Mounting from zfs:zroot/ROOT/r363310 failed with error 6; retrying for 3 more seconds
> Mounting from zfs:zroot/ROOT/r363310 failed with error 6
> 
> (r363310 is where I was trying to update to and I didn't change the BE
> name as I was searching for the problem and error 6 is ENXIO).
> 
> I tried to reproduce the problem with GENERIC but it hangs after
> displaying the EFI framebuffer information (I've seen that before and
> suspect it is a loader problem but haven't dug into it).
> 
> Does anyone have any ideas?

Did you checked that the physical devices where your ZFS pool is located,
are detected, and that kernel messages for their drivers are as usual ?
Overall, is there anything strange in the verbose dmesg ?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200719114828.GD44314>