Bug 23877 - Mga-7-beta-1 classical installer: French AZERTY layout is not working when entering root + user login/password
Summary: Mga-7-beta-1 classical installer: French AZERTY layout is not working when en...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: release_blocker major
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
: 23909 23916 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-11-21 18:29 CET by Sébastien Morin
Modified: 2018-12-11 20:39 CET (History)
5 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
Patch that fixes this bug (702 bytes, text/plain)
2018-11-28 00:24 CET, Martin Whitaker
Details
report.bug.xz (215.49 KB, application/x-xz)
2018-12-08 15:38 CET, Stig-Ørjan Smelror
Details
ddebug.log.xz (167.44 KB, application/x-xz)
2018-12-08 15:39 CET, Stig-Ørjan Smelror
Details

Description Sébastien Morin 2018-11-21 18:29:57 CET
Description of problem:
I was testing the installation of Mageia-7-beta1-x86_64.iso in a VirtualBox and realized the keyboard is still QWERTY even if I select "French (azerty standard)" or "French (azerty latin9)".


Version-Release number of selected component (if applicable):
Mageia-7-beta1-x86_64.iso


How reproducible:
always

Steps to Reproduce the 1st attempt
1. Choose French language from Boot menu, then "Installation"
2. When asked for the keyboard layout, keep the default "French (azerty standard" (a closing bracket is also missing, by the way)
3. When prompted for root password, username, user login and password, realize that the keyboard layout is still qwerty. Azerty is available in DE after reboot (tested with KDE and Gnome).


Steps to Reproduce the 2nd attempt:
1. Choose French language from Boot menu, then "Installation"
2. When asked for the keyboard layout, choose "French (azerty latin9)"
3. When prompted for root password, username, user login and password, realize that the keyboard layout is still qwerty. Azerty becomes available in DE after reboot (tested with Gnome).
Sébastien Morin 2018-11-21 18:30:25 CET

Priority: Normal => release_blocker

Comment 1 Martin Whitaker 2018-11-21 19:08:52 CET
I have reproduced this fault, again in VirtualBox. Switching to the shell on vt2, I find the French keyboard layout has been correctly selected, as shown by typing and by the output of 'setxkbmap -query'. So it seems that the change of layout is not being passed to / acted on by mutter. In case this was a regression in mutter, I created a patched installer stage2 that contained the Mageia 6 version of mutter, but that didn't help.

CC: sysadmin-bugs => mageia
Component: Release (media or process) => Installer
Summary: Mga-7-beta-1 : French AZERTY layout is not working when entering root + user login/password => Mga-7-beta-1 classical installer: French AZERTY layout is not working when entering root + user login/password
Assignee: bugsquad => mageiatools

Comment 2 Frédéric Buclin 2018-11-21 22:54:31 CET
Is this a duplicate of bug 22745?
Comment 3 Sébastien Morin 2018-11-22 06:23:24 CET
(In reply to Frédéric Buclin from comment #2)
> Is this a duplicate of bug 22745?

It looks very similar to what George described in bug 23632 indeed.
Comment 4 Martin Whitaker 2018-11-22 09:42:43 CET
Not sure about bug 22745 - Frédéric sees the keyboard layout get changed, but to the wrong layout, whereas here we are seeing no layout change.

Frédéric, could you try booting the installer then, after selecting the keyboard and reaching the partitioning choice screen, switch to the console on vt2 (Ctrl-Alt-F2 on real hardware, or RightCtrl-F2 in Vbox), and see if the keyboard layout is correct there by executing the command

  setxkbmap -query -display :0

But 23632 does look similar, but when I tested this with the Mageia 6 installer ISO, it worked fine.
Comment 5 Martin Whitaker 2018-11-28 00:24:52 CET
Created attachment 10511 [details]
Patch that fixes this bug
Comment 6 Martin Whitaker 2018-11-28 00:30:10 CET
The key mapping is set correctly in the partitioning step, but gets reset to 'us' by the time we reach the user/password step. My guess is that some package is resetting the mapping in a post-install scriptlet.

@Thierry, if you can think of a way to identify which package is the culprit, we could fix it in that package. If not, the attached patch will fix the problem, by reapplying the selected key mapping after the package installation step finishes.

CC: (none) => thierry.vignaud
Keywords: (none) => PATCH

Comment 7 Thierry Vignaud 2018-11-28 17:17:13 CET
Strange.
Might be the call to /usr/sbin/mageia-setup-keyboard in keyboard::write()
Comment 8 Manuel Hiebel 2018-11-28 20:36:15 CET
*** Bug 23916 has been marked as a duplicate of this bug. ***

CC: (none) => smelror

Comment 9 Martin Whitaker 2018-11-29 00:56:57 CET
(In reply to Thierry Vignaud from comment #7)
> Might be the call to /usr/sbin/mageia-setup-keyboard in keyboard::write()

I already looked at that, but it doesn't do anything when run in the installer (/etc/sysconfig/keyboard doesn't exist, so it just exits).
Comment 10 Martin Whitaker 2018-12-01 21:41:57 CET
(In reply to Martin Whitaker from comment #9)
> (In reply to Thierry Vignaud from comment #7)
> > Might be the call to /usr/sbin/mageia-setup-keyboard in keyboard::write()
> 
> I already looked at that, but it doesn't do anything when run in the
> installer (/etc/sysconfig/keyboard doesn't exist, so it just exits).

And changing the patch to restore the keyboard layout as the first post-install action still fixes the bug.

Unless you have any better ideas, I'll commit this fix. I've already patched the next round of beta1 ISOs to include it.
Comment 11 Thierry Vignaud 2018-12-01 22:43:49 CET
You could debug it by replacing setxkbmap by a script:
- calling setxkbmap.real (renamed bin) on first run
- logging subsequent calls (args, PPID, ...)
Comment 12 Marja Van Waes 2018-12-02 15:22:42 CET
*** Bug 23909 has been marked as a duplicate of this bug. ***

CC: (none) => hamnisdude

Comment 13 Martin Whitaker 2018-12-05 00:04:22 CET
(In reply to Thierry Vignaud from comment #11)
> You could debug it by replacing setxkbmap by a script:
> - calling setxkbmap.real (renamed bin) on first run
> - logging subsequent calls (args, PPID, ...)

I don't have time for this. If you do, please go ahead. If not, please accept the simple fix. I really don't want to have to keep patching stage2 manually each time I build the ISOs.
Comment 14 Sébastien Morin 2018-12-05 14:45:56 CET
This bug seems to be fixed with Mageia-7-beta1-x86_64.iso "round 4".
Comment 15 Stig-Ørjan Smelror 2018-12-05 14:47:41 CET
(In reply to Sébastien Morin from comment #14)
> This bug seems to be fixed with Mageia-7-beta1-x86_64.iso "round 4".

It's not fixed, per se, as Martin patches something before generating the ISO's.

Cheers,
Stig
Comment 16 Lewis Smith 2018-12-06 15:54:35 CET
M7b2 Classic ISO 4 Dec 2018 x64
Confirm c14, the problem has gone. But re c15, I agree it should be fixed properly before closure. Certainly we cannot have last-minute patches for it.

CC: (none) => lewyssmith

Comment 17 Thierry Vignaud 2018-12-06 16:52:29 CET
Yeah but we need a real fix...
Comment 18 Stig-Ørjan Smelror 2018-12-06 22:33:17 CET
I'm still having issues.

System lang set to en, with Norwegian as a second option.
I chose Norwegian keyboard and it still wrote "Stig:\" when I tried to write "Stig-Ø"

Will now try with a pure Norwegian setup and see how it goes.
Comment 19 Stig-Ørjan Smelror 2018-12-06 22:47:23 CET
Same issue with a pure Norwegian setup.

"Stig/:" instead of "Stig-Ø". Got it wrong in comment 18.
Comment 20 Martin Whitaker 2018-12-08 11:59:00 CET
(In reply to Stig-Ørjan Smelror from comment #18)
> I'm still having issues.
> 
> System lang set to en, with Norwegian as a second option.
> I chose Norwegian keyboard and it still wrote "Stig:\" when I tried to write
> "Stig-Ø"

I've just tested this in Vbox, using the Mageia-7-beta1-x86_64.iso from 4th December (md5sum 0e7ccb8786cade01e006f5e675a6cd2b), and the Norwegian keyboard layout was still active when I reached the user management screen.

If you switch to the console (Ctrl-Alt-F2), is the keyboard layout wrong there too? What does

  setxkbmap -display :0 -query

report?

If you boot into the installed system, what keyboard layout is selected?

Please attach a copy of /root/drakx/ddebug.log.
Comment 21 Martin Whitaker 2018-12-08 12:00:08 CET
(In reply to Thierry Vignaud from comment #17)
> Yeah but we need a real fix...

No, we need to release Mageia 7. For that, all we *need* is a fix that works.
Comment 22 Stig-Ørjan Smelror 2018-12-08 15:38:10 CET
Created attachment 10536 [details]
report.bug.xz

(In reply to Martin Whitaker from comment #20)
> 
>   setxkbmap -display :0 -query
> 

On my first try, I got "en".

Then I set "LANG=nb_NO.UTF-8 vmplayer" and keyboard layout was set to "no" until I clicked "Next". It was then reset to "en".

So it gets set, but then reset in Vmware Player. It boots into a working system with system lang "en" and kbd layout "no".

Cheers,
Stig
Comment 23 Stig-Ørjan Smelror 2018-12-08 15:39:20 CET
Created attachment 10537 [details]
ddebug.log.xz
Comment 24 Martin Whitaker 2018-12-08 16:44:59 CET
(In reply to Stig-Ørjan Smelror from comment #22)
> Created attachment 10536 [details]
> report.bug.xz
> 
> (In reply to Martin Whitaker from comment #20)
> > 
> >   setxkbmap -display :0 -query
> > 
> 
> On my first try, I got "en".
> 
> Then I set "LANG=nb_NO.UTF-8 vmplayer" and keyboard layout was set to "no"
> until I clicked "Next". It was then reset to "en".

I've never used vmplayer, but if setting LANG outside the VM affects the behaviour inside the VM, it's not a very good virtual machine.
Comment 25 Martin Whitaker 2018-12-08 21:20:00 CET
I've now tested this using vmplayer. After selecting the keyboard layout as Norwegian, I get Norwegian layout in both the custom partitioning stage and in the user/password stage, i.e. the fix is working for me.

BTW, to get to the installer console in vmplayer, the key combination is Ctrl-Alt-Space-F2
Comment 26 Martin Whitaker 2018-12-08 21:25:55 CET
However, I have now identified what is resetting the keyboard layout. It is the 'udevadm trigger --type=devices' that is called at the end of the formatting step.
Martin Whitaker 2018-12-08 21:54:34 CET

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=23946

Comment 27 Kristoffer Grundström 2018-12-08 23:31:07 CET
I have seen this for Swedish with QWERTY as well in the net iso installer before.
Comment 28 Thierry Vignaud 2018-12-10 11:15:29 CET
(In reply to Martin Whitaker from comment #26)
> However, I have now identified what is resetting the keyboard layout. It is
> the 'udevadm trigger --type=devices' that is called at the end of the
> formatting step.

Nice catch :-) !

Now the questions are:
Why is this suddenly an issue?
And how to fix/workaround it?
Comment 29 Thierry Vignaud 2018-12-10 11:16:55 CET
Maybe using --subsystem-match=SUBSYSTEM or better blacklisting input stuff using --subsystem-nomatch=SUBSYSTEM if DURING_INSTALL is set?
Comment 30 Thierry Vignaud 2018-12-10 11:33:04 CET
aka using either --subsystem-match=block or --subsystem-nomatch=input
(to be tested)
Comment 31 Thierry Vignaud 2018-12-10 11:35:59 CET
To answer comment #28, it's probably since we include input rules (aka since February)
Comment 32 Martin Whitaker 2018-12-10 21:38:18 CET
I've confirmed that --subsystem-match=block fixes this bug and doesn't reintroduce bug 22059.

This won't help bug 23946 - that one is triggered by the call to mageia-setup-keyboard.
Comment 33 Thierry Vignaud 2018-12-11 06:25:22 CET
Cool, can you commit that?
Martin Whitaker 2018-12-11 20:25:24 CET

Attachment 10511 is obsolete: 0 => 1

Comment 34 Martin Whitaker 2018-12-11 20:27:17 CET
Fixed in git (the bot still isn't working :-( )

Keywords: PATCH => (none)

Comment 35 Stig-Ørjan Smelror 2018-12-11 20:39:18 CET
Awesome. Now we wait for the new images with the new kernel to become available :-)

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