Anaconda cannot control the keyboard layout in the GNOME Shell session of the Fedora Workstation Live ISO. Originally, the plan was to use GNOME Initial Setup (GIS) for language and keyboard selection before Anaconda starts. However, patches enabling this functionality were removed during a rebase [3], and while a bug exists to restore them (rhbz#2308654 [0]), it is not likely that they will be back in time for Fedora 42. To mitigate this, we implemented in Web UI a Welcome screen for language selection, and we also added keyboard selection (PR #561 [1]). Unfortunately, this newly implemented feature does not work in the Workstation Live ISO because Anaconda cannot control the GNOME Shell keyboard layout in the Live session. Fixing this requires changes outlined in rhbz#2346830 [2] to grant Anaconda control over keyboard layouts. Also, additional backend work in Anaconda is needed for proper integration. Additional Context: Anaconda has long been unable to control GNOME Shell keyboard layouts in the Live environment. We are migrating to localed for consistent keyboard management (Fedora Change Proposal), but this may not be necessary for the GNOME Shell case. Impact: Users setting a LUKS password in Anaconda may be forced to enter it on boot using a different keyboard layout than intended, leading to confusion or inability to unlock encrypted disks. [0] https://bugzilla.redhat.com/show_bug.cgi?id=2308654 [1] https://github.com/rhinstaller/anaconda-webui/pull/561 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2346830 [3] https://src.fedoraproject.org/rpms/gnome-initial-setup/c/3cd24ee0efb277932c28e3e39fd09b49870fe128?branch=rawhide Reproducible: Always Steps to Reproduce: 1. Boot Fedora Workstation Live ISO from https://bodhi.fedoraproject.org/updates/FEDORA-2025-5235a700a8 (Before this update there is not a keyboard selection at all) 2. Start Anaconda Web UI and set a keyboard layout. Proceed to set up LUKS encryption. 3. Reboot into the installed system and observe potential layout mismatch for LUKS password entry. Actual Results: The keyboard layout set in Anaconda does not apply to the GNOME Shell session. Users may have to enter LUKS passwords using an unintended layout. Expected Results: Anaconda should be able to control the keyboard layout in the Live session. The user-selected layout should persist for LUKS password entry and system login if not changed in GIS after first boot. Suggested Solution: As a temporary measure, we want to launch the gnome-control-center keyboard tab from the Web UI (see attached screenshot). However, a more permanent solution is needed which should be handled by Gnome Initial Setup.
Created attachment 2078064 [details] mockup - keyboard change
Proposed as a Blocker for 42-beta by Fedora user kkoukiou using the blocker tracking app because: Users setting a LUKS password in Anaconda may be forced to enter it on boot using a different keyboard layout than intended, leading to confusion or inability to unlock encrypted disks.
Hi, this will probably depend also on Anaconda backend changes. PR: https://github.com/rhinstaller/anaconda/pull/6220
I will try to clarify current situation with releasing here. Anaconda now currently has a blocked bodhi update in a freeze to resolve issue with missing GIS which should provide us keyboard layout selection: https://bodhi.fedoraproject.org/updates/FEDORA-2025-5235a700a8 However, we found out, that this solution will not work (because of missing support of localed in Gnome Kiosk reported in bug 2346830), so we spent some time on finding a reasonable replacement. Currently we have a plan and for that reason this bug was filed. The issue is that our dist-git and upstream releasing is desynchronized now. And for that reason we would like to resolve this bug and do a rebase which should resolve all the currently proposed blockers and FEs.
Discussed on 2025-03-03 in a blocker review meeting [1]: !agreed 2348726 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this is rejected as a blocker as it doesn't violate any Beta criteria, but accepted as an FE as we feel fixing this would be a great improvement for Beta and obviously cannot be done with an update [1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2025-03-03/f42-blocker-review.2025-03-03-17.00.log.html
FEDORA-2025-73a6f8a23c (anaconda-42.27.3-1.fc42 and anaconda-webui-26-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-73a6f8a23c
FEDORA-2025-73a6f8a23c has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-73a6f8a23c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-73a6f8a23c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-73a6f8a23c (anaconda-42.27.3-1.fc42 and anaconda-webui-26-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
The 'fix' here was really more of a workaround - just showing a link to gnome-control-center. It's obviously not a real fix. The GNOME upstream issue here is showing activity: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7761 I'm gonna re-open this for downstream tracking (as I'm gonna refer to it in a common issue). Please don't re-assign to a GNOME component as it'll just get closed.
oh, well, hmm, we have https://forge.fedoraproject.org/workstation/tickets/issues/430 for this too. I guess we can go with that as the tracker.