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>
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>
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.
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.
LD_LIBRARY_PATH is set earlier than some of the other environment
variables like PATH or PYTHONPATH, so trying to save a clean version in
snapcraft is not viable. Remove it here.
Dan Bungert