** Description changed: [Impact] Subiquity's keyboard autodetection relies on the pc105.tree file generated by console-setup at build time. It generated using keymapper's gen_keymap utility. A regression in keymapper causes gen_keymap to fail when encountering any of several valid keysyms, including: dead_kcaron dead_kogonek dead_kdoubleacute dead_kbreve dead_stroke dead_currency dead_belowcomma When such a failure occurs, the affected keymap is omitted from the generated pc105.tree file. As a result, the keyboard detection database shipped in noble onward (until stonking where it's fixed) is severely incomplete: On jammy, pc105.tree contains 39 keyboard maps. On noble, pc105.tree contains only 13 keyboard maps. Many layouts, including Swiss (ch), Norwegian (no) are therefore absent from the keyboard detection database. As a consequence, Subiquity's keyboard autodetection can no longer accurately identify a number of keyboards that were correctly recognized in previous Ubuntu releases. This regression currently affects the core24-based Subiquity (shipped in the 25.10 and 26.04 installers). The same issue will happen with core26-based Subiquity if left unfixed. Proposed fix ------------ Update keymapper to recognize the missing keysyms listed above when generating keyboard detection data. Then, rebuild console-setup. This will allow new Subiquity builds to correctly identify keyboard layouts that are currently missing from the detection database. [Test Plan] 1. Install the updated keymapper package. 2. Check that dead_kcaron, dead_kogonek, dead_kdoubleacute, dead_kbreve, dead_stroke, dead_currency, dead_belowcomma are all listed in /usr/share/misc/keymap.syms 3. Install the updated console-setup package. 4. Verify that the generated pc105.tree database contains significantly more layouts than the affected version (13 layouts): - $ grep '^MAP' /usr/share/console-setup/pc105.tree | wc -l + $ grep '^MAP' /usr/share/console-setup/pc105.tree | wc -l 5. Verify that layouts previously omitted from the database are present, for example: - $ grep '^MAP ch$' /usr/share/console-setup/pc105.tree - $ grep '^MAP no$' /usr/share/console-setup/pc105.tree + $ grep '^MAP ch$' /usr/share/console-setup/pc105.tree + $ grep '^MAP no$' /usr/share/console-setup/pc105.tree For noble only (Subiquity is core24-based) ------------------------------------------ * Rebuild subiquity with console-setup from proposed. - $ git clone https://github.com/canonical/subiquity - $ snapcraft pull --shell - $ sed -i 's/noble-backports/noble-backports noble-proposed/' /etc/apt/sources.list.d/ubuntu.sources - $ apt update - $ apt install console-setup -t noble-proposed - $ exit - $ snapcraft pack + $ git clone https://github.com/canonical/subiquity + $ snapcraft pull --shell + $ sed -i 's/noble-backports/noble-backports noble-proposed/' /etc/apt/sources.list.d/ubuntu.sources + $ apt update + $ apt install console-setup -t noble-proposed + $ exit + $ snapcraft pack * Download a resolute server daily ISO - $ sudo scripts/inject-subiquity-snap.sh <RESOLUTE-ISO> <SNAP> test.iso + $ sudo scripts/inject-subiquity-snap.sh <RESOLUTE-ISO> <SNAP> test.iso * Boot the updated ISO - $ scripts/kvm-test.py --install --iso test.iso + $ scripts/kvm-test.py --install --iso test.iso * Navigate to the keyboard selection screen, click on "Identify keyboard" and ensure the first question asked is more advanced than: - +-------------------------------------------+ - | Please press one of the following keys: q | - +-------------------------------------------+ - + +-------------------------------------------+ + | Please press one of the following keys: q | + +-------------------------------------------+ [Where problems could occur] + In theory, adding a single symbol to keymapper can change the decision + tree that keymapper generates. In other words, Subiquity (or any other + piece of software that leans on keymapper) could end up asking a + different set of questions to determine the layout of the keyboard. This + means people could be asked to type symbols that they were not asked to + type in the past, even if they are not new symbols. + [Other Info] - I've added questing to the SRU for completeness, to avoid package - downgrades when upgrading from 24.04 to 25.10. However, we won't ever - build Subiquity from questing and questing should reach EOL soon, so we - might consider dropping the SRU for questing. + Original description + -------------------- + I've added questing to the SRU for completeness, to avoid package downgrades when upgrading from 24.04 to 25.10. However, we won't ever build Subiquity from questing and questing should reach EOL soon, so we might consider dropping the SRU for questing. The keyboard detection in Ubuntu 26.04 wrongfully detects German instead of Switzerland. The whole process seems like a regression. Previously (24.04), I pressed shift + "*" and it instantly detected Swiss as keyboard layout. Now I am asked to press "q" and than "z" and it wrongfully detects German.
** Description changed: [Impact] Subiquity's keyboard autodetection relies on the pc105.tree file generated by console-setup at build time. It generated using keymapper's gen_keymap utility. A regression in keymapper causes gen_keymap to fail when encountering any of several valid keysyms, including: dead_kcaron dead_kogonek dead_kdoubleacute dead_kbreve dead_stroke dead_currency dead_belowcomma When such a failure occurs, the affected keymap is omitted from the generated pc105.tree file. As a result, the keyboard detection database shipped in noble onward (until stonking where it's fixed) is severely incomplete: On jammy, pc105.tree contains 39 keyboard maps. On noble, pc105.tree contains only 13 keyboard maps. Many layouts, including Swiss (ch), Norwegian (no) are therefore absent from the keyboard detection database. As a consequence, Subiquity's keyboard autodetection can no longer accurately identify a number of keyboards that were correctly recognized in previous Ubuntu releases. This regression currently affects the core24-based Subiquity (shipped in the 25.10 and 26.04 installers). The same issue will happen with core26-based Subiquity if left unfixed. Proposed fix ------------ Update keymapper to recognize the missing keysyms listed above when generating keyboard detection data. Then, rebuild console-setup. This will allow new Subiquity builds to correctly identify keyboard layouts that are currently missing from the detection database. [Test Plan] 1. Install the updated keymapper package. 2. Check that dead_kcaron, dead_kogonek, dead_kdoubleacute, dead_kbreve, dead_stroke, dead_currency, dead_belowcomma are all listed in /usr/share/misc/keymap.syms 3. Install the updated console-setup package. 4. Verify that the generated pc105.tree database contains significantly more layouts than the affected version (13 layouts): $ grep '^MAP' /usr/share/console-setup/pc105.tree | wc -l 5. Verify that layouts previously omitted from the database are present, for example: $ grep '^MAP ch$' /usr/share/console-setup/pc105.tree $ grep '^MAP no$' /usr/share/console-setup/pc105.tree For noble only (Subiquity is core24-based) ------------------------------------------ * Rebuild subiquity with console-setup from proposed. $ git clone https://github.com/canonical/subiquity $ snapcraft pull --shell $ sed -i 's/noble-backports/noble-backports noble-proposed/' /etc/apt/sources.list.d/ubuntu.sources $ apt update $ apt install console-setup -t noble-proposed $ exit $ snapcraft pack * Download a resolute server daily ISO $ sudo scripts/inject-subiquity-snap.sh <RESOLUTE-ISO> <SNAP> test.iso * Boot the updated ISO $ scripts/kvm-test.py --install --iso test.iso * Navigate to the keyboard selection screen, click on "Identify keyboard" and ensure the first question asked is more advanced than: +-------------------------------------------+ | Please press one of the following keys: q | +-------------------------------------------+ [Where problems could occur] In theory, adding a single symbol to keymapper can change the decision tree that keymapper generates. In other words, Subiquity (or any other piece of software that leans on keymapper) could end up asking a different set of questions to determine the layout of the keyboard. This means people could be asked to type symbols that they were not asked to type in the past, even if they are not new symbols. + Also, if we made a mistake in the symbols list of keymapper, it could + lead to Subiquity identifying one keyboard as another. That said, this + is already happening today and users still have the ability to select + the layout from a drop-down list. + [Other Info] Original description -------------------- I've added questing to the SRU for completeness, to avoid package downgrades when upgrading from 24.04 to 25.10. However, we won't ever build Subiquity from questing and questing should reach EOL soon, so we might consider dropping the SRU for questing. The keyboard detection in Ubuntu 26.04 wrongfully detects German instead of Switzerland. The whole process seems like a regression. Previously (24.04), I pressed shift + "*" and it instantly detected Swiss as keyboard layout. Now I am asked to press "q" and than "z" and it wrongfully detects German. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2152901 Title: [SRU] Subiquity's automatic keyboard detection regression: pc105.tree shrunk to only 13 layouts To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/2152901/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
