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. -- Brooks
signature.asc
Description: PGP signature
