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

Andriy Gapon avg at
Mon Oct 22 14:29:46 UTC 2018

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?

Andriy Gapon

More information about the freebsd-stable mailing list