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 1075288 - 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 RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: python-blivet
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vojtech Trefny
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1201814 2160074
TreeView+ depends on / blocked
 
Reported: 2014-03-12 02:10 UTC by Lennart Poettering
Modified: 2023-02-08 13:18 UTC (History)
12 users (show)

Fixed In Version: python-blivet-3.7.0-1.fc38
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1201814 2160074 (view as bug list)
Environment:
Last Closed: 2023-02-08 13:18:22 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Lennart Poettering 2014-03-12 02:10:16 UTC 
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
Comment 1 Vratislav Podzimek 2014-03-12 09:02:13 UTC 
All the changes described above look like a python-blivet changes to me. Reassigning.
Comment 2 Lennart Poettering 2014-03-12 13:54:28 UTC 
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 3 Brian Lane 2014-03-12 16:31:19 UTC 
Note that this is going to require upstream changes in parted and pyparted so we can set the partition GUID directly.
Comment 4 Lennart Poettering 2014-03-21 02:31:51 UTC 
Note that at least gdisk and Karel's libfdisk support arbitrary GUIDs directly.
Comment 5 Fedora Admin XMLRPC Client 2015-09-28 20:25:22 UTC 
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 6 Gerd Hoffmann 2022-06-30 16:35:52 UTC 
Ping.  What is the status here?

This has the potential to simplify the boot loader configuration alot,
specifically the initrd can find the root filesystem without needing
a machine-specific root=UUID=<id> on the kenel command line.
Comment 7 Daniel Berrangé 2022-09-23 14:44:44 UTC 
(In reply to Brian Lane from comment #3)
> Note that this is going to require upstream changes in parted and pyparted
> so we can set the partition GUID directly.

Fast forward 8 years, and parted 3.5 finally includes APIs for setting/getting the GPT partition GUID, and I've just proposed a pyparted binding at https://github.com/dcantrell/pyparted/pull/95

I'm going to explore upstream blivet code to see if I can learn enough about it to do something useful with this RFE.
Comment 8 Gerd Hoffmann 2022-12-20 10:06:04 UTC 
https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
Comment 9 Daniel Berrangé 2022-12-22 13:23:05 UTC 
(In reply to Daniel Berrangé from comment #7)
> (In reply to Brian Lane from comment #3)
> > Note that this is going to require upstream changes in parted and pyparted
> > so we can set the partition GUID directly.
> 
> Fast forward 8 years, and parted 3.5 finally includes APIs for
> setting/getting the GPT partition GUID, and I've just proposed a pyparted
> binding at https://github.com/dcantrell/pyparted/pull/95

This is merged

> I'm going to explore upstream blivet code to see if I can learn enough about
> it to do something useful with this RFE.

This is proposed as:

https://github.com/storaged-project/blivet/pull/1080
Comment 10 Daniel Berrangé 2023-01-10 17:24:29 UTC 
(In reply to Daniel Berrangé from comment #9)
> (In reply to Daniel Berrangé from comment #7)
> > I'm going to explore upstream blivet code to see if I can learn enough about
> > it to do something useful with this RFE.
> 
> This is proposed as:
> 
> https://github.com/storaged-project/blivet/pull/1080

This is now merged for the 3.7-devel branch of blivet

The next step is to figure out what we want from Anaconda wrt usage of discoverable partitions.
Comment 11 Vojtech Trefny 2023-01-24 10:57:08 UTC 
Thank you again for the patches Daniel, we plan to release blivet 3.7.0 in time for Fedora 38.
Note You need to log in before you can comment on or make changes to this bug.