Description of problem: Installing [directly from boot menu], chossing AZERTY k/b, this is ignored for the subsequent disc partitioning phase which reverts to QWERTY. Version-Release number of selected component (if applicable): 7beta1 Gnome Live dated 2 Dec 2018. If the same is true for other Live ISOs, please remove 'Gnome' from the bug title. How reproducible: Did it just once. Might repeat the installation to confirm. Steps to Reproduce: 1. Choose non-QWERTY k/b at installation start e.g. AZERTY. 2. At disc partitioning, choose an option which requires k/b input e.g. disc label. 3. Type anything non-QWERTY, it shows as QWERTY.
Looks similar to bug 23877, doesn't it? It seems the keyboard layout switches back to QWERTY even before the password screen.
CC: (none) => sebsweb
(In reply to Sébastien Morin from comment #1) > Looks similar to bug 23877, doesn't it? > It seems the keyboard layout switches back to QWERTY even before the > password screen. Not closing this report as duplicate, because it might need a different fix for the Live ISOs than for the classical ISOs. The isobuilders will close it as duplicate, when appopriate.
CC: (none) => marja11Keywords: (none) => 7beta1Assignee: bugsquad => isobuild
(In reply to Sébastien Morin from comment #1) > Looks similar to bug 23877, doesn't it? > It seems the keyboard layout switches back to QWERTY even before the > password screen. No, with the classical installer the keyboard layout was correctly set at the partitioning screen (see bug 23877 comment 6). Switching to a tty login screen, the console keyboard layout has been changed, but the X keyboard layout (reported by 'setxkbmap -display :0 -query') has not. This bug also exists on the Mageia 6 and 6.1 Live ISOs.
CC: (none) => mageia
Here it is the 'udevadm trigger --subsystem-match=input --action=add' called by /sbin/mageia-setup-keyboard that is resetting the keyboard layout, so this is related to bug 23877 even though the trigger conditions are different.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=23877
What calls mageia-setup-keyboard here? install::steps::selectKeyboard() -> keyboard::write() ? A check for $::isLiveInstall before running it in keyboard.pm might do it
CC: (none) => thierry.vignaud
Created attachment 10548 [details] do not run mageia-setup-keyboard on live install (untested)
mageia-setup-keyboard is also not working when using drakkeyboard in the live system. 'udevadm info /dev/input/event0' shows that it is setting the xkb* variables, but nothing seems to be acting on them. Despite spending some time searching last night, I've not managed to find what is supposed to read and act upon those.
Same is true on a Mageia 6.1 Live system, but not on my installed system.
(In reply to Thierry Vignaud from comment #6) > Created attachment 10548 [details] > do not run mageia-setup-keyboard on live install That won't work as it stands because the keyboard::write() is being called during finish-install, not draklive-install.
Attachment 10548 is obsolete: 0 => 1
Further testing indicates mageia-setup-keyboard doesn't have any effect nowadays. Some DEs (I've tested Cinnamon and Xfce) support user keyboard layout settings which get applied when an input device is added (I'm guessing the DE settings daemon listens for input add events). Other DEs (e.g. IceWM) don't, and then the original keyboard layout (set when the X server started) gets applied. Nothing appears to pay attention to the Xkb* variables set by mageia-setup-keyboard. So unless someone can prove me wrong, I suggest this bug is fixed by removing mageia-setup-keyboard altogether.
@Thierry, WDYT? Is there any reason to keep mageia-setup-keyboard?
Assignee: isobuild => mageiatoolsSummary: Gnome Live installer ignores non-QWERTY keyboard for disc partitioning => Live installer ignores non-QWERTY keyboard for disc partitioning
Well, it' still supposed to be called by udev: $ cat /lib/udev/rules.d/61-x11-input.rules SUBSYSTEM!="input", GOTO="x11_input_end" ACTION!="add", GOTO="x11_input_end" KERNEL!="event*", GOTO="x11_input_end" ENV{ID_INPUT_KEY}=="1", IMPORT{program}="/sbin/mageia-setup-keyboard --udev" It relies on /etc/sysconfig/keyboard generated by keyboardrake When not run via udev, it calls udevadm trigger to import the keyboard settings into the udev database which are subsequently read by evdev etc. when loading. The thing is: does libinput works the same way as evdev was? Or it might be some other breakage. Eg it broke several times when xserver got updated (eg: 1.9 in 2010 or when udev got merged in systemd...
As commented above, it is being called by udev and correctly sets the variables. But nothing seems to be paying attention to those variables now...
MGA7b2.2 start Feb 2019 Live Gnome x64 During installation, having initially declared a French k/b, I specifically tested this point - and the correct k/B layout *was* respected during the disc partitioning stage. Thanks, closing this bug.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
This bug was never fixed, and is still present in 8-rc, reported by two people, and reproduced by me. Seen on both the Plasma and Xfce Live, running installer from the boot menu.
Resolution: FIXED => (none)Status: RESOLVED => REOPENEDKeywords: 7beta1 => 8rc1
*** Bug 28249 has been marked as a duplicate of this bug. ***
I have fixed this in a similar way to comment 6, but disabling the execution of mageia-setup-keyboard whenever running on a Mageia live system, not just when running draklive-install.
Status comment: (none) => fixed in git
Did this make it into RC take 5?
CC: (none) => fri
Tested on RC-Live-Plasma take 5 and the bug I described in Bug 28249 is now fixed. ISO Tested: 3,4G janv. 31 17:52 Mageia-8-rc-Live-Plasma-x86_64.iso Language: French Keyboard layout: Bépo, is now available when I reach the Bootloader Setup screen. Thanks for the fix, Martin!
Great guys Thank you for the report and testing, Sébastien, and for the fix Martin :)
Status: REOPENED => RESOLVEDResolution: (none) => FIXED