On Wed, Nov 09, 2022 at 09:19:47PM +0100, Alexander Leidinger wrote:Quoting Mark Millard <mark...@yahoo.com> (from Wed, 9 Nov 2022 12:10:18 -0800):> On Nov 9, 2022, at 11:58, Alexander Leidinger > <alexan...@leidinger.net> wrote: > >> Quoting "Patrick M. Hausen" <p...@hausen.com> (from Wed, 9 Nov 2022 >> 20:49:37 +0100): >> >>> Hi, >>> >>>> Am 09.11.2022 um 20:45 schrieb Alexander Leidinger >>>> <alexan...@leidinger.net>: >>>> But "zpool set feature@edonr=enabled rpool" (or any other feature >>>> not in the list we talk about) would render it unbootable. >>> >>> Sorry, just to be sure. So an active change of e.g. checksum or >>> compression algorithm >>> might render the system unbootable but a zpool upgrade never will? >>> At least not intentionally? ;-) >> >> If you mean "zpool upgrade", then no (modulo bugs). OpenZFS uses >> the feature flags instead of zpool upgrade. > > I'm confused by that answer: See my correction in another mail, the behavior seems to have changed and yes, doing a zpool upgrade on a boot pool should not be done. Maybe someone wants to check or add provisions to not do that on a pool which has the bootfs property set.Literally the entire point of the script added in the commit this thread is about upgrade the boot pool on first boot so that seems like it would be counterproductive.
Something is missing here. Either some pointer to some safetynet for pools with the bootfs property set (or a similar "this is a bootable pool" flag), or a real-world test of the script.
Any brave soul around to spin up a test-VM and perform a "echo before; zpool get all rpool | grep feature; zpool upgrade rpool; echo after; zpool get all rpool | grep feature" inside?
Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
pgpbcaJMrp3Tk.pgp
Description: Digitale PGP-Signatur
