You'll need a VM with 2 disks to demonstrate:
- Configure Calamares to pick "none" as initial action on
the partition page (this is a safe choice),
- Enter partition page,
- No action is selected, and the next> button is greyed out.
- Click erase; notice next> is now available.
- Change devices, notice no action is selected, but next>
is still available. Clicking on it, though, does nothing.
When changing to "no action", update the next-button's
availability.
Avoid the extra indirection through the otherwise-unused
prettyGptType(const QString&), construct table of names
only on first call to avoid static-initialization order
(though that's not important here).
In particular, we need a separate Job class to set the label; this
is invoked after we formatted a partition, and when no other changes
to the partition have been requested in the Edit dialog.
The partition- and filesystem-label setting code was already there,
but not in the call to createNewPartition(); now we set the
FS label twice (once in the call, once afterwards)
When creating or editing a new formatted partition, allow
to set a filesystem label (16 chars maximum). Modify
the KPMHelpers to accept it as a new parameter. Partitions
created by default may get a meaningful label too.
FIXES#1604
(Admittedly, this fixes the problem only when there's Plasma Solid automount
present, and not any of the other kinds; but none of those have been reported
yet, and adding them into AutoMount.cpp is opaque to the rest of the
system)
- It shouldn't be necessary to explicitly .get() pointers for
logging, and it's convenient to know when a pointer is smart.
* no annotation means raw (e.g. @0x0)
* S means shared
* U means unique
- switch logging in job to VERBOSE because we don't want to be printing
pointers to the regular session log
- switch logging in test to VERBOSE to actually see the messages from the Job
- hook the test into the build
- factor out the flags-we-want from the flags-we-already-have
- the use of ->activeFlags() meant that the state on *disk* was
being compared with the flags-we-want; if a partition was re-edited,
then you couldn't change the flags back to the state-on-disk
(eg. enable a flag, then change your mind and disable it).
- set the flags before refreshing the partition, because the
refresh checks for EFI bootability and that needs the new flags,
not the old ones.
- remove the m_defaultFSType from PartitionLayout, because it is
set on construction -- which is too early, before the configuration
has been read.
- make the default FS explicit in the init() calls which pass in
a configuration; this needs support in the intermediate
PartitionCoreModule.
- the "simple" constructor for PartitionEntry left the FS type
set as the constructor left it -- which is Unknown by default.
This leads to install failures in systems that don't set a
special layout but just want a single / -- because the FS is
set to Unknown.
- massage the constructor and consumer of the code, push
Ext4 FS in the tests and use the configured default in production.