What is the best criteria to select a mapped drive number when Rambooting Wimboot VHDs located on internal Disk, using grub4dos + SVBus driver?
I do not mean in any way I have deep knowledge on this subject, but I am interested in find an answer to some things that intrigue me about this.
Now that the urgency to fix this subject on UEFI_MULTI to let it work as required is solved, there are still some questions on my mind that are unsolved.
I'm starting this new thread because I don't want to hijack EUFI_MULTI thread.
This post from karyonix has interesting info/ideas, and I would like to try to find some answers and knowledge with our more knowledgeable forum members help:
Wonko the Sane, on 12 Mar 2019 - 03:46 AM, said:
I guess the requirement that is not met in some recent failure reports is "WIM file must be accessible to boot loader" (via INT13H in legacy BIOS mode).As always your is the "correct" approach , though I still wonder if this is what is actually "required" and "why" it is actually required.
I mean, it seems like all is needed is that the vhd is mapped to a "non-existing-till-then" hard disk number.
If drive number of the WIM-containing drive is mapped to RAMDISK, WIM-containing drive and WIM file would be inaccessible.
RAMDISK should have drive number different form WIM-containing drive.
A "non-existing-till-then" hard disk number is a sufficient condition but not a necessary condition.Wonko the Sane, on 12 Mar 2019 - 03:46 AM, said:
In that test, WIM file is in a drive other than (hd0), so it is still accessible.And the report by alacran with the "undefined" variable (resulting in (hd0)) working remains puzzling.
If WIM is in (hd0), and you simply make RAMDISK as (hd0), it would fail. But there is still a way to resolve the situation by mapping WIM-containing drive as (hd1), so it becomes visible.
These are unproven. It remains to be tested.
Source: http://reboot.pro/to...e-8#entry209770
@ karyonix
I'm ready to run all required test to prove your hypothesis, to give you more info my internal VHDs + wimboot souces on this PC are on (hd1,5) but I can also use another PC where location of this files is (hd0,6).
Also have USBs devices with the files located on (hd0,0) and (hd0,1).
All working fine upto now, so just tell me what would you like me to do for first test, and I'll do it ASAP.
I remember the following commands were tested and fail, but in order to have a fresh start on this experiments I will repeat the test and report back.
title 10x64-WB.vhd - SVBus RAMDISK - 1536 MB - map as (hd0) for WIMBOOT find --set-root --ignore-floppies /10x64-WB.vhd map --top --mem /10x64-WB.vhd (hd0) map --hook root (hd0,0) chainloader /bootmgr
EDIT: And yes, they were tested by wimb but on a different environment, it was during Rambooting from files located on external USB device, and then he started to look for a solution and Wonko suggested it.
So the observed behaviour at the time, do not apply to present case as on this case we are dealing with files located on internal HD.
alacran