Bug 1046436

Summary: after installation in "german", desktop has english keyboard layout
Product: [openSUSE] openSUSE Tumbleweed Reporter: Marcus Meissner <meissner>
Component: InstallationAssignee: Ladislav Slezák <lslezak>
Status: RESOLVED FIXED QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P2 - High CC: axel.braun, behlert, cfd_s12, fbui, fcrozat, gerrysw11, gsouza, igonzalezsosa, jreidinger, kiyomi.kakitsubata, lslezak, mvidner, okurz, premislaus1988, slindomansilla, sndirsch, snwint, systemd-maintainers, theghost, thomas.blume, youpburden, zilti
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://trello.com/c/1KOZiQgM
See Also: http://bugzilla.suse.com/show_bug.cgi?id=1003618
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: /etc/sysconfig/language
/etc/sysconfig/keyboard
y2log-Z85vZ9.tar.xz

Description Marcus Meissner 2017-06-28 15:14:22 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
Comment 1 Marcus Meissner 2017-06-28 15:16:21 UTC
Created attachment 730600 [details]
/etc/sysconfig/language

/etc/sysconfig/language
Comment 2 Marcus Meissner 2017-06-28 15:16:43 UTC
Created attachment 730601 [details]
/etc/sysconfig/keyboard

/etc/sysconfig/keyboard
Comment 3 Marcus Meissner 2017-06-28 15:18:01 UTC
Created attachment 730602 [details]
y2log-Z85vZ9.tar.xz

yast2 logs
Comment 4 Steffen Winterfeldt 2017-07-05 13:56:52 UTC
*** Bug 1045880 has been marked as a duplicate of this bug. ***
Comment 5 Steffen Winterfeldt 2017-07-06 09:55:50 UTC
*** Bug 1047460 has been marked as a duplicate of this bug. ***
Comment 6 Steffen Winterfeldt 2017-07-06 09:56:50 UTC
raising priority as we get this report a lot
Comment 7 Steffen Winterfeldt 2017-07-06 09:57:38 UTC
*** Bug 1046967 has been marked as a duplicate of this bug. ***
Comment 8 Steffen Winterfeldt 2017-07-11 09:55:17 UTC
*** Bug 1048076 has been marked as a duplicate of this bug. ***
Comment 9 Steffen Winterfeldt 2017-07-11 14:09:49 UTC
tracking in yast trello board
Comment 10 Steffen Winterfeldt 2017-07-11 14:18:13 UTC
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'.
Comment 11 Lukas Ocilka 2017-07-11 15:13:19 UTC
The change was implemented as an answer to https://bugzilla.suse.com/show_bug.cgi?id=1023774

Stefan, what should we do then?
Comment 12 Stefan Dirsch 2017-07-11 20:43:43 UTC
(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. ;-)
Comment 13 Egbert Eich 2017-07-12 06:35:01 UTC
(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?
Comment 14 Thomas Blume 2017-07-12 07:32:25 UTC
(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).
Comment 15 Thomas Blume 2017-07-12 08:47:03 UTC
(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.
Comment 16 Franck Bui 2017-07-12 09:22:29 UTC
Or maybe the installer (and only the installer) could initialize /etc/vconsole.conf directly ?
Comment 17 Stefan Dirsch 2017-07-12 09:55:15 UTC
(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?
Comment 18 Franck Bui 2017-07-12 10:03:02 UTC
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.
Comment 19 Stefan Dirsch 2017-07-12 10:12:45 UTC
(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!
Comment 20 Franck Bui 2017-07-12 10:16:31 UTC
(In reply to Stefan Dirsch from comment #19)
> No, everything would be in an inconsistent state again!

could you refresh my memory  ? ;)
Comment 21 Thomas Blume 2017-07-12 11:41:03 UTC
(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?
Comment 22 Lukas Ocilka 2017-07-12 12:04:28 UTC
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)
Comment 23 Stefan Dirsch 2017-07-12 12:12:43 UTC
(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.
Comment 24 Steffen Winterfeldt 2017-07-12 12:40:12 UTC
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?
Comment 25 Franck Bui 2017-07-12 12:44:13 UTC
(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.
Comment 26 Lukas Ocilka 2017-07-12 12:53:28 UTC
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"...
Comment 27 Stefan Dirsch 2017-07-12 13:07:04 UTC
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.
Comment 28 Steffen Winterfeldt 2017-07-12 13:10:58 UTC
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.]
Comment 29 Thomas Blume 2017-07-12 13:20:00 UTC
(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.
Comment 30 Lukas Ocilka 2017-07-12 13:24:34 UTC
From YaST POV, option C is the cleanest one.
Comment 31 Franck Bui 2017-07-12 13:25:00 UTC
(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.
Comment 32 Thomas Blume 2017-07-12 13:52:28 UTC
(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
Comment 33 Kazufumi Watanabe 2017-07-18 06:35:26 UTC
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
Comment 34 Steffen Winterfeldt 2017-07-19 13:19:11 UTC
*** Bug 1032865 has been marked as a duplicate of this bug. ***
Comment 35 Kazufumi Watanabe 2017-07-20 06:01:04 UTC
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
Comment 36 P. Otato 2017-09-06 06:34:36 UTC
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.
Comment 37 buhtz buhtz 2017-09-21 20:37:20 UTC
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.
Comment 38 Stefan Dirsch 2017-09-21 21:21:42 UTC
Guys, may I ask you, why you expect a bug to be fixed, when it's still in an open and confirmed state?
Comment 39 buhtz buhtz 2017-09-21 22:44:14 UTC
Dear Stefan,
I don't understand your question.
Comment 40 Kazufumi Watanabe 2017-09-23 08:41:01 UTC
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.
Comment 41 buhtz buhtz 2017-09-24 09:32:14 UTC
Sorry I don't understand you. I sayed nothing about mac.
I tested this in VirtualBox.
Comment 42 Sergio Lindo Mansilla 2017-09-27 08:23:22 UTC
It also happens on SLE-15 Build278.1
Got during manual testing.
Comment 43 Sergio Lindo Mansilla 2017-09-27 09:05:41 UTC
It also happens selecting English language and German keyboard during installation.
I get an installed system with English keyboard.
Comment 44 Daniel Ziltener 2017-09-29 21:28:06 UTC
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?
Comment 45 Knut Alejandro Anderssen González 2017-10-04 09:10:43 UTC
*** Bug 1056701 has been marked as a duplicate of this bug. ***
Comment 46 Kazufumi Watanabe 2017-10-07 10:11:50 UTC
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
Comment 47 Sergio Lindo Mansilla 2017-10-09 06:30:16 UTC
For me it happens on physical laptop. Dell Latitude E6530
Comment 48 Lukas Ocilka 2017-10-09 08:45:18 UTC
(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 :)
Comment 49 Thomas Blume 2017-10-09 09:12:28 UTC
(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.
Comment 50 Daniel Ziltener 2017-10-09 11:26:38 UTC
Oh great - systemd has to be modified for that? That speaks volumes about that piece of, uhh, Software...
Comment 51 Lukas Ocilka 2017-10-18 07:42:35 UTC
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...
Comment 52 Thomas Blume 2017-10-18 08:09:04 UTC
(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?
Comment 53 Lukas Ocilka 2017-10-18 09:15:42 UTC
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.
Comment 54 Thomas Blume 2017-10-18 09:31:59 UTC
(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.
Comment 55 Thomas Blume 2017-10-18 10:27:13 UTC
(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
--<
Comment 56 Stefan Dirsch 2017-10-18 10:32:08 UTC
Nice! And which content do we have in 

  /etc/X11/xorg.conf.d/00-keyboard.conf

afterwards?
Comment 57 Thomas Blume 2017-10-18 10:52:44 UTC
(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.
Comment 58 Steffen Winterfeldt 2017-10-18 11:34:21 UTC
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

???
Comment 59 Josef Reidinger 2017-10-18 11:51:12 UTC
(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.
Comment 60 Steffen Winterfeldt 2017-10-18 12:02:08 UTC
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?
Comment 61 Thomas Blume 2017-10-18 12:20:04 UTC
(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
--<
Comment 62 Thomas Blume 2017-10-18 12:24:27 UTC
(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.
Comment 63 Steffen Winterfeldt 2017-10-18 12:36:54 UTC
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?
Comment 64 Josef Reidinger 2017-10-18 12:50:09 UTC
(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 ).
Comment 65 Stefan Dirsch 2017-10-18 13:02:45 UTC
(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!).
Comment 66 Stefan Dirsch 2017-10-18 13:05:37 UTC
See also comments #27 and #28.
Comment 67 Stefan Behlert 2017-10-18 13:38:46 UTC
So this sounds like one of the X packages needs to add a service running at startup?
Comment 68 Thomas Blume 2017-10-18 13:39:33 UTC
(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:~ #
-->
Comment 69 Stefan Dirsch 2017-10-18 15:25:55 UTC
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.
Comment 70 Stefan Dirsch 2017-10-18 15:32:20 UTC
But anyway, feel free to give it a try. Built packages are in 

  obs://X11:XOrg/xdm
Comment 73 Stefan Dirsch 2017-10-19 13:39:58 UTC
(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.
Comment 75 Frederic Crozat 2017-10-20 09:41:07 UTC
(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.
Comment 76 Thomas Blume 2017-10-20 09:54:19 UTC
(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?
Comment 77 Stefan Dirsch 2017-10-20 10:03:47 UTC
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.
Comment 79 Stefan Dirsch 2017-10-20 10:27:24 UTC
(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.
Comment 80 Frederic Crozat 2017-10-20 10:49:01 UTC
(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
Comment 81 Ladislav Slezák 2017-10-20 10:54:14 UTC
yast2-country has not been submitted yet, I'll do a quick test with the latest image and submit that.
Comment 82 Martin Vidner 2017-10-20 11:19:11 UTC
FYI, the yast2-country part is (still not submitted)
https://github.com/yast/yast-country/pull/145
Comment 83 Stefan Dirsch 2017-10-20 12:02:26 UTC
(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.
Comment 84 Ladislav Slezák 2017-10-20 12:31:25 UTC
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...
Comment 85 Stefan Dirsch 2017-10-20 12:38:48 UTC
(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?
Comment 86 Ladislav Slezák 2017-10-20 12:48:33 UTC
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.
Comment 87 Ladislav Slezák 2017-10-20 12:52:58 UTC
(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.
Comment 88 Ladislav Slezák 2017-10-20 12:54:22 UTC
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).
Comment 89 Thomas Blume 2017-10-20 13:10:42 UTC
(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?
Comment 91 Ladislav Slezák 2017-10-20 14:13:39 UTC
(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".)
Comment 92 Thomas Blume 2017-10-23 09:45:08 UTC
(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?
Comment 93 Ladislav Slezák 2017-10-23 11:34:41 UTC
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)
Comment 94 Ladislav Slezák 2017-10-23 11:56:40 UTC
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.
Comment 95 Thomas Blume 2017-10-23 12:49:42 UTC
(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?
Comment 96 Thomas Blume 2017-10-23 12:51:13 UTC
(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
Comment 98 Ladislav Slezák 2017-10-23 14:12:52 UTC
(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.)
Comment 99 Frederic Crozat 2017-10-23 14:16:21 UTC
(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..
Comment 100 Ladislav Slezák 2017-10-23 14:37:48 UTC
OK, the fix will be submitted in few minutes...
Comment 101 Ladislav Slezák 2017-10-23 14:55:16 UTC
Fixed in yast2-country-4.0.4 (https://github.com/yast/yast-country/pull/146)

SR: https://build.suse.de/request/show/144603
Comment 104 Ladislav Slezák 2017-10-25 08:17:59 UTC
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.)
Comment 105 Ladislav Slezák 2017-10-25 09:16:27 UTC
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...
Comment 106 Frederic Crozat 2017-10-25 09:23:25 UTC
(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
Comment 107 Stefan Behlert 2017-10-25 10:00:29 UTC
Looks good. Thanks.
Comment 108 Stefan Dirsch 2017-10-25 10:19:15 UTC
(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?
Comment 109 Sergio Lindo Mansilla 2017-10-25 13:01:51 UTC
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?
Comment 110 Stefan Dirsch 2017-10-25 14:37:32 UTC
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.
Comment 111 Frederic Crozat 2017-10-25 14:47:19 UTC
(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.
Comment 112 Stefan Dirsch 2017-10-25 15:29:19 UTC
(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 ???
Comment 113 Frederic Crozat 2017-10-25 15:37:34 UTC
(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.
Comment 115 Stefan Behlert 2017-10-25 15:40:58 UTC
(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.
Comment 116 Stefan Dirsch 2017-10-25 15:55:09 UTC
(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 ...
Comment 117 Stefan Dirsch 2017-10-25 16:53:43 UTC
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.
Comment 118 Stefan Dirsch 2017-10-26 13:18:00 UTC
(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
Comment 119 Oliver Kurz 2017-10-29 19:30:41 UTC
(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?
Comment 120 Sergio Lindo Mansilla 2017-10-30 09:10:44 UTC
(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?
Comment 121 Franck Bui 2017-10-30 09:14:51 UTC
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.
Comment 123 Gerry Gavigan 2017-12-15 11:05:55 UTC
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>
Comment 124 Daniel Ziltener 2017-12-18 10:27:51 UTC
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
Comment 125 Stefan Hundhammer 2017-12-18 18:43:48 UTC
*** Bug 1042423 has been marked as a duplicate of this bug. ***
Comment 126 Josef Reidinger 2017-12-29 14:29:16 UTC
*** Bug 1074168 has been marked as a duplicate of this bug. ***
Comment 127 Josef Reidinger 2017-12-29 15:25:11 UTC
*** Bug 1066507 has been marked as a duplicate of this bug. ***
Comment 128 Gerry Gavigan 2017-12-29 23:41:38 UTC
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
Comment 129 Stefan Dirsch 2018-01-08 20:22:06 UTC
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.
Comment 130 Stefan Dirsch 2018-01-09 13:11:31 UTC
And please close boo#1074168 as dup of this new ibus bug.
Comment 131 Stefan Dirsch 2018-01-09 13:15:17 UTC
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.
Comment 132 Stefan Dirsch 2018-01-09 13:16:48 UTC
(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