When the URL of the security archive is unset, curtin will set it to the
URL of the primary archive.
This is not the behavior we want for Ubuntu installations. On amd64 (and
i386), the URL of the security archive should be set to
http://security.ubuntu.com/ubuntu
On other architectures, it should be set to
http://ports.ubuntu.com/ubuntu-ports
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
(cherry picked from commit 5556313652)
Mirror testing should focus on testing the primary mirror, not the
security archive - therefore we disable the -security suite.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
(cherry picked from commit 79f2c4c432)
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>
(cherry picked from commit cda6c54b87)
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>
(cherry picked from commit cd25ec454f)
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>
(cherry picked from commit 3bb74546e2)
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>
(cherry picked from commit aa6274c38e)
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.
(cherry picked from commit 2e67005403)
Future problem_report has a nice add_tags method, simulate it here.
Should be able to drop this with a core24 move.
(cherry picked from commit 232f2f9d8c)
When editing an encrypted VG that was created in the guided storage
screen, the VG information is originating from the server. However, the
server does not send the LUKS key over the wire. Instead it sends the
path to a keyfile which contains the key. The client may or may not have
read access to this keyfile so it does not have a reliable way to
determine the key.
This causes problem when editing the VG because the GUI expects to
receive a key when encryption is enabled.
If the VG object only contains a keyfile, the passphrase is set to None
and this result in the GUI crashing.
This patch fixes the crash by passing an empty passphrase instead of a
None value when the VG object only contains a keyfile.
This means the user gets forced to supply a passphrase again when
editing an encrypted VG that was created in the guided partition screen.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
(cherry picked from commit dcc66fa346)
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>
(cherry picked from commit 8298ec17c8)
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>
(cherry picked from commit 6aa9452bb0)
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>
(cherry picked from commit 938f2ffc24)
The XKB configuration guide shows that multi-layout configuration is
possible, as in the following example:
Option "XkbLayout" "us,cz,de"
Option "XkbVariant" ",bksl,"
which translates to:
* layout "us" with no variant
* layout "cz" with variant "bksl"
* layout "de" with no variant
The same applies to /etc/default/keyboard.
We do make use of this ability to automatically set an alternative
keyboard layout for non latin keyboard layouts (e.g., Arabic "ara"
becomes "us,ara" so that users can toggle between American and Arabic
keyboard layouts.
In the following commit:
13cae2488 keyboard: validate layout and variant
.. we started implementing early validation of the keyboard layout, but
we did not consider that multi-layouts are supported.
As a result, subiquity fails at keyboard selection when a non latin
keyboard layout is selected.
Fixed by making sure the validation expects possible multi-layout
setups.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
(cherry picked from commit a91dbfa004)
In ubuntu-desktop-installer/issues/1772, a user formatted an existing
partition as ext4, which triggered the ESP to be "mounted". Except this
mount step also formatted the ESP.
Previously, when we ran block probing, the restricted=False version
failed, which caused it to run a restricted=True probe. The
restricted=True probe looks at block devices, but does not gather
filesystem information. The esp "mount" check is also willing to format
the partition if it is unformatted. (We do not have a distinction
between a partition that is unformatted and one for which we have not
obtained filesystem information.)
This user had block probing restricted=False fail due to LP: #2012722,
where Ventoy was in use and we handled the device mapper entry poorly.
While recreating the failure case, simply retesting with a build with
the fix for LP: #2012722 is enough to avoid this problem. This is
because the restricted=False probe passes, which means filesystem info
is gathered, which means the mount step doesn't attempt to format it.
There will inevitably be other block probing failure cases for
restricted=False. restricted=True must not leave people so vulnerable
to a partition reformat.
Gather filesystem information during a restricted=True probe.
(cherry picked from commit c921192db3)
Move some of this logic to a common util, so it can be used in
unittests. The curtin version is close but expects to work on a storage
config, which is not a flat list.
Dan Bungert