rhel10: drop hardcoded UUIDs from {centos,rhel}-10, fedora #823
Conversation
Historically the rhel/centos image defintion hardcoded the partition table, partition and filesystem UUIDs. The exact reasons for this is unclear and it seems it was done mostly for comaptibility with the previous generation of image build tools. However given that a UUIDs is meant to be (practically) unique from rhel10 on we stop hardcoding them. The images library will then create a random one for each image build. For the cases where this is undesirable the `OSBUILD_TESTING_RNG_SEED` env can be used to control the RNG.
Similar to the change in the previous commit for centos10/rhel10 the hardcoding of the UUIDs is also dropped on fedora. Ideally we would only do it for fedora-41 or later but the library is not split this way yet and just introducing a new factory for fc41 seems overkill (but I'm happy to do it if others feel it's worth it).
|
The messy thing here is I think it's actually a best practice to do what Fedora CoreOS derivatives have been doing for a while (and what systemd-repart encourages too), which is to regenerate the filesystem UUIDs on firstboot to avoid "UUIDs" actually being the same across multiple VMs instantiated from the single generated disk image. That's...more difficult to do if the UUIDs are actually random in each disk image as it's harder to know (without using out of band metadata) that they need regeneration. FCOS has hardcoded "UUIDs" today, but I think it would make sense to use zero. BTW...there's an "ignition-vs-cloud-init" thing going on here because a lot of cloud VMs use ext4, and historically ext4 didn't allow changing the UUID when the filesystem was already mounted...and cloud-init only runs in the real root. (Actually I may have it backwards and ext4 supports it but other FS's don't). |
|
Thanks for the feedback @cgwalters - you raise a very good point here that this maybe only solving half-of-the problem and by doing that actually making it worse. I will look into what we can do, it might involve getting by-in to be able to run systemd-repart. |
There was a problem hiding this comment.
I think this is good to merge now.
Let's follow it up with a systemd-repart configuration and zeroes like Colin suggested.
For that though I'd talk to other teams (for RHEL), because it might be a pretty significant change for cloud images and expectations around marketplace and golden images.
|
This PR is stale because it has been open 30 days with no activity. Remove "Stale" label or comment or this will be closed in 7 days. |
|
This PR is stale because it has been open 30 days with no activity. Remove "Stale" label or comment or this will be closed in 7 days. |
|
This PR is stale because it has been open 30 days with no activity. Remove "Stale" label or comment or this will be closed in 7 days. |
rhel10: drop hardcoded UUIDs from {centos,rhel}-10
Historically the rhel/centos image defintion hardcoded the partition
table, partition and filesystem UUIDs. The exact reasons for this
is unclear and it seems it was done mostly for comaptibility with
the previous generation of image build tools.
However given that a UUIDs is meant to be (practically) unique
from rhel10 on we stop hardcoding them. The images library will
then create a random one for each image build. For the cases
where this is undesirable the
OSBUILD_TESTING_RNG_SEEDenvcan be used to control the RNG.
fedora: drop hardcoded UUIDs for partitions/filesystems
Similar to the change in the previous commit for centos10/rhel10
the hardcoding of the UUIDs is also dropped on fedora.
This is the result of the discussion in #816