Jump to content











Photo
* * * - - 1 votes

More deeper understanding of Mapped drive number for RamBooting Wimboot VHDs from internal HD using grub4dos + SVBus driver

ramboot

Best Answer alacran , 15 March 2019 - 10:20 PM

Finally just to don't let something pending, this time files are on (hd0,6)

 

and this are my findings:

title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map for WIMBOOT hd0 TEST 1 FAILURE
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

Info of fail:

Status: 0xc0000225

Unexpected failure  <<<<<<< This is my translation, it was in Spanish.
title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map for WIMBOOT hd1 TEST 2 BOOTING FINE
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd1)
map --hook
root (hd1,0)
chainloader /bootmgr

ALL FINE
title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map for WIMBOOT hd2 TEST 3 FAILURE
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd2)
map --hook
root (hd2,0)
chainloader /bootmgr

Info of fail:

File:  \Boot\BCD

Status: 0xc0000225

As we already know from post No. 4:

 

Mapped drive number has to be the drive number of files location +/- 1.

 

Which is already proved

 

Of course in this particular case where files are on hd0 then there is drive 0 + 1 = 1, but there is not drive 0 - 1 = -1 (since it do not exist in real life).

 

So we found and exception to previous statement. and it has to be adapted to comply with new findings.

 

Then the only condition that remains valid in all possible cases (including files on drive 0) is reduced to only one possibility:

 

Mapped drive number has to be the drive number of files location + 1.

 

Now we can say there is no dubt we know certanly wich is the only possibility to map our drive, when files are on internal HD, and make sure it will never fail (for wrong selected hd number).

 

And this are the already proved commands suggested by karyonix to make it work:

title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map as (hd) for WIMBOOT
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

For more info see karyonix final analysis of this subject: http://reboot.pro/to...e-3#entry209935

 

alacran

Go to the full post


  • Please log in to reply
53 replies to this topic

#51 alacran

alacran

    Gold Member

  • .script developer
  • 1010 posts
  •  
    Mexico

Posted 17 March 2019 - 05:27 PM

boot menu policy standard in the case of filedisk as well.

later in the evening i will also coldboot the ramdisk option your config and and tell you how it went. the problem of crashing on coldboot often presents itself when a long time has passed between re-switches, so i do not know if later in the evening will be a long enough time for the problem to replicate --> if i turn the computer back on in a couple of hours the problem will most likely not crop up (i know it for a fact).

 

a big thanks for the time being

 

nino

 

This problem is evidency of something wrong on your system hardware, NOT on the used commands, tinybit answer seems also to me as the first thing to check, I had long time ago a problem like that on a system with 2 Ram boards, during boot, the especific zone with the failure (I assume it was an small zone, and located not at the begining) in one of them was used some times and othrer times don't, so depending on my luck it booted or not. Until I found the cause of the issue and replaced the bad memory board.



#52 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 409 posts
  •  
    Italy

Posted 18 March 2019 - 05:03 AM

How do I check which one of the 4 ram sticks it is?

#53 alacran

alacran

    Gold Member

  • .script developer
  • 1010 posts
  •  
    Mexico

Posted 18 March 2019 - 02:45 PM

@antonino61

 

What I would do first is remove all Ram boards (PC has to be OFF and disconnect to AC and also battery removed if it is a Laptop) and clean the pins with a soft erraser (one of those white Pelikan or similar) both sides to remove the patina, two or maybe 3 passes should be enought, then with a brush remove any remaining of the erraser,  and also clean Ram sokets on the MB, put all them back and see if problem is solved.

 

If you still have problems:

 

You can use the tool provided by windows when booting on text screen pressing Tab you go to a tool to test memeory, I think it's name is memtest (long procedure).

 

Other option:

 

If you can boot fine with only 3 Ram boards, remove one (remember previous recommendations about machine OFF, etc.) and use yor PC as normally you do, if there are not more problems, the one you removed is the one failing. Repeat the procedure untill you find the bad Ram board.

 

In order do not commit mistakes use a color marker to put a little mark on one lateral edge of each one of them found good (those that when removed, machine still failing).  Or you can also take note of serial number if available.

 

alacran



#54 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 472 posts
  •  
    Thailand

Posted 18 March 2019 - 03:01 PM

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.)


  • alacran likes this



Also tagged with one or more of these keywords: ramboot

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users