Description of problem:
When the keyboard layout and localization configuration files are migrated to new location during systemd %post, all XKB_* options from old /etc/sysconfig/keyboard are dropped and X11 starts with implicit US keyboard.
This affects F17 -> F18 upgrade.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. F17 with non-US keyboard configured
2. upgrade to F18 using Fedup
Login manager (KDM in my case) starts and US keyboard is set, instead of my previously defined keyboard.
The keyboard defined prior to update should be set when login manager starts.
> all XKB_* options from old /etc/sysconfig/keyboard are dropped
Thinking of it... I cannot find what was the original content of the file. Not sure if the options used by X11 are really prefixed with XKB_, or whether other options are read. That old configuration was probably created by Anaconda, I do not remember changing the configuration since.
I just installed F17 to reproduce the issue and to make sure that it is really in systemd. If system-config-keyboard is run, /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf is created -- I didn't know that. I thought that the default keyboard is figured out from the content of /etc/sysconfig/keyboard.
# cat /etc/sysconfig/keyboard
Not sure why my keyboard layout stopped working after the upgrade on two different machines. I will close this bug because I think that it was caused by some non-standard configuration I had. Systemd is definitelly not the cause.
Feel free to reopen/reassign if you have the same problem and know the cause.
Re-opening. After a default F17 install there is no /etc/X11/xorg.conf.d file , and upgrading a clean F17 French install to F18 results in U.S. layout used at GDM and GNOME. See https://bugzilla.redhat.com/show_bug.cgi?id=881624#c15 and https://bugzilla.redhat.com/show_bug.cgi?id=881624#c16 . Proposing as a blocker (could potentially screw with password input), though it'll porbably get downgraded to NTH.
Humm, so what is this bug about? This appears to be about different things over its history.
Only taking #3 into account this is already two issues:
a) new installs get no /etc/X11/xorg.conf.d/ file. Does Anaconda use localed to write the initial keymap? If not then this is hardly a systemd issue.
b) On upgrade the keymap is lost. (on x11? on the console?)
This is the code that converts the old files:
To clarify for the record, the bug here is upgrades, not new installs. New F17 installs do get an xorg.conf.d snippet, that works fine. After a clean f17 install with a non-US keymap and upgrade to f18 via fedup, no xorg.conf.d snippet seems to be present and no X11 keymap config present via any other means, so gdm and GNOME both use U.S. layout. That's the bug.
my guess is that this is what happens:
removing s-s-k removes the old snippet and hence the config is lost
and a possible solution would be to take possession of the old file as ghost in the systemd rpm spec (so that it is owned jointly and remains installed9
and then just rename it to the new name in %post
I am running a fresh F17 French install to check whether there really is an xorg.conf.d snippet after F17 install or not, and if so what it's called and what it contains.
confirming that after a clean F17 install, /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf is present, with contents:
# This file is autogenerated by system-setup-keyboard. Any
# modifications will be lost.
Option "XkbModel" "pc105"
Option "XkbLayout" "fr"
Option "XkbVariant" "latin9"
Option "XkbOptions" "terminate:ctrl_alt_bksp,"
So Lennart's diagnosis appears to be correct.
http://koji.fedoraproject.org/koji/taskinfo?taskID=4836808 should fix the issue.
Adam wanted to test if this really fixes the issue. If so, I am happy to file a bodhi ticket for this (or somebody else can).
Discussed at 2012-01-03 go/no-go meeting: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-01-03/f18_final_gono-go_meeting.2013-01-03-17.01.log.txt . Accepted as a blocker per criterion "...it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria." in the case of non-U.S. keymaps. In contrast to the encryption passphrase bug, this one is pretty difficult to work around as GDM doesn't offer an input selector in this case, you're pretty stuck trying to enter your password if it can't be entered on a US layout.
Lennart, please submit the build as an update. Thanks.
systemd-195-14.fc18 has been submitted as an update for Fedora 18.
systemd-195-15.fc18 has been submitted as an update for Fedora 18.
The update seems to fix the bug. I did a yum upgrade with that systemd in the package set, and there's a 00-keyboard.conf after the upgrade with appropriate settings in it. The upgraded system didn't boot, but I did a fairly sloppy yum upgrade and probably screwed something up, it doesn't relate to the X config file. I'll test again with a cleaner scenario later.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-195-14.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
I just upgraded to Fedora 18 via FedUp. I logged in and had the wrong keyboard layout. Then I installed systemd systemd-195-15 - it did not help.
I don't know whether this was correct - I don't know how to fetch systemd-195-15 earlier than after booting into fedora 18. For me, the keyboard layout stayed wrong with the new package.
That's expected. the -15 build has to be part of the initial upgrade for it to work.
if you want to test, you have to enable the updates-testing repo for fedup, there's a command-line parameter to do that. once we push the systemd update stable, it will happen 'by default' for people using fedup according to the instructions.
Fixed for me. I installed fresh F17 and updated with FedUp:
# fedup --network 18 --debuglog fedupdebug.log --instrepo http://dl.fedoraproject.org/pub/fedora/linux/releases/test/18-Beta/Fedora/x86_64/os/ --enablerepo updates-testing
thanks, Jan - can you add karma to the systemd update if you haven't already?
note, add karma to https://admin.fedoraproject.org/updates/FEDORA-2013-0190/systemd-195-15.fc18 , not -14 - sorry. I need to get the -14 update squished.
I'm not sure what version was installed during the upgrade. I originally added the karma to -14 build, but I guess I had the newer -15 installed, because it was already some time in updates-testing. Fixed now. :)
For those of us who ran into this, could someone please explain how to get the system into a "clean" state?
- is there still supposed to be a /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf file?
- can we just create the /etc/X11/xorg.conf.d/00-keyboard.conf using something like localectl set-x11-keymap "de"
systemd-195-15.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Michael: just using localectl should probably do the job in most cases. It ought to write both vconsole.conf and an X config file when you invoke it, I believe.
For the record: just running "localectl" did not work for me but this did:
localctl set-x11-keymap "de" "" "nodeadkeys"
Which generates /etc/vconsole.conf and /etc/X11/xorg.conf.d/00-keyboard.con for me
well, yes, I meant running localectl as you described in c#21. just running it on its own is obviously not going to magically figure out what you wanted it to do. :)
*** Bug 893697 has been marked as a duplicate of this bug. ***
systemd-197-1.fc18.1 has been submitted as an update for Fedora 18.