Description of problem:
Grub-legacy shell fails to properly guess the device map that the embedded Grub will use. Grub shell seems to guess the same device map as linux (/dev/sda = (hd0), and so on) independently of the order of the disks in the BIOS (got it from enumeration?). Embedded Grub _seems_ to count according to BIOS order (to be confirmed): first HDD in sequence is (hd0).

Why do I consider this a bug, or at least a lack of "toughness" of the installer?
The problem is not to know that Grub is only reliable in CLI on boot (or the opposite).
1°) The problem is the Grub shell is still used by the MCC in the _display_ of the boot partition, etc., and and it is still accessed through the console by a root user: why is this enabled, if all those informations are crap? The use of Grub should be transparent for the user (no more (hd1,0) in the MCC!)
2°) Moreover, maybe the instructions on the DVD should tell that the use of a Grub floppy is mandatory in such situation, and should recall the procedure:
- create a Grub boot floppy or USB drive;
- use it to install Grub on the MBR of your choice and to know the device map;
- reboot with any Live CD;
- mount the /boot partition;
- write the menu.lst or correct the one that the MCC outputted;
- reboot on HDD (in case it doesn't work, change disk order in the BIOS).

Workaround:
Fortunately, as I had only 4 HDDs, trials and errors were easy.
I managed to seed Grub on the MBR of the Mageia HDD and when I selected it as the primary HDD, I could access the Grub menu and the CLI, to have a chance to know the device map used by the embedded Grub (I don't know whether it is BIOS dependant, because I haven't yet managed to get a Grub CLI when I select another HDD as the primary one). Now Mageia3 boots correctly, just because the Mageia HDD is the first (and only) drive in the boot sequence (it is the secondary HDD on the on-board SATA controller). 


Hardware configuration: 3 disk controllers (on-board SATA, on-board IDE, PCIe SATA), 4 disks, dual (or triple) boot, dedicated /boot partition.
SATA drives as IDE; PnP identified by BIOS.


Is this a regression ? I had no problem with Mandriva 2010 (only the mapping to chain to Windows bootloader). Sadly, I forgot to save my old menu.lst before formatting /boot when I migrated.

Note: I have screenshots to illustrate how the grub shell was not useful in my (borderline?) case. I and my system are available to all of you, should you want to investigate (BIOS infos, lspci, device maps, partitioning, etc.). As I want to know the cause of this behavior, I'm going to seek help on the forum.


Version-Release number of selected component (if applicable):
Mageia3 Live CD 32 bits KDE _and_ Mageia3 DVD 64 bits

How reproducible:
Maybe, it's strongly hardware dependent.

Steps to Reproduce:
1. Have more than one disk? Have a /boot partition? Want to keep a dual boot on two disks?
2. Either use the Grub-shell to guess the device map and to seed Grub in your primary disk (the windows disk, as an example), configure the menu.lst entries according to this map, or use the MCC to setup boot.
3. Watch the black screen on reboot if the first disk in the BIOS was not that you thought you seeded Grub in.

Reproducible: 

Steps to Reproduce: