Description of problem: Attempting to install Fedora Workstation 35 using the nightly live image, I get stuck on the user account creation page in gnome-initial-setup. Problem is gnome-initial-setup is using a qwerty keyboard layout instead of the keyboard layout I configured in anaconda. I don't have a qwerty keyboard and cannot continue. Version-Release number of selected component (if applicable): not sure exactly, because I cannot type How reproducible: Always Steps to Reproduce: 1. Select English (Dvorak) keyboard layout in anaconda keyboard spoke 2. Finish installation and reboot into gnome-initial-setup 3. Try to type on the first page that allows typing: the user account creation page Actual results: gnome-initial-setup uses qwerty keyboard layout Expected results: gnome-initial-setup uses configured keyboard layout Additional info: Anaconda seems to have done its job properly by configuring the selected keyboard layout in /etc/vconsole.conf, so I think this is a GNOME regression.
Proposed as a Blocker for 35-final by Fedora user catanzaro using the blocker tracking app because: If a particular keyboard layout has been configured for the system, that keyboard layout must be used: * When unlocking encrypted storage volumes during boot (but see footnotes) * When logging in at a console * When logging in via the default login manager for a release-blocking desktop * After logging in to a release-blocking desktop, if the user account does not have its own keyboard layout configuration for that desktop (if there is such a user/desktop-specific configuration, it must be used when that user logs in to that desktop) The release criterion doesn't actually mention the keyboard layout must work in initial setup tools, but IMO that's just an oversight. If we want to stretch it, we could consider initial setup being logged-in to a release-blocking desktop in which the user is just not required to explicitly log in.
(In reply to Michael Catanzaro from comment #0) > Additional info: Anaconda seems to have done its job properly by configuring > the selected keyboard layout in /etc/vconsole.conf, so I think this is a > GNOME regression. BTW I confirmed this before rebooting into the installed system by checking the /etc/vconsole.conf in the installed sysroot. After rebooting, there's no way I can check anything because I cannot type.
Just checked and Fedora 34 is good. This is a F35 regression. There are no relevant changes in gnome-initial-setup. I wouldn't be surprised if this was somehow fallout from bug #2003253. If someone with a qwerty keyboard wants to try testing that by modifying the kernel command line to disable selinux, it would be interesting to know for sure. That challenge is too much for me today.
Michael, remember you can fiddle with the installed system after installing but before rebooting; it is left mounted at /mnt/sysroot when the installer concludes. You can chroot into it or just edit files in it to do things like set SELinux to permissive mode. You can also set a password for root so you can log in as root at a console while g-i-s is running.
(In reply to Adam Williamson from comment #4) > You can also set a password for root so you > can log in as root at a console while g-i-s is running. Ah yeah, that would work because anaconda did correctly configure the system keyboard layout. It's only broken in the GNOME session, so nothing would prevent me from logging in.
So all I managed to figure out so far is this bug still happens even with selinux disabled. I was hoping it was an selinux issue like bug #1997310. :(
I could not reproduce with Czech QWERTZ layout. Works normally, so maybe it's Dvorak related?
#agreed 2003253 - The decision to delay the classification of this as a blocker bug was made as we are unsure exactly which layouts this affects and want more time to test. PUNT.
localectl says: System Locale: LANG=en_US.UTF-8 VC Keymap: us-dvorak X11 Layout: us X11 Variant: dvorak All identical to my working F34 system, so that all looks good.
In my system journal, I notice that every D-Bus call is failing with the error: Timeout was reached. And of course GNOME relies on talking D-Bus to localed to figure out what keyboard layout it should use. So I think this is a general case of "everything related to D-Bus is broken." I'm not sure why Lukas didn't hit it, though.
(In reply to Michael Catanzaro from comment #10) > In my system journal, I notice that every D-Bus call is failing with the > error: Timeout was reached. And of course GNOME relies on talking D-Bus to > localed to figure out what keyboard layout it should use. So I think this is > a general case of "everything related to D-Bus is broken." See also: bug #2003285 for a gnome-settings-daemon crash here.
Turns out this is fixed. It was caused by bug #1997310 after all. I thought it was not an selinux issue because I didn't realize two different things were breaking D-Bus. *** This bug has been marked as a duplicate of bug 1997310 ***