curtin_install before this assembled a list of steps and then executed
them one by one. As far as I can tell/remember (I was at least partly
responsible for this) there is no reason to do it this way: it feels
more Pythonic to just execute the steps!
This required removing some indirection in how the config for each step
was constructed, which I think also makes things a bit clearer.
For a dictionary, the type hint should be dict[key_type, value_type] as
opposed to dict[key_type: value_type].
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
A new job now runs on PRs. It will automatically run mypy on the target
branch and on the source branch. It will generate a diff of the errors,
showing the new ones and showing the ones that have been fixed.
It will also show a summary with the number of errors before/after the
PR.
Because we have so many false positive, it makes no sense to mark this
job red. So we always make it green (unless mypy can't run).
As for now, it's up to developers to go check if any new error is
introduced.
If a line that used to produce a mypy error gets moved, it will be
reported as:
* a fixed error
* a newly introduced error
This is suboptimal and ideally we should have a way to detect moves.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
bind_mount_tree really wants to mount to places that don't exist yet,
and to unmount them later. Simply creating these files or directories
gets weird. Manage this process in the Mounter, so that any of these
temporary mountpoints get cleaned up on unmount.
Given disk layout like so
[p1 g1 p2 p3 g2]
The code attempting to create p4 used the largest_gap() method to
attempt to select g2. If the disk was small enough, below 28GiB with
current numbers, g1 would actually be larger, but the sizing math was
done with the offset that was correct for g2, so p4 would be created
a very incorrect size (-800MiB or so).
Just select gap by offset - we have the info needed.
By default, curthooks will automatically reorder the UEFI boot entries
so that the media used during installation is set as the first boot
entry.
This is something that MAAS wants because MAAS typically boots over the
network.
This is not typically something we would want for a server or desktop
installer though. Most of the time, the media is a removable device.
Ideally, we would want the new installed grub to be the first boot
entry.
Furthermore, on some UEFI implementations, the BootCurrent does not
correspond to a Boot#### entry when booting from a removable media. When
this happens, curtin fails at making the media the first boot entry,
resulting in the following error:
Invalid BootOrder order entry valueXXXX
^
efibootmgr: entry XXXX does not exist
Fixed by disabling the UEFI boot entries reordering when invoking
curthooks.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Some people who installed a previous version of Ubuntu on a DOS
partition table ended up with a logical, ESP partition (which is marked
bootable).
This is an unsupported use-case. An ESP partition should always be a
primary partition. Ideally, an ESP partition should be on a GPT.
However, curtin's storage_config makes it clear that expecting the flag
of a logical partition to be set to 'logical' is a bad idea.
# if the boot flag is set, use this as the flag, logical
# flag is not required as we can determine logical via
# partition number
Other people want to create a swap partition in an extended partition.
This is a perfectly valid use-case and we set flag='swap' for those
partitions.
Therefore, in subiquity code, we cannot just check if a partition has a
flag set to 'logical'. We need to look at the partition number too.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
If a probert run finished in the middle of partitioning, the probing
data would be loaded automatically and this would essentially discard
changes made so far by the user. This is not a desirable behavior.
Upon starting partitioning, we now prevent later probert runs from
automatically loading the probe data. Instead, the data is stored and
only loaded after after a reset.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
For mirror testing, we run apt-get update on the host. By default,
external commands run by subiquity inherit the environment variables set
by the snap (including LD_LIBRARY_PATH).
We don't ship apt-get or its dependencies in the subiquity snap, so we
want to reset LD_LIBRARY_PATH and other variables when running the
command.
Not doing so leads to the following error when running the subiquity
snap on a focal-based system:
* apt-get: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not
found (required by /snap/subiquity/4675/usr/lib/x86_64-linux-gnu/libsystemd.so.0)
* apt-get: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not
found (required by /snap/subiquity/4675/usr/lib/x86_64-linux-gnu/libsystemd.so.0)
* apt-get: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not
found (required by /snap/subiquity/4675/usr/lib/x86_64-linux-gnu/libsystemd.so.0)
* apt-get: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not
found (required by /snap/core22/current/lib/x86_64-linux-gnu/libcap.so.2)
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>