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.