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.
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.
> 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.
Related: in case the root filesystem is btrfs the default subvolume should be set to the "root" subvolume.
This is actually a duplicate of bug 2178043, which has other discussion. Not sure which we want to keep more, to be honest.
*** This bug has been marked as a duplicate of bug 2178043 ***