Bug 2178043

FYI - pyparted support for the new parted UUID functions will need to be backported/rebased for this to work.

Also, I don't think we should be changing the default partition UUIDs in the middle of a release cycle. This seems like a change that should at least be optional, if not wait for the next major RHEL release.

(In reply to Brian Lane from comment #1)
> 
> Also, I don't think we should be changing the default partition UUIDs in the
> middle of a release cycle. This seems like a change that should at least be
> optional, if not wait for the next major RHEL release.

The change would only affect new setups, not existing ones so I was thinking 
it might still be OK to change the default. I may, however, underestimate the
importance of Partition GUIDs staying constant for some setups.

Providing an option in RHEL9 and making it the default in RHEL10 also sounds
like a very reasonable approach.

Hello, are you planning to backport Unified kernel support to RHEL-9? If not than I would focus on getting this upstream and RHEL-10 from there instead.

(In reply to Vitaly Kuznetsov from comment #2)

> The change would only affect new setups, not existing ones so I was thinking 
> it might still be OK to change the default. I may, however, underestimate the
> importance of Partition GUIDs staying constant for some setups.

I don't have any specific examples, but I'm sure there are people who do an install and then validate it using their own tools. It would be a surprising change to have the default UUIDs change without asking for it.

> 
> Providing an option in RHEL9 and making it the default in RHEL10 also sounds
> like a very reasonable approach.

I think that's the best approach.

(In reply to Jiri Konecny from comment #3)
> Hello, are you planning to backport Unified kernel support to RHEL-9? If not
> than I would focus on getting this upstream and RHEL-10 from there instead.

Yes, we already have it (TechPreview) in 9.2 https://bugzilla.redhat.com/show_bug.cgi?id=2142102

Note, there's no hard requirement on anaconda to support that at this moment, UKI
is only going to be used for Confidential VMs in clouds and these normally use
pre-generated images. For kickstart installs, Partition GUIDs can also be adjusted with
e.g. sfdisk when needed. This is more a 'nice to have' feature.

Brain, this functionality doesn't seem to be fully implemented upstream, the following UUIDs were created on a disk with GPT disk label (tested using Fedora rawhide):

[root@localhost ~]# lsblk -p -o NAME,PARTTYPE,mountpoint /dev/vda
NAME        PARTTYPE                             MOUNTPOINT
/dev/vda                                         
├─/dev/vda1 c12a7328-f81f-11d2-ba4b-00a0c93ec93b /boot/efi
├─/dev/vda2 0fc63daf-8483-4772-8e79-3d69d8477de4 /boot
├─/dev/vda3 0fc63daf-8483-4772-8e79-3d69d8477de4 /
└─/dev/vda4 0fc63daf-8483-4772-8e79-3d69d8477de4 /home
[root@localhost ~]#

Is anything missing in pyparted or any other component needs to be involved?


Vitaly, I agree with Brian that we should not change the current behavior in RHEL-9, and introduce this feature in RHEL-10. This bug should rather be tracked against Fedora to make sure it's fully implemented there first.

(In reply to Jan Stodola from comment #6)
> Brain, this functionality doesn't seem to be fully implemented upstream, the
> following UUIDs were created on a disk with GPT disk label (tested using
> Fedora rawhide):
> 
> [root@localhost ~]# lsblk -p -o NAME,PARTTYPE,mountpoint /dev/vda
> NAME        PARTTYPE                             MOUNTPOINT
> /dev/vda                                         
> ├─/dev/vda1 c12a7328-f81f-11d2-ba4b-00a0c93ec93b /boot/efi
> ├─/dev/vda2 0fc63daf-8483-4772-8e79-3d69d8477de4 /boot
> ├─/dev/vda3 0fc63daf-8483-4772-8e79-3d69d8477de4 /
> └─/dev/vda4 0fc63daf-8483-4772-8e79-3d69d8477de4 /home
> [root@localhost ~]#
> 
> Is anything missing in pyparted or any other component needs to be involved?

Depends on what you mean by fully implemented :) In rawhide you can set arbitrary UUIDs with parted by using the 'type' command. pyparted also supports this new libparted API. The default UUIDs have not changed though, that would need to be implemented by Blivet (and possibly Anaconda). So if you are just creating new partitions you will not see anything different.

By fully implemented I meant that the installer would automatically set the correct UUIDs for the partitions based on their mount points or usage (/boot, /, /home, /usr, swap,...) as described here: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/

So, I'm reassigning this bug to blivet for now, to be implemented in Fedora first.

Support for the discoverable partitions was added in blivet 3.7.0 which is available in Fedora 38 so if there isn't anything else needed, I think we can either close this as duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1075288 or move back to Anaconda.

OK, so moving back to anaconda to start using discoverable partitions.
Here is the relevant blivet PR: https://github.com/storaged-project/blivet/pull/1080

Hi Vojta, what is required from Anaconda to enable this?

You just need to set the `gpt_discoverable_partitions` flag to True, everything else will be automatic.

Here is a draft PR just to check it does what advertised. What interface do we use to make it optional? Since it's a single global flag in Blivet, it seems a poor match for anything in kickstart. I wonder if it should be a config option or a boot option?

https://github.com/rhinstaller/anaconda/pull/4974

On the one hand, making it configurable make sense but honestly I don't see why this shouldn't be the new default:
I don't see downsides from using this new GUIDs even in the autodiscovery feature is not going to be used. It may,
however, make sense to preserve the existing behavior in RHEL.

In case it's possible to set per-partition, I'd suggest to make it a 'part' flag, e.g. '--legacy-guid' but
looking at he pull request I think it's global. In that case it can be a 'bootloader' option I guess...

Can this be a problem with dualboot -- can we break booting of a preexisting installation that uses systemd boot if we suddenly add a new Fedora / partition with "root GUID"? If this isn't a problem, I think it could be default without a configuration option.