- The EXPECT_FAIL value "Abort" stops the test (I wanted 'if this
unexpectedly passes, raise an error' -- should have read the
documentation more closely).
- Set the shell in the config object, not just in GS.
- add a status member so the different steps can show progress
as the user is created and configured. The progress values
are hard-coded guesses as to how much work is done for each step.
- while here, reduce the scope of the global storage variable
This is somewhat experimental and weird; the idea is that bool
arguments are a lot easier to understand if there are proper
names attached, rather than "true" and "false".
- os-proper may return an extra file after the device:
/dev/sda1:Ubuntu 19.10 (19.10):Ubuntu:linux
/dev/sdb1@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi
I think we had this (kind of) module a long time ago and it was
removed for over-complicating things; re-introduce one now that
KPMcore is used in 3 different places and all would benefit
from consistent API handling / defines.
- handle swapfiles when writing /etc/fstab in the target system
- special-case mountpoint
- since swapfiles are not a partition, take the setting out
of partitionChoices
- create the physical swapfile as well (there's no other place
where it would make sense)
This still won't help if there's one really huge file that takes
several seconds to write, but if there's a bunch of files together
that is less than a file_chunk_count but take more than a half-
second to write, update anyway
If there's thousands of files in a squashfs (e.g. 400000 like on
some ArcoLinux ISOs) then progress would be reported every
4000 files, which can take quite some time to write. Reduce
file_chunk_count to at most 500, so that progress is reported
more often even if that wouldn't lead to a visible change
in the percentage progress: instead we **do** get a change
in files-transferred numbers.
- The total weight is only needed by the UnpackOperation,
not by each entry.
- Use a chunk size of 107 so that the number-complete seems busy:
the whole larger-or-smaller chunk size doesn't really matter.
- The progress-report was missing the weight of the current
module, so would report way too low if weight > 1. This affects
ArcoLinux configurations where one entry is huge and one is a
single file, so weights 50 and 1 are appropriate.
When there are multiple entries, the overall weight of the
module is divided between the entries: currently each entry
takes an equal amount of space in the overall progress.
When there are multiple entries which take wildly different
amounts of time (e.g. a squash-fs and a single file) then
the progress overall looks weird: the squash-fs gets half
of this module's weight, and the single file does too.
With the new *weight* key for entries, that division can
be tweaked so that progress looks more "even".
