scripts/bind-patch.sh is useful for modifying the snap in the live
environment, for quickly testing changes or for things that are too
obscure to test in other ways.
Traceback (most recent call last):
File "subiquity/server/controllers/oem.py", line 161, in load_metapackages_list
self.model.metapackages = [
File "subiquity/server/controllers/oem.py", line 164, in <listcomp>
wants_oem_kernel=await self.wants_oem_kernel(
File "subiquity/server/controllers/oem.py", line 115, in wants_oem_kernel
flavor = line.split("=", maxsplit=1)[1].strip()
IndexError: list index out of range
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
- Add content from /documentation folder into Diataxis structure
- Change all content from .md to .rst
- Add some tutorial content from Server docs
- Move introduction to top-level navigation to make it easier
to find
- Update README.md with instructions for building local docs
1. adjust the RP to use a different casper uuid, to avoid confusing when
install media is still present
2. record the partuuid of the RP on the kernel command line when booted
from there so subiquity knows to add a grub boot entry pointing to it
in this case
3. fix generating the grub boot entry pointing to the RP as this was
broken in a few ways
4. get the logic the right way around to only set BootNext in
reset-partition-only case
Currently, the partition form stores the size as a human readable value.
(e.g., 123456K, 1.1G, 1.876G, 100G). When we exit the size field (i.e., upon
losing focus), we convert the value to a number of bytes and then align
it up to the nearest MiB (or whatever the alignment requirement is).
Unfortunately, after computing the aligned value, we turn it back into a
human-readable string and store it as is. It is not okay because the
conversion does not ensure that the alignment requirement is still
honored.
For instance, if the user types in 1.1G, we do the following:
* convert it to a number of bytes -> 1181116006.4 (surprise, it is not
even an integer).
* round it up to the nearest MiB -> 1181745152 (this is the correct
value)
* transform it into a human readable string and store it as is -> 1.1G
- which actually corresponds to the original value.
This leads to an exception later when creating the partition:
File "subiquity/models/filesystem.py", line 1841, in add_partition
raise Exception(
Exception: ('size %s or offset %s not aligned to %s', 1181116006, 1048576, 1048576)
Fixed by storing the actual size as a number of bytes - alongside the
human readable size.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>