Wrong url, I meant https://github.com/yast/yast-firstboot/issues/33

I have made two Live media that were affected by that bug:

- openSUSE Leap 42.1-20160930

KIWI source code: https://github.com/kamarada/kiwi-config-Kamarada/releases/tag/42.1-20160930

- openSUSE Leap 42.2-Beta2-20160923

KIWI source code: https://github.com/kamarada/kiwi-config-Kamarada/releases/tag/42.2-Beta2-20160923

They can be downloaded here:

https://sourceforge.net/projects/kamarada/

Not sure if this is related, but when I finish YaST Firstboot, tty1 shows:

/usr/lib/YaST2/startup/Firstboot-Stage/S09-cleanup: line 48: /etc/init.d/kbd: No such file or directory

That happens only with openSUSE Leap 42.1.

1) I cannot reproduce this in a pristine Leap 42.2 beta2 (DVD version). I'm downloading Kamarada now to double check.

2) I have a question. Being a liveCD, are the settings of the live user copied to the installed system? In that case my guess is that the system-wide keyboard is actually changed but the user-specific configuration retains the old value. That's the expected behavior for both Plasma and Gnome. YaST can't do anything about it. To check whether that's the problem, please create a new user after having changed the layout with YaST Firstboot (a user that didn't exist originally when the system was still en_US) and login with that new user.

3) Both the reporter of this bug and bug#1004506 seem to assume YaST should update the KEYTABLE value in /etc/sysconfig/keyboard, but that's not the case. Currently, YaST performs this two operations on every layout change:
 - To configure console (text mode) keyboard it writes the KEYMAP value in /etc/vconsole.conf
 - To configure X11 it calls "localectl set-x11-keymap"

AFAIK, the localectl call modifies /etc/X11/xorg.conf.d/00-keyboard.conf but not the mostly legacy /etc/sysconfig/keyboard. Can you check the content of 00-keyboard.conf in your system?

If some component (Plasma, GNOME or whatever) is ignoring a correct value in 00-keyboard.conf that was set via localectl only because there is an empty KEYTABLE entry in /etc/sysconfig/keyboard, it looks like a bug in that component to me.

Please, paste also the output of this command in an affected system:

localectl

I downloaded the Kamarada image and this doesn't look as a yast2-firstboot bug. Or at least, it's far from being "yast2-firstboot does not store keyboard layout".

First thing I would like to mention is that I hadn't understand the use-case completely. You are not running yast2-bootloader after installing the system to the hard disk, but directly on the live instance. That's why my previous check with a pristine Leap DVD and my question labeled as (2) in comment#4 make no sense here.

Second thing I want to say is that it actually works perfectly and flawlessly if you select Spanish or German instead of Brazilian Portuguese. So the problem seems to be specific to the "br" keymap.

As can be inferred from the second point, yast2-firsboot is doing its part of the job. If you run "localectl" you will see:
     System Locale: n/a

       VC Keymap: br
      X11 Layout: br
       X11 Model: microsoftpro
     X11 Variant: basic
     X11 Options: terminate:ctrl_alt_bksp

And if you inspect the content of /etc/X11/xorg.conf.d/00-keyboard.conf you will see that the configuration there is also consistent with localectl.

That should have been enough for your keyboard to be in Portuguese. At least a value of "es" provides a perfectly Spanish keyboard, a value of "de" provides German keyboard and so on. So something is wrong with the "br" keymap in Kamarada (a problem that seems to not affect a pristine 42.2beta, according to my tests).

(In reply to Ancor Gonzalez Sosa from comment #6)
>
> That should have been enough for your keyboard to be in Portuguese. At least
> a value of "es" provides a perfectly Spanish keyboard, a value of "de"
> provides German keyboard and so on. So something is wrong with the "br"
> keymap in Kamarada (a problem that seems to not affect a pristine 42.2beta,
> according to my tests).

I was wrong in this last point. I have just tried to use YaST to change keyboard to Brazilian Portuguese in a recently installed 42.2beta3 and the result in X11 is not the expected one.

localectl reports "X11 Layout: br" and the corresponding line in 00-keyboard.conf also looks sane, but I'm not able to enter Portuguese accents.

Reopening and reassigning, since I expect Stefan to know better than me what's going on.

You can try with geometry abnt2, but I don't see a difference to the one with pc015.

  setxkbmap -geometry "pc(abnt2)" -layout "br(abnt2)" -v

vs. 

  setxkbmap -geometry "pc(pc105)" -layout "br" -v

Both work for me in gnome-terminal.

Sorry for the delay, but only now I've got time to test things and answer as I would like.

(In reply to Ancor Gonzalez Sosa from comment #4)
> 1) I cannot reproduce this in a pristine Leap 42.2 beta2 (DVD version). I'm
> downloading Kamarada now to double check.

Indeed, a clean install is not affected. I downloaded openSUSE Leap 42.2 RC Network installation medium from https://software.opensuse.org/developer/ and made a clean install on a VirtualBox virtual machine. I chose Português (Brasil) / Portuguese (Brazil) as my keyboard layout during setup. It got applied when the installation finished and I got to the desktop environment.

> 2) I have a question. Being a liveCD, are the settings of the live user
> copied to the installed system? In that case my guess is that the
> system-wide keyboard is actually changed but the user-specific configuration
> retains the old value. That's the expected behavior for both Plasma and
> Gnome. YaST can't do anything about it. To check whether that's the problem,
> please create a new user after having changed the layout with YaST Firstboot
> (a user that didn't exist originally when the system was still en_US) and
> login with that new user.

Please note that there is no previous configuration for the Plasma desktop and the live user (called linux). When system finishes booting and reaches desktop, that is an entirely new session, as if it was the first time the user logged in. Also, it is interesting to note that, being a live system, a fresh session will always be started unless a persistent LiveUSB is being used.

As a test, I booted the live system (for reference, Kamarada's openSUSE Leap 42.2 RC 1 LiveDVD with KDE, released on 2016-10-18) and in YaST Firstboot I selected everything as I described on my report. Right after reaching the graphical interface, I used YaST to create a new user called gecko, then I logged out linux and logged in gecko. The Brazilian Portuguese keyboard layout (supposedly system-wide applied) was not applied to the gecko user's first session.

> 3) Both the reporter of this bug and bug#1004506 seem to assume YaST should
> update the KEYTABLE value in /etc/sysconfig/keyboard, but that's not the
> case. Currently, YaST performs this two operations on every layout change:
>  - To configure console (text mode) keyboard it writes the KEYMAP value in
> /etc/vconsole.conf

Continuing the test I described above, using the live system and logged in as the gecko user, I started Konsole and issued the following commands:

gecko@linux:~> cat /etc/vconsole.conf
KEYMAP=br
gecko@linux:~>

(that file actually had only that line)

>  - To configure X11 it calls "localectl set-x11-keymap"
> 
> AFAIK, the localectl call modifies /etc/X11/xorg.conf.d/00-keyboard.conf but
> not the mostly legacy /etc/sysconfig/keyboard. Can you check the content of
> 00-keyboard.conf in your system?

gecko@linux:~> cat /etc/X11/xorg.conf.d/00-keyboard.conf 
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "br"
        Option "XkbModel" "microsoftpro"
        Option "XkbVariant" "basic"
        Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection
gecko@linux:~>

> If some component (Plasma, GNOME or whatever) is ignoring a correct value in
> 00-keyboard.conf that was set via localectl only because there is an empty
> KEYTABLE entry in /etc/sysconfig/keyboard, it looks like a bug in that
> component to me.

(In reply to Ancor Gonzalez Sosa from comment #5)
> Please, paste also the output of this command in an affected system:
> 
> localectl

gecko@linux:~> localectl
   System Locale: n/a

       VC Keymap: br
      X11 Layout: br
       X11 Model: microsoftpro
     X11 Variant: basic
     X11 Options: terminate:ctrl_alt_bksp
gecko@linux:~>

(In reply to Ancor Gonzalez Sosa from comment #6)
> I downloaded the Kamarada image and this doesn't look as a yast2-firstboot
> bug. Or at least, it's far from being "yast2-firstboot does not store
> keyboard layout".
> 
> First thing I would like to mention is that I hadn't understand the use-case
> completely. You are not running yast2-bootloader after installing the system
> to the hard disk, but directly on the live instance. That's why my previous
> check with a pristine Leap DVD and my question labeled as (2) in comment#4
> make no sense here.

Yes. All the steps described at the beginning of my report were performed on a live system. What maybe sounded confusing was what I said at the end:

"I installed openSUSE Leap 42.1 on my laptop a few months ago. Every time I boot it up with openSUSE, I need to change the keyboard layout as described above before actually using it."

Let me explain that. I used the LiveDVD I built myself to install openSUSE Leap 42.1 on my own laptop. Similar behavior was observed on my hard drive installation. Brazilian Portuguese keyboard layout was not applied during boot. Everyday, I needed to change keyboard layout using YaST before actually being able to type anything. I ended up reinstalling openSUSE Leap 42.1, now using an official Network installation medium.

> Second thing I want to say is that it actually works perfectly and
> flawlessly if you select Spanish or German instead of Brazilian Portuguese.
> So the problem seems to be specific to the "br" keymap.

Interesting. I have not tested any keyboard layout other than Brazilian Portuguese. But is it safe to conclude that a keyboard layout is working by testing it with a keyboard that actually has another layout? (e.g. I want to test the Spanish keyboard layout, but I'm actually using a Brazilian keyboard)

> As can be inferred from the second point, yast2-firsboot is doing its part
> of the job. If you run "localectl" you will see:
>      System Locale: n/a
> 
>        VC Keymap: br
>       X11 Layout: br
>        X11 Model: microsoftpro
>      X11 Variant: basic
>      X11 Options: terminate:ctrl_alt_bksp
> 
> And if you inspect the content of /etc/X11/xorg.conf.d/00-keyboard.conf you
> will see that the configuration there is also consistent with localectl.

That is true. But still trying to type "acentuação" does not give me what I expect. Instead, it shows "acentua;'ao".

> That should have been enough for your keyboard to be in Portuguese. At least
> a value of "es" provides a perfectly Spanish keyboard, a value of "de"
> provides German keyboard and so on. So something is wrong with the "br"
> keymap in Kamarada (a problem that seems to not affect a pristine 42.2beta,
> according to my tests).

But I did not provide any keyboard layout file. What is different from a pristine openSUSE Leap installation? Maybe is the langset service (https://github.com/kamarada/kiwi-config-Kamarada/commit/2f5c8ba69731b016899c93f34542b0de009290d6) conflicting with YaST Firstboot?

(In reply to Ancor Gonzalez Sosa from comment #7)
> I was wrong in this last point. I have just tried to use YaST to change
> keyboard to Brazilian Portuguese in a recently installed 42.2beta3 and the
> result in X11 is not the expected one.
> 
> localectl reports "X11 Layout: br" and the corresponding line in
> 00-keyboard.conf also looks sane, but I'm not able to enter Portuguese
> accents.
> 
> Reopening and reassigning, since I expect Stefan to know better than me
> what's going on.

I would like to repeat your test here, but for it to be unbiased, it would take me to format my VirtualBox VM, reinstall openSUSE Leap 42.2 from scratch (and download all the packages again), set it up to use the English keyboard layout, then when it was ready try to change the keyboard layout to Brazilian Portuguese. If you want, I can do that test, but by now let's say I prefer to stay with yours :D

(In reply to Stefan Dirsch from comment #8)
> You can try with geometry abnt2, but I don't see a difference to the one
> with pc015.
> 
>   setxkbmap -geometry "pc(abnt2)" -layout "br(abnt2)" -v
> 
> vs. 
> 
>   setxkbmap -geometry "pc(pc105)" -layout "br" -v
> 
> Both work for me in gnome-terminal.

Indeed, both of those commands worked for me in Konsole (I typed "acentuação" just as a test):

gecko@linux:~> setxkbmap -geometry "pc(abnt2)" -layout "br(abnt2)" -v
Warning! Multiple definitions of keyboard layout
         Using command line, ignoring X server
Warning! Multiple definitions of geometry
         Using command line, ignoring rules file
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+br(abnt2)+inet(evdev)+terminate(ctrl_alt_bksp)+terminate(ctrl_alt_bksp)
geometry:   pc(abnt2)
gecko@linux:~> acentuação^C
gecko@linux:~> setxkbmap -geometry "pc(pc105)" -layout "br" -v
Warning! Multiple definitions of keyboard layout
         Using command line, ignoring X server
Warning! Multiple definitions of geometry
         Using command line, ignoring rules file
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+br+inet(evdev)+terminate(ctrl_alt_bksp)+terminate(ctrl_alt_bksp)
geometry:   pc(pc105)
gecko@linux:~> acentuação
If 'acentuação' is not a typo you can use command-not-found to lookup the package that contains it, like this:
    cnf acentuação
gecko@linux:~>

Using Kamarada's openSUSE Leap 42.1 LiveDVD with KDE (released on 2016-09-30) gives me similar results:

gecko@linux:~> cat /etc/vconsole.conf
KEYMAP=br-abnt2
gecko@linux:~> cat /etc/X11/xorg.conf.d/00-keyboard.conf 
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "br"
        Option "XkbModel" "microsoftpro"
        Option "XkbVariant" "basic"
EndSection
gecko@linux:~> localectl
   System Locale: LC_CTYPE=en_US.UTF-8
       VC Keymap: br-abnt2
      X11 Layout: br
       X11 Model: microsoftpro
     X11 Variant: basic
gecko@linux:~> setxkbmap -geometry "pc(abnt2)" -layout "br(abnt2)" -v
Warning! Multiple definitions of keyboard layout
         Using command line, ignoring X server
Warning! Multiple definitions of geometry
         Using command line, ignoring rules file
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+br(abnt2)+inet(evdev)+terminate(ctrl_alt_bksp)
geometry:   pc(abnt2)
gecko@linux:~> acentuação^C
gecko@linux:~> setxkbmap -geometry "pc(pc105)" -layout "br" -v
Warning! Multiple definitions of keyboard layout
         Using command line, ignoring X server
Warning! Multiple definitions of geometry
         Using command line, ignoring rules file
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+br+inet(evdev)+terminate(ctrl_alt_bksp)
geometry:   pc(pc105)
gecko@linux:~> acentuação
If 'acentuação' is not a typo you can use command-not-found to lookup the package that contains it, like this:
    cnf acentuação
gecko@linux:~>

I hope my answers help us find what's going on.

Thank you for your efforts so far!

Interesting is the line:

   System Locale: LC_CTYPE=en_US.UTF-8

in the output of localectl while using Kamarada's openSUSE Leap 42.1 LiveDVD.

Maybe it can be explained by that line in KIWI's config.xml for my openSUSE Leap 42.1 LiveDVD:

    <locale>en_US</locale>

which is not present in the config.xml file for my openSUSE Leap 42.2 LiveDVD.

But shouldn't that setting be overriden when I select Brazilian Portuguese (pt_BR) as my locale in YaST Firstboot?

Sources for comparison:

- openSUSE Leap 42.1 LiveDVD's config.xml

https://github.com/kamarada/kiwi-config-Kamarada/blob/42.1-20160930/source/config.xml

- openSUSE Leap 42.2 LiveDVD's config.xml

https://github.com/kamarada/kiwi-config-Kamarada/blob/42.2-RC1-20161018/source/config.xml

Those same commands ran on my laptop (before openSUSE 42.1, installed using the official Network installation medium, as I said, and nowadays openSUSE 42.2 RC 1, upgraded this week following instructions available at https://en.opensuse.org/SDB:System_upgrade):

viny@viny-notebook:~> cat /etc/vconsole.conf
KEYMAP=br-abnt2
viny@viny-notebook:~> cat /etc/X11/xorg.conf.d/00-keyboard.conf
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "br"
        Option "XkbModel" "abnt2"
        Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection
viny@viny-notebook:~> localectl
   System Locale: LC_CTYPE=pt_BR.UTF-8
       VC Keymap: br-abnt2
      X11 Layout: br
       X11 Model: abnt2
     X11 Options: terminate:ctrl_alt_bksp
viny@viny-notebook:~>

And those same commands ran on the VirtualBox virtual machine I just set up (openSUSE Leap 42.2 RC 1, clean install using the official Network installation medium, as I said):

kamarada@linux:~> cat /etc/vconsole.conf
KEYMAP=br
kamarada@linux:~> cat /etc/X11/xorg.conf.d/00-keyboard.conf
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "br"
        Option "XkbModel" "microsoftpro"
        Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection
kamarada@linux:~> localectl
   System Locale: LC_CTYPE=pt_BR.UTF-8
       VC Keymap: br
      X11 Layout: br
       X11 Model: microsoftpro
     X11 Options: terminate:ctrl_alt_bksp
kamarada@linux:~>

I will also check the output of those commands on the desktop I use at work. I also use openSUSE there :D

On the desktop I use at work, the outputs of

$ cat /etc/vconsole.conf
$ cat /etc/X11/xorg.conf.d/00-keyboard.conf
$ localectl

match the ones I got on my laptop. They were installed the same way, maybe that explains (openSUSE Leap 42.1 using Network install then openSUSE Leap 42.2 RC 1 using zypper dup).

Not sure if I was clear, but in the last 3 tests I ran (my laptop, the VirtualBox VM and the computer I use at work) I did not use the live system. openSUSE was booted from the hard drive. Those commands were run on installations in which the Brazilian Portuguese keyboard layout works as expected.

I observe that on both openSUSE Leap 42.1 and openSUSE Leap 42.2 RC 1 live systems their outputs are different.

Not much I can add here. Just the information, that keyboard value in /etc/vconsole.conf must not be written not using localectl. There is no reliable way reading it afterwards and setting this then via 'localectl set-x11-keymap/set-keymap <KEYMAP>'. YaST needs to run locaectl directly with the preferred keyboard layout. The keymap in /etc/vconsole.conf then will also be written by localectl.

This is boo#1023774.

So it looks like we'll have to do that differently in the inst-sys where there is no systemd running (so I guess localectl won't work there) than later in the installed system where we now need localectl.

Now tracking in Trello to integrate this task in our scrum team workflow:

  https://trello.com/c/6fFTGo5o

Hope this bugreport gets updated once there is an update available in Trello. I have no access to this Trello task.

Yes, of course. Bugzilla is our primary comminication medium for bugs. Trello is used to schedule tasks in our scrum sprints, not for general communication.

Did this now a become a duplicate of boo#1046436? ;-)

IMO this is really a dup of boo#1046436 ...

This is automated batch bugzilla cleanup.

The openSUSE 42.3 changed to end-of-life (EOL [1]) status. As such
it is no longer maintained, which means that it will not receive any
further security or bug fix updates.
As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
openSUSE (At this moment openSUSE Leap 15.1, 15.0 and Tumbleweed) please
feel free to reopen this bug against that version (!you must update the
"Version" component in the bug fields, do not just reopen please), or
alternatively create a new ticket.

Thank you for reporting this bug and we are sorry it could not be fixed
during the lifetime of the release.

[1] https://en.opensuse.org/Lifetime