From owner-freebsd-stable@freebsd.org Mon Oct 22 14:36:01 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB5DCFFE33E for ; Mon, 22 Oct 2018 14:36:01 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FD0B7CC21; Mon, 22 Oct 2018 14:36:01 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 32B7BF516; Mon, 22 Oct 2018 14:36:01 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Mon, 22 Oct 2018 14:35:59 +0000 From: Glen Barber To: Andriy Gapon Cc: Eugene Grosbein , FreeBSD stable Subject: Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2 Message-ID: <20181022143559.GG13668@FreeBSD.org> References: <8517429b-9e3b-2ea3-80a6-12fc92106252@grosbein.net> <6627d159-fd52-2d10-2d45-97fd02725adc@FreeBSD.org> <5BC9A2E4.9010306@grosbein.net> <6c2f8adb-c0e7-550b-8595-e7a4768d5157@FreeBSD.org> <20181022140304.GE13668@FreeBSD.org> <1d5236b8-0269-5dce-3f2e-e7b1910836c6@grosbein.net> <20181022141527.GF13668@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Uu2n37VG4rOBDVuR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 14:36:02 -0000 --Uu2n37VG4rOBDVuR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 rep= ort from local user. > >>>> > >>>> Glen, maybe that errata record should be deleted. The problem is rea= l 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. > >> > >> > >=20 > > 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? >=20 > This is just a typical foot-shooting (and a shortcoming of the kernel bui= ld > 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? >=20 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 --Uu2n37VG4rOBDVuR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAlvN4E8ACgkQAxRYpUeP 4pP0nQ/+P1teIIE73mnhsyS8OTWPSV8wiVVFLmNI7khecaF7R0C7mZxK6I+Rbge2 jzTNrY3OgLXod3roxECYMg73N4vvZpnosN4CTA2k54sfjrMmHZukkaq2M3XboYGr ozzVluuGnXS5RDzsCDvb+xWMJVW4fj+fa+81WguerXei0FEfzG4rGK60AjwayLEC kuZCPG/7+qnucwsUmS2vmM8pcFxYajjR8JkFqGEnA7FGE32TxCFCK5Fsg5/Uf8Gn fhfBJYgY4iHEV0AgkR4sFJL3vO4PmYdPdNY2UG9gQkvVeVhlPZTqovjTLSknjXIm Vp++YTgEclcPaLKrxJ9vmKP/uexaCjMVw8eitJaeGf3FmecnKNZq+f5mLwEpSWsP HQdAiXSWrYNwCjrPQRtKessICs5iK8z9zcgW1MU8lmkSJvKeWJ2TSsF+ee4+wpF4 Ki5y/c2p0Azd35nG3jOflc5NLcGsX/D8DduYC9hcjQi4+v2S0lHkhJAK9ox+OCve XJAONfmofeVqP6EF7fOlSIZrAIsaEH+5Ky1CZdt7Cuz2mtXY1JLHRmtzKusph/o/ CPmf0QTQU4VhUlj9qAaF482/x54pzn7s4F9LlOjONeYNhYxFO08se3URu984H0n4 LdIY5kNwPUw9ocT+xqyhaSKBpQl+yqZKftDmeeLWzdqZ4YayBE4= =Bpln -----END PGP SIGNATURE----- --Uu2n37VG4rOBDVuR--