On Fri, Jun 02, 2023 at 03:52:16PM +0200, Christian Brauner wrote: > On Fri, Jun 02, 2023 at 04:34:58PM +1000, Dave Chinner wrote: > > On Fri, Jun 02, 2023 at 12:27:14AM -0400, Theodore Ts'o wrote: > > > On Thu, Jun 01, 2023 at 06:23:35PM -0700, Darrick J. Wong wrote: > > There's an obvious solution: a newly provisioned filesystem needs to > > change the uuid at first mount. The only issue is the > > kernel/filesystem doesn't know when the first mount is. > > > > Darrick suggested "mount -o setuuid=xxxx" on #xfs earlier, but that > > requires changing userspace init stuff and, well, I hate single use > > case mount options like this. > > > > However, we have a golden image that every client image is cloned > > from. Say we set a special feature bit in that golden image that > > means "need UUID regeneration". Then on the first mount of the > > cloned image after provisioning, the filesystem sees the bit and > > automatically regenerates the UUID with needing any help from > > userspace at all. > > > > Problem solved, yes? We don't need userspace to change the uuid on > > first boot of the newly provisioned VM - the filesystem just makes > > it happen. > > systemd-repart implements the following logic currently: If the GPT > *partition* and *disk* UUIDs are 0 then it will generate new UUIDs > before the first mount. > > So for the *filesystem* UUID I think the golden image should either have > the UUID set to zero as well or to a special UUID. Either way, it would > mean the filesystem needs to generate a new UUID when it is mounted the > first time. > > If we do this then all filesystems that support this should use the same > value to indicate "generate new UUID". Ok, the main problem here is that all existing filesystem implementations don't consider a zero UUID special. If you do this on an existing kernel, it won't do anything and will not throw any errors. Now we have the problem that userspace infrastructure can't rely on the kernel telling it that it doesn't support the functionality it is relying on. i.e. we have a mounted filesystems and now userspace has to detect and handle the fact it still needs to change the filesystem UUID. Further, if this is not handled properly, every root filesystem having a zero or duplicate "special" UUID is a landmine for OS kernel upgrades to trip over. i.e. upgrade from old, unsupported to new supported kernel and the next boot regens the UUID unexpectedly and breaks anything relying on the old UUID. Hence the point of using a feature bit is that the kernel will refuse to mount the filesysetm if it does not understand the feature bit. This way we have a hard image deployment testing failure that people building and deploying images will notice. Hence they can configure the build scripts to use the correct "change uuid" mechanism with older OS releases and can take appropriate action when building "legacy OS" images. Yes, distros and vendors can backport the feature bit support if they want, and then deployment of up-to-date older OS releases will work with this new infrastructure correctly. But that is not guaranteed to happen, so we really need a hard failure for unsupported kernels. So, yeah, I really do think this needs to be driven by a filesystem feature bit, not retrospectively defining a special UUID value to trigger this upgrade behaviour... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
