Date: Mon, 24 Aug 2020 19:31:50 +1000 From: Peter Jeremy <peter@rulingia.com> To: freebsd-stable@freebsd.org Subject: Re: svn commit: r362848 - in stable/12/sys: net netinet sys Message-ID: <20200824093150.GA66115@server.rulingia.com> In-Reply-To: <20200719112102.GA15535@server.rulingia.com> References: <202007011803.061I3cTs089322@repo.freebsd.org> <20200719112102.GA15535@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable TL;DR: Ensure you explicitly destroy all ZFS labels on disused root pools. On 2020-Jul-19 21:21:02 +1000, Peter Jeremy <peter@server.rulingia.com> wro= te: >I'm sending this to -stable, rather than the src groups because I >don't believe the problem is the commit itself, rather the commit >has uncovered a latent problem elsewhere. > >On 2020-Jul-01 18:03:38 +0000, Michael Tuexen <tuexen@FreeBSD.org> wrote: >>Author: tuexen >>Date: Wed Jul 1 18:03:38 2020 >>New Revision: 362848 >>URL: https://svnweb.freebsd.org/changeset/base/362848 >> >>Log: >> MFC r353480: Use event handler in SCTP > >I have no idea how, but this update breaks booting amd64 for me (r362847 >works and this doesn't). I have a custom kernel with ZFS but no SCTP so I >have no real idea how this could break booting - presumably the >eventhandler change has uncovered a bug somewhere else. To close the loop on this, the problem was a combination of: * changes in GEOM provider ordering; * insufficient checks when ZFS is looking for the root pool; * my system having remnants of a disused pool with the same name as the roo= t poop. It seems that the order of GEOM providers is relatively unstable - even including a device, that doesn't physically exist, in a kernel can change the provider order. Presumably r362848 also resulted in a change in order. During a root-on-ZFS boot, the kernel scans all providers, looking for ZFS labels with a pool name matching the root pool. Only minimal checks are performed, in particular, there's no check that it's a valid pool, and the first such label found is assumed to describe the root pool. In my case, some time ago, I'd moved things around on my boot disk. My old root pool went to the end of the physical disk but I'd decided to shrink it and left some free space at the end of the disk. This meant that ZFS found one (out of 4) labels when it tasted the physical disk and if GEOM sorted the physical disk prior to its partitions then ZFS would use the pool GUIDs =66rom the stray label on the physical disk and then fail to find a usable pool matching those GUIDs. My fix was to zero the end of my disk. --=20 Peter Jeremy --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE2M6l8vfIeOACl4uUHZIUommfjLIFAl9DiPxfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQ4 Q0VBNUYyRjdDODc4RTAwMjk3OEI5NDFEOTIxNEEyNjk5RjhDQjIACgkQHZIUommf jLK1IA/+OGhdGUPxr0Mg81frybtekzDHYfAZ5IUfRuo8T3MQzQYLMBvaRLMxVq/Y y+dl0cPF5kmDBCa7E5tTBgKz8sRGgNUhAKXgjLSQekEPi5TEErDfThfrZ/FMymHV FUh2CFnMIrc/ZCq7CnTcUamw09KVnfzDkVBoqEA+jqH+p9LtJwPWH7tn+HIodAWn blYbF9/epqokOELzeCesj6yRt8hpKRBrycNq5nwLrrJo7UufPpN14aiWdkzbWlcq P3ulA1pQB4Mj6gCXkY8EyzkJ5QLlqXlNNos6A/uLMgGB1Cyrma2Sd2fU98hfEGEl t6cLbZCUyaJStWSW0xgweUStUjcwCZANUenUcE9vV0uugkf0yvU5GLl7JBeEXUNq fQ2CW29RZH9JDDiiu0QtxP/CzV2GTShTbYvw/iCkGGLiHqIPE8zBISaHawsgqn3Z w026Vwbnfms3r2KbalzxH5lTufuIxdwtyPAfD/gEzA3Dd43z2TbmfZfIXpd0dfSs mU/NW9QG+Vk2QSp3CYWKBVt8CEwBrRb84e8oivH1+ixXGtGsthKBmWYne4qia7vh m1StEgRsInrhkgaGcEYVwFf0t+7iur5eCYVk9MrNvT+5Nr3slmyoLhDsx/8u+5Oh jLhkpPNObBb9YIuuHLC1LUyqU2ovkd0LOaqk2cLg+AqJnUef5qo= =gn3Y -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200824093150.GA66115>