The GPT partition layout supports partition attributes.
The CLI sfdisk sets the partition attributes using the option
--part-attrs. See the examples below:
$ cat <<EOF | sfdisk disk.img
label: gpt
type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, size=64M
type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
EOF
(...)
$ sfdisk --part-attrs disk.img 1 RequiredPartition,NoBlockIOProtocol,LegacyBIOSBootable,48
(...)
$ sfdisk --part-attrs disk.img 2 60,61,62,63
(...)
$ sfdisk --dump disk.img
(...)
disk.img1 : start= 2048, size= 131072, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=BBE806BB-8567-A843-9FF5-9B6B35D2908E, attrs="RequiredPartition NoBlockIOProtocol LegacyBIOSBootable GUID:48"
disk.img2 : start= 133120, size= 1963999, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=7DB39F08-C138-664B-B38E-ED2DEB549AA6, attrs="GUID:60,61,62,63"
This commit introduces the new job set-partition-attributes that is used
in the new-operation to set the attributes of the partition. The job
uses the newly introduced method setPartitionAttributes that is
implemented by the sfdisk and dummy backends.
Note: This is a copypaste of what was done for GPT partition label in
commit f585f6c (Add new job to set the GPT partition label) and GPT
partition UUID in commit 1dde035 (Add new job to set the GPT partition
UUID).
Note: RequiredPartition, NoBlockIOProtocol, LegacyBIOSBootable are
key words for 0, 1 and 2.
The GPT UUID are generated by the backends automatically once a
partition is created.
This reads the UUID that was generated after the creation of a partition
and stores it back to the object Partition.
The GPT partition layout supports unique GUID partitions.
The CLI sfdisk sets the partition UUID using the option --part-uuid.
See the examples below:
$ cat <<EOF | sfdisk disk.img
label: gpt
type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, size=64M
type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
EOF
(...)
$ sfdisk --dump disk.img
(...)
disk.img1 : start= 2048, size= 131072, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=BBE806BB-8567-A843-9FF5-9B6B35D2908E
disk.img2 : start= 133120, size= 1963999, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=7DB39F08-C138-664B-B38E-ED2DEB549AA6
$ sfdisk --part-uuid disk.img 1 00000000^C000-0000-0000-000000000000
(...)
$ sfdisk --part-uuid disk.img 2 11111111-1111-1111-1111-111111111111
(...)
$ sfdisk --dump disk.img
(...)
disk.img1 : start= 2048, size= 131072, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=00000000-0000-0000-0000-000000000000
disk.img2 : start= 133120, size= 1963999, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=11111111-1111-1111-1111-111111111111
This commit introduces the new job set-partition-uuid that is used in
the new-operation to set the UUID of the partition. The job uses the
newly introduced method setPartitionUUID that is implemented by the
sfdisk and dummy backends.
Note: This is a copypaste of what was done for GTP partition label in
commit f585f6c (Add new job to set the GPT partition label).
The GPT partition layout supports naming partitions.
The support for the partition label was added in the backend libparted
since commit 28fa6ac (Add support for GTP partition labels).
The libparted was removed later by commit 8fa1814 (Remove libparted
backend) and no backend sets the partition label.
The CLI sfdisk sets the partition label using the option --part-label.
See the examples below:
$ cat <<EOF | sfdisk disk.img
label: gpt
type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, size=64M
type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
EOF
(...)
$ sfdisk --part-label disk.img 1 efi
(...)
$ sfdisk --part-label disk.img 2 rootfs
(...)
$ sfdisk --dump disk.img
(...)
disk.img1 : start= 2048, size= 131072, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=D08E5B2A-4649-9F4A-AEA3-6C3048888EAA, name="efi"
disk.img2 : start= 133120, size= 1963999, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=0BEEFE82-19EA-DC4C-BB6A-27B6DA0C3BD2, name="rootfs"
This commit introduces the new job set-partition-label that is used in
the new-operation to set the label of the partition. The job uses the
newly introduced method setPartitionLabel that is implemented by the
sfdisk and dummy backends.
The GPT partition layout defines the type of the partition using a
UUID[1]. The type of the partition is not related to the underlying
filesystem but to its functionality: rootfs, home, var, swap, esp...
The UUID 4f68bce3-e8cd-4db1-96e7-fbcaf984b709 defines the root partition
(/), the UUID 933ac7e1-2eb4-4f13-b844-0e14e2aef915 defines the home
partition (/home), the UUID 4d21b016-b534-45c2-a9fb-5c16e091fd2d defines
the variable partition (/var)... Also, the UUIDs may vary depending on
the architecture (x86, x86_64, arm or aarch64).
KPMcore guesses the type depending on the underlying filesystem.
This commit enables the setting of a more specific GPT type if it is
specified through the method Partition::setType(). It falls back to the
previous guess type if the type is left unset.
[1]: https://systemd.io/DISCOVERABLE_PARTITIONS/
setFlags function now takes additional argument const Partition& partition.
This allows us to completely remove CoreBackendPartition class.
Remove getPartitionBySector and getExtendedPartitions.
These functions were designed around libparted API and are not very convenient
with other backends.
Gaël PORTAY
Andrius Štikonas
Caio Carvalho