If an autoinstall storage config with the last lvm_partition
is set to use all remaining space in the volgroup (size: -1)
and it is not aligned with the lvm chunk size, lvcreate will
round it up, and that will not fit into the actual free size.
That might happen depending on the size used by the previous
(lvm) partitions (e.g., may use percentage) and size of disk.
Fix that by rounding it down to the LVM chunk size.
This passed 'make check' and 'make lint' with exit code 0.
LP: #1919053
Before:
Running command ['lvcreate', 'vg', '--name', 'lv-root', '--zero=y',
'--wipesignatures=y', '--size', '6435110912.0B'] with allowed return
codes [0] (capture=False)
Rounding up size to full physical extent <6.00 GiB
Volume group "vg" has insufficient free space (1534 extents): 1535
required.
An error occured handling 'lvm-lv-root': ProcessExecutionError -
Unexpected error while running command.
After:
Running command ['lvcreate', 'vg', '--name', 'lv-root', '--zero=y',
'--wipesignatures=y', '--size', '6434062336.0B'] with allowed return
codes [0] (capture=False)
Logical volume "lv-root" created.
Check:
$ python3 -q
>>> 6435110912 / (4*1024**2)
1534.25
>>> 6435110912 & ~(4*1024**2-1)
6434062336
>>> _ / (4*1024**2)
1534.0
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com>
This adds a way of serializing objects to lists, which makes the results
much less self-documenting but also much smaller. (I want to ship
keyboard data serialized with this code with the snap, but do not really
want to ship JSON data that is way bigger than it needs to be.)
The first of these scripts mashes the current branch's code over that of
a pre-existing subiquity snap.
The second uses the first to mash the current branch's code over the
subiquity snap from an ISO and then creates a new ISO with this new
snap.
It's all a bit terrifying but being able to get your changes into a
bootable ISO in about 30s is quite a large improvement on building the
snap from scratch.
Accidental schema updates are unintended, so enforce that. Schema
updates that don't break API are fine, we can handle that by manually
regenerating the schema at such time.
there were two issues: the client never set up translation based on the
initial setting and the server contined to strip ".UTF-8" off the $LANG
value so the client didn't find a matching value to highlight the
initial language correctly.
Michael Hudson-Doyle