As the sfdisk man page says on the option '--wipe' that
specifies whether or not to wipe signatures in order
to avoid collisions:
> When this option is not given, the default is auto,
> in which case signatures are wiped only when in interactive mode
but sfdisk is not run in interactive mode here, since
stdin does not refer to a terminal, and the sfdisk
man page says:
> It [i.e. sfdisk] runs in interactive mode if executed on terminal
> (stdin refers to a terminal).
Therefore, explicitly pass the '--wipe=always' option to
sfdisk so that old signatures are wiped when a new partition
table is created.
Bug: 431628
Move include of BLKID_INCLUDE_DIRS into scope it is used.
UUID_INCLUDE_DIRS is unused, left over from before partitionmanager
switched away from libuuid in 26e7f9d7ef306d61380e1c8965feb83bb6b07d18 .
Explicit Qt5Core_INCLUDE_DIRS no longer needed.
src/ is automatically available for kpmcore target, also exposed in
its build link interface.
That one uses std::is_constructible<impl, QObject *, const QVariantList &>
which will fail for our current plugin constructors due to being private
and with only friend class KPluginFactory.
We need this to avoid multiple authentication requests when applying
long operations.
Otherwise, the user will have to authenticate after each job,
which can mean up to 4 password dialogs for some longer operations.
In the old code QByteArray fstabContents was actually empty.
Also, writeData function was opening file in append mode,
thus nothing was actually written.
Split writeData function into two:
* one for block devices
* another for writing fstab file
BUG: 417205
The output of `sfdisk --json /dev/sdb` is not necessarily
valid JSON. Then, no partition information is stored,
no first-valid-lba in particular. This leads to new partitions
being made from sector 0, which is invalid on a GPT table.
The workaround is to manually fix the known-broken JSON
from sfdisk. This is amply documented in a standalone
static function.
FIXES#425097
The GPT type and attributes can be set since the commits 0529ebf (Add
support for setting the specific GPT type) and 0ffec31 (Add new job to
set the GPT partition attributes).
But these two data from existing partitions are not read and are missing
though.
This reads the GPT type and attributes data at scanning from the json
output, after the GPT name/label and uuid are read.
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.
Michael Weghorn
Andrius Štikonas
l10n daemon script
Friedrich W. H. Kossebau
Gaël PORTAY
David Edmundson
Adriaan de Groot