krpc: unbootable ZFS-on-root after major upgrade to 11.2

[Glen Barber]

On Mon, Oct 22, 2018 at 05:21:43PM +0300, Andriy Gapon wrote:
> On 22/10/2018 17:15, Glen Barber wrote:
> > On Mon, Oct 22, 2018 at 09:09:14PM +0700, Eugene Grosbein wrote:
> >> 22.10.2018 21:03, Glen Barber wrote:
> >>
> >> t's strange that this is a 10.x vs 11.x issue.
> >>>>> I see that zfs has the krpc dependency since r193128.
> >>>>> And the call to xdrmem_create is there since r168404.
> >>>>
> >>>> You are right. I was mis-informed and have not verified enough a report from local user.
> >>>>
> >>>> Glen, maybe that errata record should be deleted. The problem is real but it is long-standing
> >>>> and present in 10.x too.
> >>>>
> >>>
> >>> Could you elaborate more on the failure case you originally reported
> >>> first?  If the problem is real, my feeling is that the errata entry
> >>> should stay, just worded differently to reflect the failure case here.
> >>
> >> zfs.ko depends on krpc.ko. The KRPC code in compiled in GENERIC kernel as dependency
> >> of NFS client/server code. The problem arises if all of these are true:
> >>
> >> 1) a system uses custom kernel with NFS options removed;
> >> 2) there is no krpc.ko available due to MODULES_OVERRIDE excluding it;
> >> 3) the system boots off ZFS pool.
> >>
> >> In such case, loader cannot resolve dependency and fails to load zfs.ko
> >> and kernel fails to mount root breaking boot sequence.
> >>
> >>
> > 
> > So, if I understand correctly (and please correct me if I am wrong), the
> > majority of the text in the errata note is correct, however needs to be
> > tweaked to remove "upgrading from 10.x...".  Is this generally correct?
> 
> This is just a typical foot-shooting (and a shortcoming of the kernel build
> system that allows such foot-shooting to happen).
> I think that there can be other ways in which you can specify inconsistent
> kernel options and/or an incorrect subset of modules in MODULES_OVERRIDE to
> create missing dependencies for critical modules.
> Do we want to issue an errata for each possible misconfiguration?
> 

Not necessarily.  I think it is a matter of how common the edge case is,
for example.  I am perfectly fine removing the errata entry if this is
an extreme edge case.  Meaning, I think it would be excessive to
document the fallout from adding 'nodevice mem' to the configuration
file.

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20181022/c846fad9/attachment.sig>