(In reply to Oleg Bosis from comment #0)

> 
> Steps to Reproduce:
> 1. Start installing using x86_64 netinstall iso image
> 2. Choose Russian when prompted for language to use
> 3.

when prompted.... so that's at the beginning of stage2.

It's long ago that I did a VBox install, I don't know whether you can switch to tty2 from the guest, and whether inserting a USB key and then typing:
   bug
will put report.bug on the key.

If you can do that before the crash, but after starting to see the pauses, that would be great.

If that's impossible, then it would be great to get the logs that are in /tmp, like /tmp/ddebug.log and /tmp/stage1.log 
Maybe they're even still there after the crash, so that the ddebug.log might contain more information?

Please attach the log files or report.bug to this bug report (if there's an avalanche of errors, you might need to compress with xz or so first)

CC: (none) => marja11
Assignee: bugsquad => mageiatools
Source RPM: (none) => drakx-installer-stage2

Created attachment 8608 [details]
report.bug from vm

Attached report.bug from vm made just after language selection

CC: (none) => olegbosis

Additional info: I've switched to vt2 before disk partitioning stage and the console is flooded with 

* running: loadkeys ru
* loading keymap ru

string pairs. And this strings seem to be printed endlessly...

(In reply to Oleg Bosis from comment #3)
> Additional info: I've switched to vt2 before disk partitioning stage and the
> console is flooded with 
> 
> * running: loadkeys ru
> * loading keymap ru
> 
> string pairs. And this strings seem to be printed endlessly...

It ends with

* exec of loadkeys failed: Cannot allocate memory

after that there are many repeated lines of:

* running: setxkbmap -option 
* running: setxkbmap ru -variant  -model pc105 -option compose:rwin -compat

which ends with

* lang:ru charset:koi8-u font:DejaVu Sans 12 consolefont:UniCyr_8x16
* lang:ru charset:koi8-u font:font-family: DejaVu Sans; font-size: 12pt; consolefont:UniCyr_8x16

Keywords: NEEDINFO => (none)

(In reply to Marja van Waes from comment #4)
> (In reply to Oleg Bosis from comment #3)
> > Additional info: I've switched to vt2 before disk partitioning stage and the
> > console is flooded with 
> > 
> > * running: loadkeys ru
> > * loading keymap ru
> > 
> > string pairs. And this strings seem to be printed endlessly...
> 
> It ends with
> 
> * exec of loadkeys failed: Cannot allocate memory
> 
> after that there are many repeated lines of:
> 
> * running: setxkbmap -option 
> * running: setxkbmap ru -variant  -model pc105 -option compose:rwin -compat
> 
> which ends with
> 
> * lang:ru charset:koi8-u font:DejaVu Sans 12 consolefont:UniCyr_8x16
> * lang:ru charset:koi8-u font:font-family: DejaVu Sans; font-size: 12pt;
> consolefont:UniCyr_8x16

You mean the content of the report.bug? It was created before license agreement and keyboard layout stages and it contains just a very small amount of loadkeys.
The flood occurs later just before the disk partitioning stage and probably causes vm reboot (probably just some memory gets exhausted by these "loadkeys").

(In reply to Oleg Bosis from comment #5)

> 
> You mean the content of the report.bug? 

Yes, that's what I meant

> It was created before license
> agreement and keyboard layout stages and it contains just a very small
> amount of loadkeys.
> The flood occurs later just before the disk partitioning stage and probably
> causes vm reboot (probably just some memory gets exhausted by these
> "loadkeys").

Thanks for telling us!

Summary: Netinstall images hang and crash if Russian language is selected in installer in virtualbox vm => Netinstall images hang and crash if Russian language is selected in installer in virtualbox vm ("* running: loadkeys ru * loading keymap ru" flood)

This bug is valid for Mageia-6-sta2-x86_64-DVD.iso image. I've tried to install it in a virtualbox and my physical PC both. After I do select 'Russian' and press 'Next' button installer freezes.

CC: (none) => ugal12v

Created attachment 9035 [details]
report.bug from my physical PC

It can be reproduced by running "loadkeys ru" on tty2 in installer

Reverting s/ru4/ru/ fixes it:
http://gitweb.mageia.org/software/drakx-kbd-mouse-x11/commit/lib/keyboard.pm?id=44a643f73fbb9a1d83fea952326f26fedc407842

Priority: release_blocker => Normal
CC: (none) => pablo
Source RPM: drakx-installer-stage2 => drakx-installer-stage2, drakx-kbd-mouse-x11

commit e2990244437375a022f4da40f633d150de63de8c
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Tue Mar 7 17:15:58 2017 +0100

    Revert "switch from legacy (KOI8-R) 'ru4' keyboard to 'ru'"
    
    This reverts commit 44a643f73fbb9a1d83fea952326f26fedc407842.
    
    This causes a crash in installer (mga#19680)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx-kbd-mouse-x11/commit/?id=e2990244437375a022f4da40f633d150de63de8c

Added to the errata
https://wiki.mageia.org/en/Mageia_6_Errata#Russian_install_impossible

But not adding the IN_ERRATA6 keyword, because Thierry's commit fixes it for 6RC.
Netinstalls will be fixed as soon as drakx-installer-stage2 is rebuilt with new drakx-kbd-mouse-x11

@ Thierry

Do we need feedback from Pablo before rebuilding stage2?

@ Yuri and Oleg

Could both of you please consider becoming QA iso testers? 
https://wiki.mageia.org/en/QA_ISO_testers

Even if this bug will be fixed in 6RC, we don't want to end up missing another awful bug that doesn't affect our current iso testers, but does affect many in the rest of the world!

Mageia 4.1 had to be released because we had missed a bug that made it impossible to install Mageia for half of the Russian users. We don't want that to happen again.

Btw, do the 6sta2 Live isos work?

@ AlexL

I thought you had access to the QA isos, but fail to see you in the iso testers list. Is my memory wrong?

Status comment: (none) => fixed in drakx-kbd-mouse-x11, fix will end up in stage2 when it's rebuilt.
CC: (none) => loginov_alex

Net install should work when drakx-installer-stage2-17.73-3.mga6 (pushed ± an hour ago) has arrived on your mirror

Status comment: fixed in drakx-kbd-mouse-x11, fix will end up in stage2 when it's rebuilt. => fixed in drakx-kbd-mouse-x11, fix is included in drakx-installer-stage2-17.73-3.mga6

Yes the bug is fixed.
Though I requested Pablo's advice for what should we do if we want to switch to non legacy encoding.
Pablo is the Jedi master regarding l10n/i18n :-)

Status: NEW => RESOLVED
Resolution: (none) => FIXED

> Btw, do the 6sta2 Live isos work?

I tested the Mageia-6-sta2-LiveDVD-Plasma-x86_64-DVD image. The Russian localization installs well from both the boot menu and the live system. 
When the installed system starts to boot, two lines 'cannot open file ru.uni' appears on the console. I don't know if it's important or not. The installed system boots and operates seems normally. I attached the log file with that lines.

Created attachment 9044 [details]
boot.log from installed system with the 'cannot open file ru.uni' lines

(In reply to Yuri Galitsky from comment #15)
> > Btw, do the 6sta2 Live isos work?
> 
> I tested the Mageia-6-sta2-LiveDVD-Plasma-x86_64-DVD image. The Russian
> localization installs well from both the boot menu and the live system. 
> When the installed system starts to boot, two lines 'cannot open file
> ru.uni' appears on the console. I don't know if it's important or not. The
> installed system boots and operates seems normally. I attached the log file
> with that lines.

Thanks for testing :-)

The error means it cannot open /usr/lib/kbd/keymaps/i386/qwerty/ru.map.gz which is the Russian UTF-8 keymap. You'll probably notice that when you switch to a VT with e.g. ctrl+alt+F3, that you can't type Russian.

Becoming root and then typing "loadkeys ru4" should give you the old Russian keymap in your VT, which does work.

That's another issue that should be in another bug report :-)
I've tried switching Russian to UTF-8 but I obviously failed (as can be seen in this bug report existence :-))
The terminal setting us in keyboarddrake's keyboard.pm :

http://gitweb.mageia.org/software/drakx-kbd-mouse-x11/tree/lib/keyboard.pm#n127
http://gitweb.mageia.org/software/drakx-kbd-mouse-x11/tree/lib/keyboard.pm#n275

/me is confused, but is aware that she jumped to conclusions too fast

Now that I think about it, the issue is that it didn't find a kbmap file in /usr/share/keymaps.
For installer, those came from http://gitweb.mageia.org/software/drakx/tree/perl-install/install/share/keymaps.tar.bz2
Underdocumented Pixel's generator is at http://gitweb.mageia.org/software/drakx/tree/perl-install/install/share/kmap2bkmap

So what happens is that loadkeys is implemented in perl in installer, calls loadkeys() from install::commands, which calls keyboard::setup_install() which if the bkmap file is missing, calls the external loadkey program instead of _builtin_loadkeys().
And the external loadkeys enters commands.pm and we got a nice old fork bomb written in perl :-(

http://gitweb.mageia.org/software/drakx/tree/perl-install/install/commands.pm#n422
http://gitweb.mageia.org/software/drakx-kbd-mouse-x11/tree/lib/keyboard.pm#n560

So the issue is that if we wants to switch away from "ru4", we must also regenerate install/share/keymaps.tar.bz2 with the new mapping...

*** Bug 20430 has been marked as a duplicate of this bug. ***

CC: (none) => hazard157