Bug 438246 - Keyboard layout selected during install is forgotten at post-install boot
Summary: Keyboard layout selected during install is forgotten at post-install boot
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-keyboard   
(Show other bugs)
Version: rawhide
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Kristian Høgsberg
QA Contact: Fedora Extras Quality Assurance
: 439632 441009 442512 442523 (view as bug list)
Depends On:
Blocks: F9Blocker F9PR
TreeView+ depends on / blocked
Reported: 2008-03-19 20:55 UTC by Frank Thingholm
Modified: 2008-04-17 19:43 UTC (History)
8 users (show)

Fixed In Version: anaconda-
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-17 19:43:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Frank Thingholm 2008-03-19 20:55:00 UTC
Description of problem:
Keyboard layout selection (keyboard layout "dk") has no effect after Anaconda
reboots (after installation of the appx. 900 packages).

Version-Release number of selected component (if applicable):
Anaconda ...54

How reproducible:
Every time during my daily installs of Fedora 9 (4 days in a row).

Steps to Reproduce:
1. Download boot.iso from rawhide (in my case from
2. Boot and perform clean install from URL mentioned above (standard disk layout)
3. Select language "danish" and keyboard layout "dk" (not "dk latin")
4. Remove tick mark in "office" packages (none of the 4 set of usages selected,
leaving a pretty minimal system)
5. Normal install of appx. 900 packages, reboot, run "first-run" utility
6. Now the keyboard layout is the default "us" and not dk.
Actual results:
Keyboard layout is an english default.

Expected results:
Keyboard layout should be as selected during the installation - in this case it
should be "dk".  A change to "dk" via SYSTEM / ADMINISTRATION / KEYBOARD works
OK and is also in place after next reboot.

Additional info:

Comment 1 Jeremy Katz 2008-03-19 21:56:52 UTC
So /etc/sysconfig/keyboard didn't have the right layout after you rebooted

Comment 2 Frank Thingholm 2008-03-20 04:11:22 UTC
I'll have to check this after my next daily install. Right now it shows "dk" but
I have corrected the layout selection shortly after install by selecting SYSTEM
/ ADMINISTRATION / KEYBOARD and then selecting the "dk" layout. So I don't know
right now if this was orginally something different.

There is another way of correcting the layout - I used that for a previous
install a few days ago: SYSTEM / PREFERENCES / HARDWARE / KEYBOARD and select
the LAYOUT tab. Then ADD layout DANISH and mark as default. This seems to
require a reboot to take effect.

Curiously, the method I used today (SYSTEM / ADMINISTRATION / KEYBOARD), which
also works fine, isn't reflected in SYSTEM / PREFERENCES / HARDWARE / KEYBOARD
which still only mentions US.

It seems we have multiple sets of settings for selecting the keyboard layout and
they don't necessarily need to be set equally?

Comment 3 Jeremy Katz 2008-03-20 13:42:35 UTC
Yes, you can individually set the keyboard layout for the system as well as for
the user 

Comment 4 Frank Thingholm 2008-03-25 02:03:42 UTC
In answer to #1:

The following behaviour is from daily installs from
http://mirrors.kernel.org/fedora/development/i386/os (after the daily syncs) on
22-Mar, 23-Mar and 24-Mar. The problem is still there.

1) /etc/sysconfig/keyboard contains


2) GNOME SYSTEM / ADMINISTRATION / KEYBOARD has "Danish" selected. (Manually
setting this to something else then setting back to "Danish" solves the problem
for me.)

3) GNOME SYSTEM / SETTINGS / HARDWARE / KEYBOARD has "USA" on the list (with no
bullet in the "default" column). (The manual selection mentioned under 2)
doesn't change this but solves the problem anyway.)

I can't confirm changes after reboot and relogin with these builds.

The 21-Mar install (which I didn't examine very carefully) was corrected as
mentioned in 2) above and left on overnight. The next morning it was back to USA
keyboard layout by itself. (Patch handling was left at default which I
understand is "tell about but do not install automatically.)

And thanks to #3 for clarifying that. I suspected something like that, but it
was unclear to me what is "system" and what is "user".

Comment 5 Jeremy Katz 2008-03-25 02:24:04 UTC
Okay, so this is the case that we know about.  We made a late switch back to
using kbd for the keyboard rather than evdev just before beta and so lost the
bits that look at the system settings in /etc/sysconfig/keyboard.  We'll get it
back before the next milestone one way or another.

Comment 6 Frank Thingholm 2008-03-25 02:30:20 UTC
That's fine. Do I change the bug status at this point?

Comment 7 Chris Lumens 2008-03-29 23:00:40 UTC
*** Bug 439632 has been marked as a duplicate of this bug. ***

Comment 8 Chris Lumens 2008-04-07 15:01:05 UTC
*** Bug 441009 has been marked as a duplicate of this bug. ***

Comment 9 Jeremy Katz 2008-04-08 18:08:54 UTC
The plan is to handle this in X based on what is in /etc/sysconfig/keyboard

Comment 10 Jeremy Katz 2008-04-15 13:33:18 UTC
*** Bug 442523 has been marked as a duplicate of this bug. ***

Comment 11 Jeremy Katz 2008-04-15 13:33:26 UTC
*** Bug 442512 has been marked as a duplicate of this bug. ***

Comment 13 Jeremy Katz 2008-04-16 02:01:28 UTC
Okay, for now, made rhpxl go back to writing out a keyboard section if it's
given keyboard information.  Which it is in the installer case.  Don't like it,
but it seems like the shortest path for F9.  For F10, I really am taking out the
writing of an xorg.conf from anaconda, etc, though...

Comment 14 Will Woods 2008-04-17 19:43:42 UTC
I installed F9pr with a UK keyboard. In the installed system, the keyboard
layout indicator shows gb, and shift-3 produces £ as expected.

I'm going to close this, but please retest with F9PR/rawhide-20080417 or later
(anything with anaconda- or higher) to confirm for yourself. Feel
free to re-open this bug if it's not fixed for you.

Note You need to log in before you can comment on or make changes to this bug.