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.
UDI snap ships the package, thus its data dir is part of the snap
subiquity snap does not.
This tries l-s-c data dir in the base system, outside of the snap
and gives up if the dir does not exits.
The following commmit:
ce146ab28 add .path to Raid so for_client(raid-with-partitions) works
introduced a (read only) path property for Raid objects, returning an
imaginary value to make for_client work with Raid objects. Later on, the
following commit:
8e658998e add "path" attributes to fs model objects that curtin now
provides a path for
introduced a (read/write) path attribute to all filesystem objects. For
Raid however, the property still takes precedence over the new attribute
of the same name, so doing raid.path = x is invalid (no setter) and
results in the following exception:
AttributeError: can't set attribute 'path'
Fixed by using a @property + @setter attribute for path. The getter
returns the actual path if it exists, otherwise returns the same
imaginary value as before.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Dan Bungert