Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2160074 - RFE: please consider using the GPT partition type IDs from the discoverable partitions spec
Summary: RFE: please consider using the GPT partition type IDs from the discoverable p...
Keywords:
Status: CLOSED DUPLICATE of bug 2178043
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1075288
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-01-11 13:36 UTC by Daniel Berrangé
Modified: 2023-10-17 14:21 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1075288
Environment:
Last Closed: 2023-10-17 14:21:43 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Daniel Berrangé 2023-01-11 13:36:50 UTC 
Cloning as the support for setting partition type IDs is now included in parted, pyparted and blivet. It is just a matter of deciding a usage strategy/policy in anaconda and enabling that.

+++ This bug was initially created as a clone of Bug #1075288 +++

systemd 211 and newer support the "discoverable partitions spec" for identifying simply by looking at a GPT partition table where to mount file systems. This has a couple of benefits, but the most interesting one I see is that container images can make sense of GPT disk images this way, and mount them properly. This closes a major gap regarding deployment of identical images on bare-metal and nspawn.

It would be great if Anaconda could follow the spec when it creates GPT disk labels:

http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/

As soon as Anaconda starts to use the suggested GPT partition type GUIDs for the partitions it creates we can boot them up directly with nspawn, and hopefully soon with libvirt-lxc, Anaconda hence becomes truly useful as a generic installer not only for physical machines but also for container images.

The changes necessary in Anaconda are relatively simple. Basically, what I'd like to see changed in Anaconda is the following:

1. Whenever Anaconda creates a partition that is mounted to the root directory (/) of the installed system please use GPT partition type 44479540-f297-41b2-9af7-d131d5f0458a on 32bit x86, and 4f68bce3-e8cd-4db1-96e7-fbcaf984b709 on 64bit x86-64. If LUKS is used for the root partition, please name the LUKS volume "root".

2. Whenever Anaconda creates a partition that is mounted to the home directory (/home) of the installed system please use GPT partition type 933ac7e1-2eb4-4f13-b844-0e14e2aef915. If LUKS is used for the home partition, please name the LUKS volume "home".

3. Whenever Anaconda creates a partition that is mounted to the server data directory (/srv) of the installed system please use GPT partition type 3b8f8425-20e0-4f3b-907f-1a25a76f98e8. If LUKS is used for the srv partition, please name the LUKS volume "srv".

4. Whenever Anaconda creates a swap partition, please use GPT partition type 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f (which is afaics already what Anaconda does).

Note that the partition types suggested in 1.-3. should only be used if the partition contains a simple file system like btrfs, ext2,3,4, xfs, ..., possibly encrypted with LUKS. It should not be used if LVM, mdraid or btrfs is used for the partition. 

For all other partitions use other GPT partitions. If they contain simple file systems they should probably carry the generic Linux GPT partition type 0fc63daf-8483-4772-8e79-3d69d8477de4. (And if they contain LVM or DMRAID, they should probably carry even other partition types).

Note that the last time I installed my system with Anaconda I noticed that it uses the Windows partition type by default for its data partition (which is probably parted's fault). This is definitely something to fix, and please consider fixing it by adopting this specification.

Anyway, would be great if you guys would consider adopting this simple scheme for the GPT partition tables generated by Anaconda! I think being able to use Anaconda for creating disk images that just work in the various container managers would be great.

Fore more information about all of this, also see https://plus.google.com/u/0/+LennartPoetteringTheOneAndOnly/posts/5p1QuhdFtjN

--- Additional comment from Lennart Poettering on 2014-03-12 13:54:28 GMT ---

Meh, I wanted to say:

"Note that the partition types suggested in 1.-3. should only be used if the partition contains a simple file system like btrfs, ext2,3,4, xfs, ..., possibly encrypted with LUKS. It should not be used if LVM, mdraid or btrfs *RAID* is used for the partition."

Simple single-volume btrfs should use the GPT type ids suggested here, just btrfs raid should not.
Comment 1 Daniel Berrangé 2023-01-11 13:48:57 UTC 
On the blivet side, discoverable partitions is exposed as an opt-in feature, to be enabled using
    
      from blivet.flags import flags
      flags.gpt_discoverable_partitions = True
    
if that is done, then any PartitionDevice() object instance receiving a 'mountpoint' will lookup the corresponding GPT type ID and use that.

Regardless of that flag it is also possible for callers to manually specify a GPT partition type ID to several methods.

My inclination is to initially just make anaconda set flags.gpt_discoverable_partitions, possibly based on an anaconda.conf option similar to the approach for the "multipath_friendly_names" flags/option handling. This should make standardized GPT partition type IDs be set based on the uapi group spec "out of the box". 

A question is whether there is unacceptable risk of regressions in doing that if people are relying on the traditional generic Linux partition type ID being set.

I'd also intend to extend pykickstart so it can accept a raw partition type ID for the 'part' command.
Comment 2 Gerd Hoffmann 2023-01-12 07:36:33 UTC 
> A question is whether there is unacceptable risk of regressions in doing
> that if people are relying on the traditional generic Linux partition type
> ID being set.

Data point:  I have several virtual machines with type being using
fdisk (or sfdisk in %post script).  I have not noticed any problems
so far.
Comment 3 Gerd Hoffmann 2023-10-12 13:16:19 UTC 
Related: in case the root filesystem is btrfs the default subvolume should be set to the "root" subvolume.
Comment 4 Vladimír Slávik 2023-10-17 13:58:13 UTC 
This is actually a duplicate of bug 2178043, which has other discussion. Not sure which we want to keep more, to be honest.
Comment 5 Vladimír Slávik 2023-10-17 14:21:43 UTC 

*** This bug has been marked as a duplicate of bug 2178043 ***
Note You need to log in before you can comment on or make changes to this bug.