Bugzilla – Bug 1046436
after installation in "german", desktop has english keyboard layout
Last modified: 2018-01-09 13:16:48 UTC
I just installed Tumbleweed 20170626 fresh, GNOME desktop. I selected German keyboard in the installer. The finally running GNOME has english keyboard layout. It is not fully clear if this is YAST or GNOME fault
Created attachment 730600 [details] /etc/sysconfig/language /etc/sysconfig/language
Created attachment 730601 [details] /etc/sysconfig/keyboard /etc/sysconfig/keyboard
Created attachment 730602 [details] y2log-Z85vZ9.tar.xz yast2 logs
*** Bug 1045880 has been marked as a duplicate of this bug. ***
*** Bug 1047460 has been marked as a duplicate of this bug. ***
raising priority as we get this report a lot
*** Bug 1046967 has been marked as a duplicate of this bug. ***
*** Bug 1048076 has been marked as a duplicate of this bug. ***
tracking in yast trello board
There are actually two things: (1) > /usr/bin/localectl --no-convert set-keymap de-nodeadkeys > Failed to set keymap: Failed to execute program org.freedesktop.locale1: Permission denied 'man localectl' says: > It communicates with systemd-localed(8) to modify files such as /etc/locale.conf and /etc/vconsole.conf. This sentence is new in TW. Note that we don't have systemd running during installation. (2) 'yast keyboard' fiddles with a non-existent 'kbd.service'.
The change was implemented as an answer to https://bugzilla.suse.com/show_bug.cgi?id=1023774 Stefan, what should we do then?
(In reply to Lukas Ocilka from comment #11) > The change was implemented as an answer to > https://bugzilla.suse.com/show_bug.cgi?id=1023774 > > Stefan, what should we do then? I have no idea. I guess for such issues we need to create a script during installation, which is executed the first time, when the system boots after installation with systemd active. And only then and only once. I know, this is crap, but you asked me for a proposal. ;-)
(In reply to Lukas Ocilka from comment #11) > The change was implemented as an answer to > https://bugzilla.suse.com/show_bug.cgi?id=1023774 > > Stefan, what should we do then? Wouldn't it make sense to request some input from the systemd experts about this?
(In reply to Egbert Eich from comment #13) > (In reply to Lukas Ocilka from comment #11) > > The change was implemented as an answer to > > https://bugzilla.suse.com/show_bug.cgi?id=1023774 > > > > Stefan, what should we do then? > > Wouldn't it make sense to request some input from the systemd experts about > this? I guess the answer it a fix for bug#1014991 (see bug 1014991 comment#7).
(In reply to Steffen Winterfeldt from comment #10) > There are actually two things: > > (1) > > > /usr/bin/localectl --no-convert set-keymap de-nodeadkeys > > Failed to set keymap: Failed to execute program org.freedesktop.locale1: Permission denied localectl does dbus calls to talk to systemd-localed. Unfortunately, org.freedesktop.locale1 is not registered with dbus in the installation system: --> # dbus-send --system --print-reply --type=method_call --dest=org.freedesktop.locale1 /org/freedesktop/locale1 org.freedesktop.locale1.SetVConsoleKeyboard string:"de-nodeadkeys" string:"" boolean:false boolean:true Error org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program org.freedesktop.locale1: Permission denied --< The easiest is probably to create a temporary unit that runs localectl at first system boot. Something similar is done via systemd-firstboot.service.
Or maybe the installer (and only the installer) could initialize /etc/vconsole.conf directly ?
(In reply to Franck Bui from comment #16) > Or maybe the installer (and only the installer) could initialize > /etc/vconsole.conf directly ? Franck, haven't you told me, that /etc/vconsole.conf shouldn't be written directly, only indirectly by means of using localectrl?
Indeed but maybe we could make an exception during the *installation* process... Or maybe introduce something like "yast2-firstboot.service" as it was suggested by Thomas. That might be also needed for other stuff that YaST needs to run during the firstboot.
(In reply to Franck Bui from comment #18) > Indeed but maybe we could make an exception during the *installation* > process... No, everything would be in an inconsistent state again!
(In reply to Stefan Dirsch from comment #19) > No, everything would be in an inconsistent state again! could you refresh my memory ? ;)
(In reply to Franck Bui from comment #18) > Or maybe introduce something like "yast2-firstboot.service" as it was > suggested by Thomas. That might be also needed for other stuff that YaST > needs to run during the firstboot. Probably yast can even do this without an additional service. Steffen, is there something like an non-interactive yast2-firstboot or some functionality like the autoyast init-scripts that could be used to run custom commands at first system boot?
There's one important thing: There is no second-stage installation *, so everything needs to be done before reboot. (* Well, there's an optional second-stage for AutoYaST)
(In reply to Franck Bui from comment #20) > (In reply to Stefan Dirsch from comment #19) > > No, everything would be in an inconsistent state again! > > could you refresh my memory ? ;) I can't, since the details are just too long gao. But one thing I can remember. Writing /etc/vconsole.conf directly did not work and always resulted in a possibly wrong layout.
As Lukas wrote, there is no second stage any more; the system has to be configured properly when yast exists. Why would writing vconsole.conf be a problem? There's no localed running, so no confusion. Or not?
(In reply to Steffen Winterfeldt from comment #24) > > Why would writing vconsole.conf be a problem? There's no localed running, so > no confusion. Or not? That was my point: if it's only done during the installation where no systemd is running, that might be ok.
OK, so we have basically two options: A. In the installer, write /etc/vconsole.conf directly, as there's no systemd running and thus we can't use it. B. Create yet another one-off systemd service (script) that would be called during the system boot and adjust all settings that can't be set during the initial installation. The service and the script would not be part of YaST but part of some separate package as no "YaST on the system" is a required feature. Moreover, it would have to be called before YaST.Firstboot, which actually allows adjusting the system via YaST UI and also before YaST.Second-Stage, which is optional for AutoYaST (and which can also change the system) Both options are somewhere between "the solution" and "a hack"...
Ok. Assuming writing vconsole.conf directly during installation works out. Who is then generating the xorg.conf.d keyboard snippet later? (which otherwise would have generated automatically via localectl set-x11-keymap us [1] localectl set-keymap <KEYMAP> [OPTIONS] [2] [1] may no longer be necessary. I believe I eventually closed the bug about the need for this as INVALID - if I recall correctly.
I've just tried and editing /etc/vconsole.conf and just rebooting sets the text console mapping correctly but X11 stays unchanged; apparently as nobody updates /etc/X11/xorg.conf.d/00-keyboard.conf. So I guess we'd have to write both files to be fine. [Option B seems a bit overkill to me.]
(In reply to Lukas Ocilka from comment #26) > OK, so we have basically two options: > > A. In the installer, write /etc/vconsole.conf directly, as there's no > systemd running and thus we can't use it. > > B. Create yet another one-off systemd service (script) that would > be called during the system boot and adjust all settings that > can't be set during the initial installation. The service and the > script would not be part of YaST but part of some separate package > as no "YaST on the system" is a required feature. Moreover, it would > have to be called before YaST.Firstboot, which actually allows > adjusting the system via YaST UI and also before YaST.Second-Stage, > which is optional for AutoYaST (and which can also change the system) > > Both options are somewhere between "the solution" and "a hack"... C. Extend systemd-firstboot to cover kbd settings. The systemd-firstboot manpage states: --> Note that this tool operates directly on the file system and does not involve any running system services, unlike localectl(1), timedatectl(1) or hostnamectl(1). This allows systemd-firstboot to operate on mounted but not booted disk images and in early boot. --< systemd-firstboot is available in the installation system, so this is the tool we would need. Still, implementation of kbd setting support might take a while and upstream acceptance is not guaranteed.
From YaST POV, option C is the cleanest one.
(In reply to Thomas Blume from comment #29) > systemd-firstboot is available in the installation system, so this is the > tool we would need. > Still, implementation of kbd setting support might take a while and upstream > acceptance is not guaranteed. Indeed that might be worth a try... Thomas could you open an issue (or a RFE) against upstream for requesting this new feature so we can hopefully see quickly if that would be the way to go ? If we get a positive answer then we'll implement that.
(In reply to Franck Bui from comment #31) > Thomas could you open an issue (or a RFE) against upstream for requesting > this new feature so we can hopefully see quickly if that would be the way to > go ? > > If we get a positive answer then we'll implement that. Ok, done: https://github.com/systemd/systemd/issues/6346
Hi. I have some information. I tried to change keymap with /etc/vconsole.conf, but not changed. Also,I tried loadkey comannd and localectl command to change keymap,but not worked. But, Using systemd ,for example fedora26, recognize Japanese keyboard, and set right keyboard layout. So,I compared openSUSE Leap's systemd ver and fedora26's systemd ver, fedora26 use 233,but openSUSE use 228. I perceived that /usr/share/kbd/keymap/legacy/mac/mac-jp.map.gz is symbolic link to mac-us.map.gz. My exam environment at office is MacBookPro,so not recognized with Windows Machine Best Regards, Kazufumi Watanabe
*** Bug 1032865 has been marked as a duplicate of this bug. ***
Dear Steffen Winterfeldt I tried to use Japanese keyboard with openSUSE Tumbleweed. And I think after OS install,before reboot, run localectl, for example,[localectl set-keymap jp106] and [localectl set-x11-keymap jp], in case, Japanese keyboard. But this case, not resolve keybord selection at install. Best Regards Kazufumi Watanabe
This bug is still unfixed. Although it is not hard to change the keyboard layout after the installation, it is a big handicap for Linux beginner and new Tumbleweed users since they won't be able to login due to this bug.
I could reproduce the problem two times with KDE on tumbleweed. When you open the system keyboard layout dialog in Yast after the installation "Deutsch" is selected in the list. So Yast think it is "Deutsch". But it is not. I have to select another layout (double click another item in the list) and then re-select "Deutsch". Then it works.
Guys, may I ask you, why you expect a bug to be fixed, when it's still in an open and confirmed state?
Dear Stefan, I don't understand your question.
Dear Stefan Dirsch I think sorry to your reply. I think perhaps buhtz says "I have mac or macbook series with german keyboard,but does not fixed.". Why I think ,because Virtualbox environment is not appear this problem. So,My comment No 33,please add mac keyboard layout.
Sorry I don't understand you. I sayed nothing about mac. I tested this in VirtualBox.
It also happens on SLE-15 Build278.1 Got during manual testing.
It also happens selecting English language and German keyboard during installation. I get an installed system with English keyboard.
Also happens for the Swiss keyboard layout. I'm on KDE, and it's definitely a YAST problem. What's the discussion anyway - that bug is new, and it's not like you didn't use systemd a year ago. There must've been a solution to this problem a year ago before this appeared, no? How did the installer set the layout a year ago?
*** Bug 1056701 has been marked as a duplicate of this bug. ***
Dear All Well,I think must organize environment which environment is happened. I recognized environment is - Japanese Keyboard(MacBook Pro(H/W Key is Japanese)) - German Keyboard(On Virtual Box/What is Host OS?) - Swiss keyboard layout(Which environment?) Other environmet has happened? Not Happened - Japanese keyboard(Virtual Box On Windows/KVM) At Japanese environment,I think what is difference. SUSE can recognize Japanese keyboard layout right,but don't have right keymap file, so,use US Keymap file. Perhaps,other environment what is happen is same,I think. So,I want add more keyboard layout file,not symbolic file. Best regards. Kazufumi Watanabe
For me it happens on physical laptop. Dell Latitude E6530
(In reply to Thomas Blume from comment #32) > https://github.com/systemd/systemd/issues/6346 Thomas, There is a new comment at that issue: poettering commented 12 days ago sure, makes sense to add! And I guess these are the changes (master might not be the correct branch): https://github.com/systemd/systemd/compare/master...tblume:add-keymap-setup-to-systemd-firstboot?expand=1 When can we expect this to be finished? I guess YaST depends on your implementation now? Thanks a lot! BTW :)
(In reply to Lukas Ocilka from comment #48) > There is a new comment at that issue: > poettering commented 12 days ago > sure, makes sense to add! > > And I guess these are the changes (master might not be the correct branch): > https://github.com/systemd/systemd/compare/master...tblume:add-keymap-setup- > to-systemd-firstboot?expand=1 > > When can we expect this to be finished? It's finished, I just wanted to test a bit more but I plan a pull request today. > I guess YaST depends on your implementation now? > Thanks a lot! BTW :) Yes, yast depends on it. I have some testpackages at: https://download.opensuse.org/repositories/home:/tsaupe:/branches:/openSUSE:/Factory:/systemd-upstream/openSUSE_Factory/ If you want to start the work on YaST you can use them. I still might change the code a bit if upstream requests some changes, but the functionality should stay the same. Just consult: /usr/bin/systemd-firstboot --help about how to set the keymap.
Oh great - systemd has to be modified for that? That speaks volumes about that piece of, uhh, Software...
Thomas, we need the package in SLE 15, otherwise we can't implement our side. What's the status? I don't see these changes there, but maybe I'm just looking at a wrong place...
(In reply to Lukas Ocilka from comment #51) > Thomas, we need the package in SLE 15, otherwise we can't implement > our side. What's the status? > > I don't see these changes there, but maybe I'm just looking at a wrong > place... I'm waiting for a reply in the upstream submission at: https://github.com/systemd/systemd/pull/7035 As soon as this is done, we can add it officially to the SLE-15 packages. But we need it in the installation system, so we'll have to wait for new installation media afterwards. Meanwhile I could build test packages for SLE-15 and you could add them to your SLe-15 installation system via a DUD. Would this help on your side?
DUD is OK for testing, but Release Managers want that for Beta1. IMO we need a Plan B -> patch for systemd package. We'll plan for the YaST side of the implementation in less than 30 minutes, but we still depend on the new systemd to be there. We can implement it in in way that it's gonna silently fail... till the new package is in inst-sys.
(In reply to Lukas Ocilka from comment #53) > DUD is OK for testing, but Release Managers want that for Beta1. > IMO we need a Plan B -> patch for systemd package. > We'll plan for the YaST side of the implementation in less than 30 minutes, > but we still depend on the new systemd to be there. > > We can implement it in in way that it's gonna silently fail... till > the new package is in inst-sys. We agreed amongst the systemd maintainers to do a submit to SLE-15 despite the patch hasn't been approved upstream yet.
(In reply to Lukas Ocilka from comment #53) > DUD is OK for testing, but Release Managers want that for Beta1. > IMO we need a Plan B -> patch for systemd package. > We'll plan for the YaST side of the implementation in less than 30 minutes, > but we still depend on the new systemd to be there. > > We can implement it in in way that it's gonna silently fail... till > the new package is in inst-sys. With the patched systemd, the following works in the installation system: --> 0:g179:~ # systemd-firstboot --root /mnt --keymap=de-latin1-nodeadkeys Found container virtualization none. /mnt/etc/vconsole.conf written. 0:g179:~ # cat /mnt/etc/vconsole.conf KEYMAP=de-latin1-nodeadkeys --<
Nice! And which content do we have in /etc/X11/xorg.conf.d/00-keyboard.conf afterwards?
(In reply to Stefan Dirsch from comment #56) > Nice! And which content do we have in > > /etc/X11/xorg.conf.d/00-keyboard.conf > > afterwards? I'm afraid that can't be done in the installation system. The command for conversion to X11 keymaps is done via dbus calls to localed. We know that this doesn't work in the installer. Furthermore, not every machine installs the Xserver. IMHO, that part should be done at first system boot by using the data from vsconsole.conf.
Do I see this correctly that we spent months and even blocked beta1 waiting for something roughly equivalent of echo KEYMAP=de-latin1-nodeadkeys > /mnt/etc/vconsole.conf ???
(In reply to Steffen Winterfeldt from comment #58) > Do I see this correctly that we spent months and even blocked beta1 waiting > for something roughly equivalent of > > echo KEYMAP=de-latin1-nodeadkeys > /mnt/etc/vconsole.conf > > ??? see bug#1023774 there is complain that writing it directly is not always correct if done by yast and should be done by localectl. At least we have now responsible sources, who ensure it is written correctly.
See comment 56 and comment 57. The whole point here is that you should not write it directly as using systemd provides the additional benefit of syncing the various keymap definitions in the system. If this second part is not done, what's left?
(In reply to Josef Reidinger from comment #59) > (In reply to Steffen Winterfeldt from comment #58) > > Do I see this correctly that we spent months and even blocked beta1 waiting > > for something roughly equivalent of > > > > echo KEYMAP=de-latin1-nodeadkeys > /mnt/etc/vconsole.conf > > > > ??? > > see bug#1023774 there is complain that writing it directly is not always > correct if done by yast and should be done by localectl. At least we have > now responsible sources, who ensure it is written correctly. Yes, it does some sanity checks, for example: --> 0:g179:~ # systemd-firstboot --keymap=. Keymap . is not valid. 0:g179:~ # systemd-firstboot --keymap=/bla Keymap /bla is not valid. --< But please be aware that it doesn't check for the existence of the keymap file, e.g.: --> 0:g179:~ # systemd-firstboot --keymap=blafasel /etc/vconsole.conf written. 0:g179:~ # cat /etc/vconsole.conf KEYMAP=blafasel --<
(In reply to Steffen Winterfeldt from comment #60) > See comment 56 and comment 57. The whole point here is that you should not > write it directly as using systemd provides the additional benefit of > syncing the various keymap definitions in the system. If this second part is > not done, what's left? This second part should be done via a service at initial system boot. I don't see any chance to do this without systemd running.
When I tested this back then (comment 28) the x11 keymap config was not created on system startup. Does this work now, provided we have set /etc/vconsole.conf?
(In reply to Steffen Winterfeldt from comment #63) > When I tested this back then (comment 28) the x11 keymap config was not > created on system startup. Does this work now, provided we have set > /etc/vconsole.conf? Well, I expect not, but I hope X should on first start set it from vconsole.conf ( not sure if it is doing it now, but it should start, as yast does not have second stage to do it ).
(In reply to Josef Reidinger from comment #64) > (In reply to Steffen Winterfeldt from comment #63) > > When I tested this back then (comment 28) the x11 keymap config was not > > created on system startup. Does this work now, provided we have set > > /etc/vconsole.conf? > > Well, I expect not, but I hope X should on first start set it from > vconsole.conf ( not sure if it is doing it now, but it should start, as yast > does not have second stage to do it ). X does read /etc/X11/xorg.conf.d/00-keyboard.conf. It does not write it! One needs to use localectl now for any keyboard configuration now in order to have a consistent state in Linux console and X11 keyboard setting and content of /etc/vconsole.conf. And running localectl in the installed system again with the same value, which has already been set in /etc/vconsole.conf during installation, will not create the X11 keybaord config file either. (localectl will think, it's already set, so nothing to do!).
See also comments #27 and #28.
So this sounds like one of the X packages needs to add a service running at startup?
(In reply to Stefan Dirsch from comment #65) > X does read /etc/X11/xorg.conf.d/00-keyboard.conf. It does not write it! One > needs to use localectl now for any keyboard configuration now in order to > have a consistent state in Linux console and X11 keyboard setting and > content of /etc/vconsole.conf. What was writing /etc/X11/xorg.conf.d/00-keyboard.conf before systemd? > And running localectl in the installed system again with the same value, > which has already been set in /etc/vconsole.conf during installation, will > not create the X11 keybaord config file either. (localectl will think, it's > already set, so nothing to do!). That seems to be fixed in SLES15: --> g179:~ # cat /etc/os-release NAME="SLES" VERSION="15" VERSION_ID="15" PRETTY_NAME="SUSE Linux Enterprise Server 15" ID="sles" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:15" g179:~ # g179:~ # cat /etc/X11/xorg.conf.d/00-keyboard.conf cat: /etc/X11/xorg.conf.d/00-keyboard.conf: No such file or directory g179:~ # g179:~ # g179:~ # cat /etc/vconsole.conf KEYMAP=de-latin1-nodeadkeys g179:~ # g179:~ # man localectl g179:~ # localectl set-x11-keymap de-latin1-nodeadkeys g179:~ # g179:~ # cat /etc/X11/xorg.conf.d/00-keyboard.conf # Written by systemd-localed(8), read by systemd-localed and Xorg. It's # probably wise not to edit this file manually. Use localectl(1) to # instruct systemd-localed to update it. Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "de-latin1-nodeadkeys" EndSection g179:~ # -->
xdm.changes: ------------------------------------------------------------------- Wed Oct 18 15:01:24 UTC 2017 - sndirsch@suse.com - reintroduced /etc/X11/xdm/keytable script and the hook-up in /usr/lib/X11/display-manager to setup X11 keymaps, since YaST is not able to use localectl already during installation due to dbus and appropriate systemd services not running :-( (bsc#1046436) https://build.opensuse.org/request/show/534975 Unfortunately this change sits on top of another radical change in xdm package. ------------------------------------------------------------------- Thu Oct 12 10:08:28 UTC 2017 - dimstar@opensuse.org - Have update-alternatives handle Xinit's integration of the displaymanager, replacing /etc/sysconfig/displaymanager. - Add a dummy entry for 'console' - which is special-cased in the display-manager script to 'exit early'. In order for it to become an option for update-alternatives, the target needs to exist. - Update /usr/lib/X11/display-manager to get the default-displaymanager from the update-alternative setting instead of reading it from /etc/sysconfig/displaymanager. - Remove DISPLAYMANAGER from displaymanager.sysconfig template. - Add xdm-with-update-alternative.patch so the needed changes can be applied for suse_version >= 1330 only, not breaking Leap 42.x. - All that together solves boo#1053863. And that change depends on other displaymanager packages being adjusted first. This is going to become a funny week.
But anyway, feel free to give it a try. Built packages are in obs://X11:XOrg/xdm
(In reply to Stefan Dirsch from comment #70) > But anyway, feel free to give it a try. Built packages are in > > obs://X11:XOrg/xdm Meanwhile I gave it a try myself on Tumbleweed with xdm. Appears to work. (I've created manually /etc/vconsole.conf and then ran rcxdm restart. X11 keyboard layout has been created accordingly.) Unfortunately I can't test with other DMs like gdm, since they haven't been adjusted let alone checked in yet. :-( See https://build.opensuse.org/request/show/534162 for more details.
(In reply to Thomas Blume from comment #62) > (In reply to Steffen Winterfeldt from comment #60) > > See comment 56 and comment 57. The whole point here is that you should not > > write it directly as using systemd provides the additional benefit of > > syncing the various keymap definitions in the system. If this second part is > > not done, what's left? > > This second part should be done via a service at initial system boot. > I don't see any chance to do this without systemd running. If we don't do it as install time, we are loosing information from the install. Currently, it tries to call localectl set-x11-keymap with all parameters (layout model variant and options) Just relying on calling at runtime localectl set-keymap will just set the "default" computed by the kbd-model-map, which is not enough.
(In reply to Frederic Crozat from comment #75) > > This second part should be done via a service at initial system boot. > > I don't see any chance to do this without systemd running. > > If we don't do it as install time, we are loosing information from the > install. Currently, it tries to call localectl set-x11-keymap with all > parameters (layout model variant and options) > > Just relying on calling at runtime localectl set-keymap will just set the > "default" computed by the kbd-model-map, which is not enough. Hm, I'm not really sure what information we loose. We have the keymap in /etc/vconsole.conf, that is written at install time via systemd-firstboot. We only need to extract the keymap from there at runtime and set the x11 keymap accordingly. In order to set the x11 keymap, we can use: localectl set-x11-keymap $KEYMAP where $KEYMAP ist the one extracted from vconsole.conf. So, what is missing?
I would call the issue fixed with my change in xdm package. BTW, running localectl set-x11-keymap $KEYMAP is simply wrong. You need to run localectl set-keymap $KEYMAP which sets the Linux console keyboard layout *and* writes the *appropriate* X11 keyboard layout (there is a mapping, which is needed!). Unfortunately it does not create /etc/X11/xorg.conf.d/00-keyboard.conf if it does not exist yet. Therefore I run localectl set-x11-keymap us in my script as workaround before if needed. Unfortunately this bug has never been fixed. Sigh.
(In reply to Frederic Crozat from comment #75) > If we don't do it as install time, we are loosing information from the > install. Currently, it tries to call localectl set-x11-keymap with all > parameters (layout model variant and options) > > Just relying on calling at runtime localectl set-keymap will just set the > "default" computed by the kbd-model-map, which is not enough. Frederic, console keyboard mappings are now generated from the X11 keyboard layouts with layout, mode, variant and options. Therefore they now have strange names like "de-latin1-nodeadkeys". This name is used in /etc/vconsole.conf. Therefore one just needs to run localectl set-keymap <this-possibly-strange-name> It then gets written to /etc/vconsole.conf, Linux console keyboard is set and X11 keybaord config snippet written.
(In reply to Stefan Dirsch from comment #79) > (In reply to Frederic Crozat from comment #75) > > If we don't do it as install time, we are loosing information from the > > install. Currently, it tries to call localectl set-x11-keymap with all > > parameters (layout model variant and options) > > > > Just relying on calling at runtime localectl set-keymap will just set the > > "default" computed by the kbd-model-map, which is not enough. > > Frederic, console keyboard mappings are now generated from the X11 keyboard > layouts with layout, mode, variant and options. Therefore they now have > strange names like "de-latin1-nodeadkeys". This name is used in > /etc/vconsole.conf. > Therefore one just needs to run > > localectl set-keymap <this-possibly-strange-name> > > It then gets written to /etc/vconsole.conf, Linux console keyboard is set > and X11 keybaord config snippet written. Looks at yast2 code (yast-country to be precise), it is still calling: "/usr/bin/localectl --no-convert set-x11-keymap #{args.join(' ')}" and will try to set the various options for X11 (not sure where it will get the data from). If we don't expose those options in YaST nor the installer anymore, that's fine, but yast2-country might still need some cleanup
yast2-country has not been submitted yet, I'll do a quick test with the latest image and submit that.
FYI, the yast2-country part is (still not submitted) https://github.com/yast/yast-country/pull/145
(In reply to Martin Vidner from comment #82) > FYI, the yast2-country part is (still not submitted) > https://github.com/yast/yast-country/pull/145 May I ask, why you're using --no-convert localectl option. It is my understanding, that it won't create X11 keyboard configuration or in a wrong way.
Um, no idea, that was used already before. Anyway that part is relevant only for the installed system, during installation Stage.initial == true. Let's focus on the installation here, at least for now...
(In reply to Ladislav Slezák from comment #84) > Um, no idea, that was used already before. And for the new system we need to change it. > Anyway that part is relevant only for the installed system, during installation > Stage.initial == true. Let's focus on the installation here, at least for now... Sure we can focus on the installation system, but we should also fix it for the installed system, right? Why not now?
The YaST fix (https://github.com/yast/yast-country/pull/145) has been merged, submitted in yast2-country-4.0.3 in https://build.suse.de/request/show/144417 Unfortunately the problem was still not fix in my manual test. The /etc/vconsole.conf file was completely missing. I have used Build174.3 from http://download.suse.de/ibs/SUSE:/SLE-15:/GA:/Staging:/Y/images/iso/. Maybe it was not recent enough, there is some newer already. However, the YaST part worked as expected, the YaST log contains this line: modules/Keyboard.rb:895 Making console keyboard persistent: /usr/bin/systemd-firstboot --root /mnt --keymap 'cz-lat2-us' Which indicated that the correct command was call, also there is no error reported in the log so it succeeded. So for me the YaST side looks OK. Thomas or Stefan, please check it when the fixed YaST package is accepted.
(In reply to Stefan Dirsch from comment #85) > Sure we can focus on the installation system, but we should also fix it for > the installed system, right? Why not now? This is Beta1 blocker and my impression is that the installation part is what blocks the Beta1 release, not installed system.
And also to reduce the risk of breaking something else in the Beta1 I'd rather postpone that fix after the release (if release managers are fine with that).
(In reply to Ladislav Slezák from comment #86) > The YaST fix (https://github.com/yast/yast-country/pull/145) has been > merged, submitted in yast2-country-4.0.3 in > https://build.suse.de/request/show/144417 > > Unfortunately the problem was still not fix in my manual test. The > /etc/vconsole.conf file was completely missing. > > I have used Build174.3 from > http://download.suse.de/ibs/SUSE:/SLE-15:/GA:/Staging:/Y/images/iso/. Maybe > it was not recent enough, there is some newer already. > > However, the YaST part worked as expected, the YaST log contains this line: > > modules/Keyboard.rb:895 Making console keyboard persistent: > /usr/bin/systemd-firstboot --root /mnt --keymap 'cz-lat2-us' > > > Which indicated that the correct command was call, also there is no error > reported in the log so it succeeded. So for me the YaST side looks OK. > > > Thomas or Stefan, please check it when the fixed YaST package is accepted. I did a try with this image and cannot find the above call to systemd-firstboot in the yast logs. I which logfile have you seen it?
(In reply to Thomas Blume from comment #89) > > I have used Build174.3 from > > http://download.suse.de/ibs/SUSE:/SLE-15:/GA:/Staging:/Y/images/iso/. Maybe > > it was not recent enough, there is some newer already. > I did a try with this image and cannot find the above call to > systemd-firstboot in the yast logs. I which logfile have you seen it? I used that build + manually patched Keyboard.rb YaST file. It wont work in the original build. The yast2-country-4.0.3 has been accepted to Staging Y, you just have to wait until the ISO is rebuilt. You can verify the package version by running "grep yast2-country /.packages.root" in the running inst-sys. (Either switch to another console or boot with "start_shell=1".)
(In reply to Ladislav Slezák from comment #91) > > You can verify the package version by running "grep yast2-country > /.packages.root" in the running inst-sys. (Either switch to another console > or boot with "start_shell=1".) I've tried with the latest image from Staging D and could reproduce the behaviour. It is pretty weird, the yast logs show: --> 2017-10-23 11:31:18 <1> kvm134(3795) [Ruby] modules/Keyboard.rb:895 Making console keyboard persistent: /usr/bin/systemd-firstboot --root /mnt --keymap 'de-latin1-nodeadkeys' 2017-10-23 11:31:18 <1> kvm134(3795) [Ruby] modules/Keyboard.rb:948 Skipping active key <nLyy.+49ps10DtUF> --> to be configured 2017-10-23 11:31:18 <1> kvm134(3795) [Ruby] modules/Keyboard.rb:960 Marked keyboard <nLyy.+49ps10DtUF> as configured 2017-10-23 11:31:18 <1> kvm134(3795) [Ruby] modules/Keyboard.rb:964 Marked keyboard <nLyy.+49ps10DtUF> as needed 2017-10-23 11:31:18 <1> kvm134(3795) [Ruby] modules/Keyboard.rb:970 Saved data for keyboard: <german> --< dmesg shows a successfull write as well: [ 307.498422] systemd-firstboot[25165]: /mnt/etc/vconsole.conf written. still vconsole.conf isn't there: --> 1:linux-akgf:~ # mount /dev/sda1 /mnt 1:linux-akgf:~ # 1:linux-akgf:~ # ll /mnt/etc/vconsole.conf ls: cannot access '/mnt/etc/vconsole.conf': No such file or directory 1:linux-akgf:~ # --< executing the command from a shell works though: --> 1:linux-akgf:~ # /usr/bin/systemd-firstboot --root /mnt --keymap 'de-latin1-nodeadkeys' /mnt/etc/vconsole.conf written. 1:linux-akgf:~ # ll /mnt/etc/vconsole.conf -rw-r--r-- 1 root root 28 Oct 23 11:40 /mnt/etc/vconsole.conf 1:linux-akgf:~ # 1:linux-akgf:~ # cat /mnt/etc/vconsole.conf KEYMAP=de-latin1-nodeadkeys 1:linux-akgf:~ # --< Is there any way to stop the installation directly after systemd-firstboot has been executed from the YaST2 module?
1. Boot with "startshell=1 netsetup=dhcp" 2. When the shell is active replace the Keyboard.rb file: a) copy this file to /tmp: https://github.com/yast/yast-country/blob/kbd_debug/keyboard/src/modules/Keyboard.rb b) mount --bind /tmp/Keyboard.rb /usr/share/YaST2/modules/Keyboard.rb 3. Start the installation with "yast" 4. YaST displays a Popup after running the "systemd-firstboot" command with the result, keep the popup open 5. For debugging switch to another console (e.g. Ctrl+F2) or use Ctrl+Shift+Alt+X in YaST to open an xterm window (GUI only)
BTW I'm getting "unrecognized option --keymap" error with build 313.1, looks like the systemd patch is not present in the latest build yet.
(In reply to Ladislav Slezák from comment #93) > 1. Boot with "startshell=1 netsetup=dhcp" > 2. When the shell is active replace the Keyboard.rb file: > a) copy this file to /tmp: > https://github.com/yast/yast-country/blob/kbd_debug/keyboard/src/modules/ > Keyboard.rb > b) mount --bind /tmp/Keyboard.rb /usr/share/YaST2/modules/Keyboard.rb > 3. Start the installation with "yast" > 4. YaST displays a Popup after running the "systemd-firstboot" command with > the result, keep the popup open > 5. For debugging switch to another console (e.g. Ctrl+F2) or use > Ctrl+Shift+Alt+X in YaST to open an xterm window (GUI only) Thanks, and here we have the problem: --> 1:kvm134:~ # find /mnt/ -name vconsole.conf /mnt/mnt/etc/vconsole.conf --< The config file is there, only in the wrong directory. Seems that systemd-firstboot sees a different path for system root when called via the YaST module. The following change seems to work: --> --- Keyboard.rb 2017-10-23 14:00:00.491466812 +0200 +++ Keyboard.rb.mod 2017-10-23 14:35:32.249892754 +0200 @@ -889,7 +889,7 @@ chomped_keymap = @keymap.chomp(".map.gz") cmd = if Stage.initial - "/usr/bin/systemd-firstboot --root #{Installation.destdir} --keymap '#{chomped_keymap}'" + "/usr/bin/systemd-firstboot --keymap '#{chomped_keymap}'" else "/usr/bin/localectl --no-convert set-keymap #{chomped_keymap}" end --> 1:kvm134:~ # find /mnt/ -name vconsole.conf /mnt/etc/vconsole.conf 1:kvm134:~ # Can you give it a try?
(In reply to Ladislav Slezák from comment #94) > BTW I'm getting "unrecognized option --keymap" error with build 313.1, looks > like the systemd patch is not present in the latest build yet. I've used this one from IBS, which had the patches applied: SLE-15-Installer-DVD-x86_64-Build170.1-Media1.iso
(In reply to Thomas Blume from comment #95) > The config file is there, only in the wrong directory. > Seems that systemd-firstboot sees a different path for system root when > called via the YaST module. > The following change seems to work: > > --> > --- Keyboard.rb 2017-10-23 14:00:00.491466812 +0200 > +++ Keyboard.rb.mod 2017-10-23 14:35:32.249892754 +0200 > @@ -889,7 +889,7 @@ > > chomped_keymap = @keymap.chomp(".map.gz") > cmd = if Stage.initial > - "/usr/bin/systemd-firstboot --root #{Installation.destdir} --keymap > '#{chomped_keymap}'" > + "/usr/bin/systemd-firstboot --keymap '#{chomped_keymap}'" Aaaarggh, the cmd is already executed in /mnt chroot, no need for the "--root" option... :-O But it executes the command in the *installed* system. Can we assume that "/usr/bin/systemd-firstboot" is always available? Even in the very minimal system? (Otherwise we should call it from inst-sys with the --root option.)
(In reply to Ladislav Slezák from comment #98) > (In reply to Thomas Blume from comment #95) > > > The config file is there, only in the wrong directory. > > Seems that systemd-firstboot sees a different path for system root when > > called via the YaST module. > > The following change seems to work: > > > > --> > > --- Keyboard.rb 2017-10-23 14:00:00.491466812 +0200 > > +++ Keyboard.rb.mod 2017-10-23 14:35:32.249892754 +0200 > > @@ -889,7 +889,7 @@ > > > > chomped_keymap = @keymap.chomp(".map.gz") > > cmd = if Stage.initial > > - "/usr/bin/systemd-firstboot --root #{Installation.destdir} --keymap > > '#{chomped_keymap}'" > > + "/usr/bin/systemd-firstboot --keymap '#{chomped_keymap}'" > > Aaaarggh, the cmd is already executed in /mnt chroot, no need for the > "--root" option... :-O > > But it executes the command in the *installed* system. Can we assume that > "/usr/bin/systemd-firstboot" is always available? Even in the very minimal > system? (Otherwise we should call it from inst-sys with the --root option.) it is part of systemd package, so yes, it will be always there..
OK, the fix will be submitted in few minutes...
Fixed in yast2-country-4.0.4 (https://github.com/yast/yast-country/pull/146) SR: https://build.suse.de/request/show/144603
I have tested Build321.4 and the /etc/vconsole.conf file was created properly and the keyboard worked as expected in the console. Closing as FIXED. (Please test also the X installation, I did only minimal text mode test.)
JFYI: in yast2-country-4.0.5 I have improved the error reporting, if the "systemd-firstboot" call fails YaST displays a popup. (https://github.com/yast/yast-country/pull/147) This fix is not required for the Beta release, it can be merged later...
(In reply to Ladislav Slezák from comment #104) > I have tested Build321.4 and the /etc/vconsole.conf file was created > properly and the keyboard worked as expected in the console. > > Closing as FIXED. > > (Please test also the X installation, I did only minimal text mode test.) X installation works fine too, keymap is properly configured
Looks good. Thanks.
(In reply to Stefan Dirsch from comment #83) > (In reply to Martin Vidner from comment #82) > > FYI, the yast2-country part is (still not submitted) > > https://github.com/yast/yast-country/pull/145 > > May I ask, why you're using --no-convert localectl option. It is my > understanding, that it won't create X11 keyboard configuration or in a wrong > way. (In reply to Ladislav Slezák from comment #84) > Um, no idea, that was used already before. Anyway that part is relevant only > for the installed system, during installation Stage.initial == true. Let's > focus on the installation here, at least for now... So this issue has been successfully ignored, right? It basically means that keyboard layout changes via YaST after installation will only affect Linux console, but not X11. So we need an additional bug report for this?
Also verified from QA during manual testing of build 321.5. Can we marked this ticket as verified fixed? Or is there yet work to do about it?
I cannot confirm this issue would have been fixed with the latest image. I've used /mounts/dist/install/SLE-15-Installer-TEST/SLE-15-Installer-DVD-x86_64-Build321.5-Media1.iso I've installed SLED with all available modules enabled. Registration key from https://wiki.microfocus.net/index.php?title=YAST/reg_codes ("real" SCC) I couldn't test SLES, since the key from this page didn't work, only the one for SLED did. I've selected packages as much as possible, as long as it could be resolved. Result was # cat /etc/vconsole.conf KEYMAP=de-latin1-nodeadkeys And no /etc/X11/xorg.conf.d/00-keyboard.conf. So X11 keybaord configuration has not been written. Reason is that xdm package has not been updated for this image. It's missing the changelog entries: ------------------------------------------------------------------- Wed Oct 18 15:01:24 UTC 2017 - sndirsch@suse.com - reintroduced /etc/X11/xdm/keytable script and the hook-up in /usr/lib/X11/display-manager to setup X11 keymaps, since YaST is not able to use localectl already during installation due to dbus and appropriate systemd services not running :-( (bsc#1046436) ------------------------------------------------------------------- Thu Oct 12 10:08:28 UTC 2017 - dimstar@opensuse.org - Have update-alternatives handle Xinit's integration of the displaymanager, replacing /etc/sysconfig/displaymanager. - Add a dummy entry for 'console' - which is special-cased in the display-manager script to 'exit early'. In order for it to become an option for update-alternatives, the target needs to exist. - Update /usr/lib/X11/display-manager to get the default-displaymanager from the update-alternative setting instead of reading it from /etc/sysconfig/displaymanager. - Remove DISPLAYMANAGER from displaymanager.sysconfig template. - Add xdm-with-update-alternative.patch so the needed changes can be applied for suse_version >= 1330 only, not breaking Leap 42.x. - All that together solves boo#1053863. Update xdm manually in order to create /etc/X11/xorg.conf.d/00-keyboard.conf for the first time. Then I've tested YaST keyboard module after installation. As explained before YaST keyboard module should use localectl set-keymap de-latin1-nodeadkeys instead of localectl --no-convert set-keymap de-latin1-nodeadkeys localectl --no-convert set-x11-keymap de pc105 nodeadkeys \ terminate:ctrl_alt_bksp localectl set-keymap is responsible for creating *also* the X11 keybaord layout and the mapping. I'm not sure, why this bug has been closed as fixed. Seriously.
(In reply to Stefan Dirsch from comment #110) > I cannot confirm this issue would have been fixed with the latest image. > I've used > > /mounts/dist/install/SLE-15-Installer-TEST/SLE-15-Installer-DVD-x86_64- > Build321.5-Media1.iso > > I've installed SLED with all available modules enabled. Registration key from > > https://wiki.microfocus.net/index.php?title=YAST/reg_codes ("real" SCC) So, you didn't test the latest build. You tested Alpha5 modules, on top of up-to-date SLE15 Installer. > I'm not sure, why this bug has been closed as fixed. > Seriously. Because people really tested the proper builds. Please either use proxy SCC or the additional "ALL Packages" iso.
(In reply to Frederic Crozat from comment #111) > (In reply to Stefan Dirsch from comment #110) > > I cannot confirm this issue would have been fixed with the latest image. > > I've used > > > > /mounts/dist/install/SLE-15-Installer-TEST/SLE-15-Installer-DVD-x86_64- > > Build321.5-Media1.iso > > > > I've installed SLED with all available modules enabled. Registration key from > > > > https://wiki.microfocus.net/index.php?title=YAST/reg_codes ("real" SCC) > > So, you didn't test the latest build. You tested Alpha5 modules, on top of > up-to-date SLE15 Installer. Aha. The installation procedure is just nowhere explained! sle15 is such a mess! > > I'm not sure, why this bug has been closed as fixed. > > Seriously. > > Because people really tested the proper builds. > > Please either use proxy SCC Ok. Then this information is well/perfectly hidden! > or the additional "ALL Packages" iso. Which I can find where ???
(In reply to Stefan Dirsch from comment #112) > (In reply to Frederic Crozat from comment #111) > > (In reply to Stefan Dirsch from comment #110) > > > I cannot confirm this issue would have been fixed with the latest image. > > > I've used > > > > > > /mounts/dist/install/SLE-15-Installer-TEST/SLE-15-Installer-DVD-x86_64- > > > Build321.5-Media1.iso > > > > > > I've installed SLED with all available modules enabled. Registration key from > > > > > > https://wiki.microfocus.net/index.php?title=YAST/reg_codes ("real" SCC) > > > > So, you didn't test the latest build. You tested Alpha5 modules, on top of > > up-to-date SLE15 Installer. > > Aha. The installation procedure is just nowhere explained! sle15 is such a > mess! This is explained in every milestone release email for SLE15. It was also explained during the SLE15 lunch'n'learn which took place in Nuremberg some weeks ago. > > > I'm not sure, why this bug has been closed as fixed. > > > Seriously. > > > > Because people really tested the proper builds. > > > > Please either use proxy SCC > > Ok. Then this information is well/perfectly hidden! > > > or the additional "ALL Packages" iso. > > Which I can find where ??? Please check Stefan Behlert email on devel which was sent minutes ago. It contains everything.
(In reply to Stefan Dirsch from comment #108) > (In reply to Stefan Dirsch from comment #83) > > (In reply to Martin Vidner from comment #82) > > > FYI, the yast2-country part is (still not submitted) > > > https://github.com/yast/yast-country/pull/145 > > > > May I ask, why you're using --no-convert localectl option. It is my > > understanding, that it won't create X11 keyboard configuration or in a wrong > > way. > > (In reply to Ladislav Slezák from comment #84) > > Um, no idea, that was used already before. Anyway that part is relevant only > > for the installed system, during installation Stage.initial == true. Let's > > focus on the installation here, at least for now... > > So this issue has been successfully ignored, right? It basically means that > keyboard layout changes via YaST after installation will only affect Linux > console, but not X11. So we need an additional bug report for this? Yes, let's track this in a new bug, this one is already too full of comments. And the installation issue is solved, while this is post-installation. Thanks.
(In reply to Frederic Crozat from comment #113) > > > So, you didn't test the latest build. You tested Alpha5 modules, on top of > > > up-to-date SLE15 Installer. > > > > Aha. The installation procedure is just nowhere explained! sle15 is such a > > mess! > > This is explained in every milestone release email for SLE15. "For testing SLE 15 with SCC you need a beta registration code." That was it. No information how to get thes keys, let alone SCC proxies ... I was happy that someone once told me about this webpage https://wiki.microfocus.net/index.php?title=YAST/reg_codes > It was also > explained during the SLE15 lunch'n'learn which took place in Nuremberg some > weeks ago. I missed that one, since I was supposed to go to SUSE Labs conference. :-( > Please check Stefan Behlert email on devel which was sent minutes ago. It > contains everything. Unfortunately I do not read devel mails each minute. Ah. The boot option for proxy SCC now suddenly changed from "SCC_URL" to "regurl". That explains why my further testing didn't work either ...
Ok. With repositories of SCC proxy xdm package is up-to-date and X11 keyboard configuration is correct. I'm going to report a separate bug for the required localectl usage change in YasT2.
(In reply to Stefan Dirsch from comment #117) > Ok. With repositories of SCC proxy xdm package is up-to-date and X11 > keyboard configuration is correct. I'm going to report a separate bug for > the required localectl usage change in YasT2. boo#1065264
(In reply to Sergio Lindo Mansilla from comment #109) > Also verified from QA during manual testing of build 321.5. > > Can we marked this ticket as verified fixed? > Or is there yet work to do about it? Sergio. This bug was initially reported for openSUSE Tumbleweed. Could you please verify TW and then set the bug to VERIFIED FIXED?
(In reply to Oliver Kurz from comment #119) > (In reply to Sergio Lindo Mansilla from comment #109) > > Also verified from QA during manual testing of build 321.5. > > > > Can we marked this ticket as verified fixed? > > Or is there yet work to do about it? > > Sergio. This bug was initially reported for openSUSE Tumbleweed. Could you > please verify TW and then set the bug to VERIFIED FIXED? I have tried with openSUSE-20171028-i586-x86_64-Build0002 and the issue still happens on tumbleweed. Reopen?
That's because the fix in systemd has still not reached TW repos but that should happen soon since it's been accepted in Factory. Please wait for the next TW snapshot.
If anything things seem to be regressing as my installations of Tumbleweed are beginning to exhibit this problem. They are different computers from different manufacturers (e.g., I first noticed it on a ASUS laptop but it has since crept on to an Acer laptop. The keyboard reverts to US layout with no obvious reason why, e.g., home/[me]/.local/share/kded5/keyboard/session/layout_memory.xml contains <LayoutMap SwitchMode="Global" version="1.0"><item currentLayout="gb"/></LayoutMap>
A heads-up: I *think* the systemd changes are propagated to Tumbleweed now, but the problem is that, at least on fresh KDE installs, IBus is installed per default, but in a completely unconfigured state, i.e. with the en-US layout: https://bugzilla.opensuse.org/show_bug.cgi?id=1073215
*** Bug 1042423 has been marked as a duplicate of this bug. ***
*** Bug 1074168 has been marked as a duplicate of this bug. ***
*** Bug 1066507 has been marked as a duplicate of this bug. ***
For me, at least, I think I have found a solution. iBus defaults to US English and seems to "grab" the system settings (I have no idea what it for but it suddenly appeared as a temporary dependency for LO and I believe it's going from KDE soon isn't it?) setting your preferred language in iBus seems to be a workaround
This bug should be closed again and a new bug openend for ibus not being configured at all. And no longer close bugs as duplicate of this one.
And please close boo#1074168 as dup of this new ibus bug.
Ah. There is already such an ibus bug (basically closed as INVALID, and apparently ibus won't be installed by default any longer). So closing this as fixed again.
(In reply to Stefan Dirsch from comment #131) > Ah. There is already such an ibus bug (basically closed as INVALID, and > apparently ibus won't be installed by default any longer). So closing this > as fixed again. boo#1073215