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>
When we create a swap partition using v2_add_partition, the mount
parameter always has the value of None.
We do however, create a fake mountpoint object and assign it the value
of "" (empty string) so we know the swap partition is used although it's
not really mounted anywhere in the filesystem hierarchy.
Subsequently, when editing the swap partition, the mount parameter is
set to the empty string, not None.
This causes trouble in the create_mount function, which normally returns
immediately upon encountering None as the mountpoint.
Fixed by skipping the call to create_mount for a swap partition.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Subiquity snap doesn't stage language-selector-common nor locales
packages.
Attempting to run those commands require respecting the env previously
prepared by the caller, as well as fixing the commands paths
(or changing the PATH env var in the env preparation step).
Since the apt commands were already ran with a fixed path,
I'm applying the same principle in here.
Yet, for now, Jammy doesn't ship the l-s-c package seeded,
so a condition was preserved to avoid future crashes.
When running autoinstalls, the source model will be marked configured
automatically after apply_autoinstall_config has run. The selected
source will be the one described in the autoinstall section or will
default to the legacy server entry: Ubuntu Server.
Doing an additional POST request can only make things inconsistent in
fully automated installs.
When the POST request is handled, most of the models may already have
applied their autoinstall configuration, and are already relying on the
previous source selected.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
If the source model changes, the mirror model gets a chance to apply a
new apt configuration. However, if this happens during an automated
install, this is a recipe to disaster.
Make sure we raise an exception if a POST request to /source occurs
after the mirror model has started applying its autoinstall
configuration.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When the source model changes, the mirror model gets notified and
replaces the "apt configurer" instance with a new one. If this happens
in the middle of a "deploy apt configuration + run apt-get update"
operation, this leads to an assertion error.
Fixed by making sure we do the entire operation on the same "apt
configurer" instance.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Dan Bungert