Here's a little suggestion / wish for next vMA release:
For English-keyboard users, the problem might not be so obvious. So before you jump in and say "it's easy to change the keyboard", please hold yourself from such impulse to answer.
Yes, it is easy to change keyboard once logged in, but the problem isn't here. It's during password creation: well, first, the password needs to be strong so a lot of "candidate passwords" are rejected before getting the good one. Without really knowing what we are typing, it's really a pain to create a password in such condition.
If it's not possible to change keyboard before asking for password, it would be nice to give us a chance to test the keyboard before. This is especially useful to test if the NUM-LOCK is on or off. You have to know that if NUM-LOCK is off, press those "numbers" on the number pad actually gives some valid "characters" for the password! And it'll be a pain to retype the password afterwards.
A common example for such keyboard test is like this:
Before going on, you could test your keyboard by typing anything except ENTER below.
Press the ENTER key to end the test:
At the redhat boot loader (red screen) press any key to interrupt the automated boot, then press 'a' to modify the the kernel arguments.
Add the word single to the end of the boot line to boot into single user mode, e.g.:
grub append> ro root=/dev/VolGroup00/root quiet
grub append> ro root=/dev/VolGroup00/root quiet single
Press enter and wait for it to boot and you will arrive at a shell. Edit the file /etc/sysconfig/keyboard and change "KEYTABLE" to your own keyboard settings, save and reboot. Your keyboard layout should now be loaded for the initial setup steps.
You can find your relevant keymap under /lib/kbd/keymaps/i386
Oh... I see...
The first time I saw that screen, by the time I read through the message and understood what it meant, the OS was already loading! Anyway, even if I was fast enough, I wouldn't have known what to do with it!
If we missed that (ie when the "configuration for the first time" is already started) and if we press the red square button to force a shutdown, would we break the VM? Or is it better to deploy a new vMA once again and hope we are fast enough to go to this "single user mode" that you're talking about?
Rebooting it shouldn't cause it any problems, but redeploying it doesn't take long either so... up to you
If you open the console before turning the VM on, you might get a bit longer to interrupt it. Alternatively edit the VM settings and force it to delay the boot menu for about 5000 ms, that way you're giving yourself extra time to prepare for the actual boot menu you want to interrupt
Alright, on my nth vMA deployment (because of other problems :smileyangry: ), I tried this "single user mode" trick and it works quite well. Thanks
For the record, the GRUB append string is different (maybe because I'm using vMA 4.1) but I just added "single" to the end of it and boot. This works.