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.

(In reply to Vojtech Trefny from comment #15)
> 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.

Honestly, I can't think of a scenario when this would be a problem. For existing installations,
which don't use GPT partition auto-discovery (more or less all existing installations), partition
GUIDs should not matter much. For new installations, where GPT partition auto-discovery IS supposed
to be used (when UKI is used instead of the standard kernel -- anaconda doesn't support that yet), 
I would not expect to see more than one set of discoverable partitions on the same disk, it makes no
sense. Going forward, Anaconda may refuse to do UKI based setup in case there's any ambiguity in
partitioning but this can certainly be sorted out later.

(In reply to Vitaly Kuznetsov from comment #16)
> I would not expect to see more than one set of discoverable partitions on
> the same disk, it makes no
> sense.

If we turn this feature on by default than we'll have two sets of discoverable partitions on the same disk every time someone decides to have two Fedora installations in dualboot. We can assume this won't happen very often, but it can happen and if the result is unbootable system, than we can't have this enabled by default. So my question is still the same -- what will happen if I have two root partitions on the same disk in this case?

(In reply to Vojtech Trefny from comment #17)
> (In reply to Vitaly Kuznetsov from comment #16)
> > I would not expect to see more than one set of discoverable partitions on
> > the same disk, it makes no sense.
> 
> If we turn this feature on by default than we'll have two sets of
> discoverable partitions on the same disk every time someone decides to have
> two Fedora installations in dualboot. We can assume this won't happen very
> often, but it can happen and if the result is unbootable system, than we
> can't have this enabled by default. So my question is still the same -- what
> will happen if I have two root partitions on the same disk in this case?

For the existing, standard kernel setup when you pass explicit "root=<UUID>" on the
command line nothing is going to change, it does not really matter if partition
GUIDs are "discoverable" or not. I don't see any risk to dual-booted systems here, 
things will keep working as usual even if you have multiple partition sets: partition
UUIDs are still unique, they're independent from GUIDs (types).

In case someone explicitly wants to use 'GPT autodiscovery' feature by not supplying "root=.."
on the kernel command line (and anaconda doesn't create such setups) he/she must be sure that 
the right root partition will be auto-discovered but this is a generic problem: if you have two
setups on the same drive and don't want to specify which one you want to boot, how would the
system decide what you want?

Ah, thanks for the explanation. So if I read this right: Systems installed by anaconda explicitly pick the place to boot, so there's no detection taking place. Using the new GUIDs won't change anything for such setups. And if someone modifies their system, they need to do it by hand, and know what they're doing, so they will know they have two Fedoras... likely... Is that correct?

Is there any other distro using this, or is Fedora the only consideration this far?

(In reply to Vladimír Slávik from comment #19)
> Ah, thanks for the explanation. So if I read this right: Systems installed
> by anaconda explicitly pick the place to boot, so there's no detection
> taking place. Using the new GUIDs won't change anything for such setups. And
> if someone modifies their system, they need to do it by hand, and know what
> they're doing, so they will know they have two Fedoras... likely... Is that
> correct?

Yes, it is. We may want to add an option to install UKI instead of a normal kernel 
image to Anaconda in the future and it would certainly make sense to add a check that
there's just one set of 'discoverable' partitions on the target disk but for now it's
all 'manual'.

For the reference, here's a kickstart which I use to create UKI-based Fedora image:
https://people.redhat.com/~vkuznets/Fedora-UKI-rh.ks

> 
> Is there any other distro using this, or is Fedora the only consideration
> this far?

AFAIK Ubuntu uses UKI for Azure CVM image too and thus they also rely on 'discoverable'
GUIDs but honestly I'm not sure if this has anything to do with Anaconda.

*** Bug 2160074 has been marked as a duplicate of this bug. ***

(In reply to Vitaly Kuznetsov from comment #18)
> (In reply to Vojtech Trefny from comment #17)
> > (In reply to Vitaly Kuznetsov from comment #16)
> > > I would not expect to see more than one set of discoverable partitions on
> > > the same disk, it makes no sense.
> > 
> > If we turn this feature on by default than we'll have two sets of
> > discoverable partitions on the same disk every time someone decides to have
> > two Fedora installations in dualboot. We can assume this won't happen very
> > often, but it can happen and if the result is unbootable system, than we
> > can't have this enabled by default. So my question is still the same -- what
> > will happen if I have two root partitions on the same disk in this case?
> 
> For the existing, standard kernel setup when you pass explicit "root=<UUID>"
> on the
> command line nothing is going to change, it does not really matter if
> partition
> GUIDs are "discoverable" or not. I don't see any risk to dual-booted systems
> here, 
> things will keep working as usual even if you have multiple partition sets:
> partition
> UUIDs are still unique, they're independent from GUIDs (types).

IOW it depends on what scenarios we want to protect against. Historically
all *default* installs by anaconda will have resilted in 'root=<UUID>' being set.
So setting GPT discoverable GUIDs won't break any default historicall Fedora/RHEL
installs.

We don't know what other OS distros have done, however, so there is a risk that
by installing new Fedora, we'll berak some other distro install on the same disk
that is relying on GPT discovery.

To protect against that scenario would require us to detect if any other
pre-existing partitions aside from the ESP are present and avoid enabling 
GPT discoverable partitions. 

This would, however, complicate life if we ever want to /rely/ on GPT discovery
in future, to stop setting "root=<UUID>", but maybe we can worry about that when
the time comes ?


> In case someone explicitly wants to use 'GPT autodiscovery' feature by not
> supplying "root=.."
> on the kernel command line (and anaconda doesn't create such setups) he/she
> must be sure that 
> the right root partition will be auto-discovered but this is a generic
> problem: if you have two
> setups on the same drive and don't want to specify which one you want to
> boot, how would the
> system decide what you want?

That's what a bootloader UI is for.

Amended https://github.com/rhinstaller/anaconda/pull/4974 to have also config.