Andriy Gapon
2018-Oct-22 14:21 UTC
krpc: unbootable ZFS-on-root after major upgrade to 11.2
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
Eugene Grosbein
2018-Oct-22 14:32 UTC
krpc: unbootable ZFS-on-root after major upgrade to 11.2
22.10.2018 21:21, Andriy Gapon wrote:>>>>> 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?Yes.> 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?OTOH, we have option krpc in sys/conf/options but it is not mentioned elsewhere: not in the Handbook nor in the sys/conf/NOTES or GENERIC. Not a bit of our documentation mentions that ZFS requires KRPC for last 10 years. One can call it foot-shooting if it is against documentation but that's not the case.
Glen Barber
2018-Oct-22 14:35 UTC
krpc: unbootable ZFS-on-root after major upgrade to 11.2
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>