+++ 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 09:54:28 EDT ---

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.

--- Additional comment from bcl on 2014-03-12 12:31:19 EDT ---

Note that this is going to require upstream changes in parted and pyparted so we can set the partition GUID directly.

--- Additional comment from Lennart Poettering on 2014-03-20 22:31:51 EDT ---

Note that at least gdisk and Karel's libfdisk support arbitrary GUIDs directly.