VHDs + wimboot sources on this PC are on (hd1,5) in grub4dos nomenclature.
...
EDIT: Just to cover all possibilities, trying the commands used by UEFI_MULTI for files located on USB device:
...
@ karyonix
I hope you have enough info now to evaluate your hypothesis, please I will appreciate a lot if you explain me in detail your conclusions.
alacran
Test 2 FAILS because WIM in BIOS (hd1) is inaccessible after (hd1) is mapped to RAMDISK.
Test 4-6 FAIL because VHD RAMDISK drive number exceeds mapped number-of-harddrives, so it does not exist in Windows boot loader's point of view.
If you attahced 1 more harddrives to the PC to the system and its order is after the drive containing WIM, test 4 would be expected to succeed.
If you attahced 2 more harddrives to the PC to the system and their order are after the drive containing WIM, test 5 would also be expected to succeed.
Test 7 FAILS
I guess USB is the only drive or is the last drive.
FAILURE is unexpected in case USB drive is (hd0) and there is also an internal drive (hd1) without the files.
RAMDISK should have drive number different form WIM-containing drive.
This is now proved only Partialy true since it is true on Tests 1 and 3 but fails to boot on Tests 4, 5 and 6 where was mapped to hds 3, 4 and 5 respectively.
This is still a necessary condition (in case WIM is not in VHD RAMDISK).
A "non-existing-till-then" hard disk number is a sufficient condition but not a necessary condition.
This is now proved not true.
So then: If drive number of the WIM-containing drive is mapped to RAMDISK, WIM-containing drive and WIM file would be inaccessible.
It is one condition, valid to not boot (0), but we need to establish the condition(s) valid for boot (1).
So thinking this in Boolean algebra, required conditions already known are:
RAMDISK should have drive number different form WIM-containing drive AND xxxxx
xxxxx is the missing part to establish full conditions.
RAMDISK should have drive number different form WIM-containing drive AND their drive numbers must be valid (harddrive number below new number-of-harddrives),
AND, to avoid undefined behavior, all harddrive numbers above-or-equal-to original number-of-harddrives and below new number-of-harddrives must be mapped to something.
If you map them sequantially from original number-of-harddrives up, GRUB4DOS automatically increase number-of-harddrives.
If you map them in non-sequential order, use map --harddrives= to specify new number-of-harddrives.
I could say,AND Mapped drive number has to be the drive number of files location +/- 1.
Then it comes to:
RAMDISK should have drive number different form WIM-containing drive AND Mapped drive number has to be the drive number of files location +/- 1.
But since second condition also satisfy first condition, now we end with a single condition:
Mapped drive number has to be the drive number of files location +/- 1.
Which is already proved
This is the final answer, the big question unanswered is WHY.
Excuse Me if this may look as nonsense insistence, but I would like to learn a few more info in order to understand more clearly this.
Best Regards
alacran.
Because your tests have originally only 2 drives and would have up to 3 drives after map.
The only valid drive numbers are {(hd0),(hd1),(hd2)} and (hd1) is always assigned to the drive containing WIM,
so the remaining drives are only (hd0) and (hd2), so the (RAM,WIM) pair could only be either ((hd1),(hd0)) or ((hd1),(hd2)), so their difference could only be +/-1.
If you use multiple map commands, it is possible to reorder them like this
map --top --mem /10x64-WB.vhd (hd0)
map (hd0) (hd1)
map (hd1) (hd2)
map --hook
# ((hd0)=RAMDISK, (hd1)=USB, (hd2)=internal disk with WIM)
or this
map (hd1) (hd0)
map (hd0) (hd1)
map --top --mem /10x64-WB.vhd (hd2)
map --hook
# ((hd0)=internal disk with WIM, (hd1)=USB, (hd2)=RAMDISK)
If you have more drives, more drive numbers would be available.
For example, if (you have 4 harddrives and WIM file is on (hd2)), then {(hd0), (hd1), (hd3), (hd4)} would be valid choices for RAMDISK.
You can, optionally, increase number of valid harddrive numbers by mapping more harddrives. (I don't have a reason to do so. I just say it is possible in theory.)