disk: drop static UUIDs in defs#1922
Conversation
mvo5
left a comment
There was a problem hiding this comment.
Removing this for fedora makes a lot of sense, I'm a bit hesitant for rhel, especially the older rhel releases.
What causes the hesitation? |
Nothing too specific, I remember we talked about it in the past (c.f. #816 and #823 and particularly #823 (comment)) and the history was that there was a bit of worry about older rhel and that people might depend on this. Fwiw, I have no strong opinion here, hardcoding the UUIDs is weird but given how long this is around its hard to know who might rely on it. |
Yea, very true. If we want to I can drop the commits for RHEL 7/8(/9?), let's see what the feeling is :) |
Drop the static UUIDs defined in the distro definitions. Note that the changes to the manifest checksums are only related to the PRNG now being called more often and thus having a different state from before. Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
Drop the static UUIDs defined in the distro definitions. Note that the changes to the manifest checksums are only related to the PRNG now being called more often and thus having a different state from before. This also updates a UUID used in a test since the state of the PRNG is different as it has generated *more UUIDs. Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
Drop the static UUIDs defined in the distro definitions. Note that the changes to the manifest checksums are only related to the PRNG now being called more often and thus having a different state from before. Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
Drop the static UUIDs defined in the distro definitions. Note that the changes to the manifest checksums are only related to the PRNG now being called more often and thus having a different state from before. Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
Drop the static UUIDs defined in the distro definitions. Note that the changes to the manifest checksums are only related to the PRNG now being called more often and thus having a different state from before. Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
achilleas-k
left a comment
There was a problem hiding this comment.
I'm in favour of dropping these. I don't think it's a problem to do in older RHEL distros either. One downside I can see is that sometimes when troubleshooting issues with images "in the wild", they were a good indicator of an image built using IB, but that's a silly reason to keep them. :)
If we want to do first-boot UUID initialisation, we can plan for that separately.
There were some left over UUIDs in the ARM Minimal partition table that were missed in [1]. Let's remove them here. [1]: #1922 Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
There were some left over UUIDs in the ARM Minimal partition table that were missed in [1]. Let's remove them here. [1]: osbuild#1922 Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
See osbuild#1922 - this commit does the same for bootc images.
See osbuild#1922 - this commit does the same for bootc images.
See osbuild#1922 - this commit does the same for bootc images.
See osbuild#1922 - this commit does the same for bootc images.
See osbuild#1922 - this commit does the same for bootc images.
See #1922 - this commit does the same for bootc images.
We have long had a comment in our YAML definitions to drop the UUIDs and have them be autogenerated. This PR does so.