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

[Andriy Gapon]

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