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

#1 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 March 2019 - 12:11 PM

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:snapback.png

As always your is the "correct" approach :), though I still wonder if this is what is actually "required" and "why" it is actually required. :dubbio:
I mean, it seems like all is needed is that the vhd is mapped to a "non-existing-till-then" hard disk number.

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).
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:snapback.png

And the report by alacran with the "undefined" variable (resulting in (hd0)) working remains puzzling.

In that test, WIM file is in a drive other than (hd0), so it is still accessible.

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



#2 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 March 2019 - 01:35 PM

VHDs + wimboot sources on this PC are on (hd1,5) in grub4dos nomenclature.

 

So far this are my findings:

title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map as (hd0) for WIMBOOT (TEST 1) BOOTING FINE
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr
title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map as (hd1) for WIMBOOT (TEST 2) FAILURE
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd1)
map --hook
root (hd1,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 as (hd2) for WIMBOOT (TEST 3) BOOTING FINE
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd2)
map --hook
root (hd2,0)
chainloader /bootmgr

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

Info of fail:

File:  \Boot\BCD

Status: 0xc0000225

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

Info of fail:

File:  \Boot\BCD

Status: 0xc0000225

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

Info of fail:

File:  \Boot\BCD

Status: 0xc0000225

EDIT: Just to cover all possibilities, trying the commands used by UEFI_MULTI for files located on USB device:

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

Status: 0xc0000225

Unspected failure <<<<<<<<< My translation

They fail as expected since we already know that commands are not for internally located files.

 

EDIT: And of course the commands actually in UEFI_MULTI for internally located files are working fine:

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

Attached pictures of the 2 successful boots.

 

As you can see it doesn't matter how we mapped the VHD hd0 or hd2, it runs from virtual hd2 on both pictures.

 

Also made pictures of unsucessfull test, I don't thing they can give more info all are related to Status: 0xc0000225, so the cause is the same: Windows cannot find the system files used for booting,  boot configuration data files are being missed or corrupted while accessing any application or system files/programs:.       https://fixforwindows.com/0xc0000225

 

I will take this as Windows can't find wimboot source wim file.

 

I was expecting mapping as hd2 to be the only successful, but also maping to hd0 was successful, as karyonix inferred.

 

@ 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

Attached Files



#3 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 15 March 2019 - 02:35 PM

Most of the test results corespond to the rule given by karyonix, except tests 4, 5 and 6

 

If drive number of the WIM-containing drive is mapped to RAMDISK, WIM-containing drive and WIM file would be inaccessible.

 

Error 225 is indeed simply file not found, in this case WIM file not found.

 

 

There is (hd) which means next available driver number for hard drive. You can use together with (hd-1) (last existing harddrive). (ref : rmprebusb)
Map as (hd), then, after hook, it becomes (hd-1).

 

http://reboot.pro/to...drive/?p=209754



#4 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 March 2019 - 03:52 PM

Everything fits in the rule given by Wonko

 

Please excuse me my friend, but karyonix was who said that, and also said in same paragraph:

 

 

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.

 

If drive number of the WIM-containing drive is mapped to RAMDISK, WIM-containing drive and WIM file would be inaccessible.

 

Proved to be true, as you already said.

 

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.

 

And only is true on tests 1 and 3 where was mapped to hds 0, and 2 respectively

 

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.

 

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.



#5 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 15 March 2019 - 03:55 PM

Please excuse me my friend, but karyonix was who said that, and also said in same paragraph:

 

 

You are right that I made a mistake, but I was making the correction while you were posting

 

It is indeed more complex and it is certainly worthwhile to study more on the subject.



#6 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 March 2019 - 04:10 PM

No problem my friend, we all are here for fun, have a good time, share some info and learn from each other and nobody is perfect, I was only trying to let you know to fix it and give credit to the right person.

 

See you latter.



#7 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 March 2019 - 10:20 PM   Best Answer

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



#8 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 15 March 2019 - 11:03 PM

Because the first and third menus above give different errors, I am wondering if there are two variables in your menus.

1. What drive you map the VHD to

2. What drive is set as root

 

Could you try  these menus again but use

 

Menu1

rootnoverify (hd1,0)
chainloader (hd0,0)/bootmgr

and for the 3rd menu

rootnoverify (hd1,0)
chainloader (hd2,0)/bootmgr

and maybe try different drives for the rootnoverify line like hd0 and hd2?



#9 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 March 2019 - 12:32 AM

@ steve6375

 

It seems to me you didn't read the thread since the begining, we already know the right commands to Ramboot a Wimboot VHD when files are on internal HD thanks to karyonix, based on a document from yourself (steve6375):

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

This works for files located on any internal HD (up to hd9), previously proposed by Wonko:

title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map as disk+1 (RIGHT-1)
find --set-root --ignore-floppies /10x64-WB.vhd
root | set myroot=
set /a mydisk=%@root:~3,1%+1
map --top --mem /10x64-WB.vhd (hd%mydisk%)
map --hook
root (hd%mydisk%,0)
chainloader /bootmgr

See: This post from karyonix for more info: http://reboot.pro/to...e-8#entry209754

 

But no problem, to satisfy your curiosity (and mine too) I ran all tests you requested:

title 10x64-WB.vhd - SVBus  RAMDISK  - hd0 rootnoverify (hd1,0) chainloader (hd0,0)
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd0)
map --hook
rootnoverify (hd1,0)
chainloader (hd0,0)/bootmgr

Info of fail:

Status: 0xc0000225

Unexpected failure  <<<<<<< This is my translation, it was in Spanish.


title 10x64-WB.vhd - SVBus  RAMDISK  - hd2 rootnoverify (hd1,0) chainloader (hd2,0)
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd2)
map --hook
rootnoverify (hd1,0)
chainloader (hd2,0)/bootmgr

Info of fail:

File:  \Boot\BCD

Status: 0xc0000225


title 10x64-WB.vhd - SVBus  RAMDISK  -  hd0 rootnoverify (hd0,0) chainloader (hd0,0)
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd0)
map --hook
rootnoverify (hd0,0)
chainloader (hd0,0)/bootmgr

Info of fail:

Status: 0xc0000225

Unexpected failure  <<<<<<< This is my translation, it was in Spanish.


title 10x64-WB.vhd - SVBus  RAMDISK  - hd2 rootnoverify (hd0,0) chainloader (hd2,0)
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd2)
map --hook
rootnoverify (hd0,0)
chainloader (hd2,0)/bootmgr

Info of fail:

File:  \Boot\BCD

Status: 0xc0000225


title 10x64-WB.vhd - SVBus  RAMDISK  - hd0 rootnoverify (hd2,0) chainloader (hd0,0)
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd0)
map --hook
rootnoverify (hd2,0)
chainloader (hd0,0)/bootmgr

Info of fail:

Status: 0xc0000225

Unexpected failure  <<<<<<< This is my translation, it was in Spanish.


title 10x64-WB.vhd - SVBus  RAMDISK  - hd2 rootnoverify (hd2,0) chainloader (hd2,0)
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd2)
map --hook
rootnoverify (hd2,0)
chainloader (hd2,0)/bootmgr

Info of fail:

File:  \Boot\BCD

Status: 0xc0000225

alacran



#10 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 16 March 2019 - 08:45 AM

OK, thanks!

So it is looking like you must set the grub4dos root drive to point to the same drive that the --mem vhd is loaded into in order for bootmgr to find the BCD.

And then, the driver is attaching the memdisk as an extra physical drive in the system as disk n+1.

Perhaps the reason why using a larger disk number does not work is that when you map a new hd in grub4dos, it does not increase the BIOS counter for the number of hard disks in the system?

You can change the BIOS hard drive count using

map --harddrives=n

So maybe try something like:

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

The count is set to 9 (drives hd0-8) so that the svbus driver will mount the memory-mapped drive as drive hd9.

(I think my logic is correct ??? - if not try changing the harddrives number +/-1!).


Edited by steve6375, 16 March 2019 - 08:49 AM.


#11 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 March 2019 - 12:24 PM

@steve6375

 

The right solution in use actually is coming from a document witten by yourself and it is working great.

 

Please read again my previous post, I edited it, and now I think it is more clear, sorry for any missunderstanding.

 

These commands for grub4dos are already defined and in use in UEFI_MULTI.

 

The only pourpose of this thread was to understand better the requirements for mapping hd when files are located on internal HD, since as it is proved now after carefull testing, when files are on a HD other than hd0 there are two possible solutions, not only one and this was creating certain confussion.

 

alacran



#12 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 16 March 2019 - 12:32 PM

Sure - and the menu I suggested (if it works) would explain what is going on.

If adjusting the number of disks in the system works (as in my menu), then it explains why you have to use (hd) - because the svbus driver looks at the BIOS drive count and mounts the ram drive as  TotalBIOSDisks+1.

If the suggested menu works, then it would prove this theory.

 

Isn't that the point of this thread - to have a theory and then to test the theory?



#13 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 March 2019 - 12:35 PM

Ok my friend, I'll try it immediatly and report back



#14 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 March 2019 - 01:18 PM

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

Info of fail:

File:  \Boot\BCD

Status: 0xc0000225

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

Info of fail:

File:  \Boot\BCD

Status: 0xc0000225

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

Files are located on this PC on (hd1,5), will try now on another PC with files on (hd0,6)

 

alacran



#15 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 16 March 2019 - 01:27 PM

hmmm... not quite what I was expecting, but I think this proves the BIOS no-of-disks is used.

 

Please could you test  map --harddrives=11

just to make sure it will fail?



#16 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 March 2019 - 01:44 PM

Sure, no problem, about test on PC where files are on (hd0,6), I got exactly same results as on previous test.



#17 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 March 2019 - 02:03 PM

title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map as (hd9) for WIMBOOT harddrives=11 BOOTS FINE
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd9)
map --hook
map --harddrives=11
root (hd9,0)
chainloader /bootmgr

title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map as (hd9) for WIMBOOT harddrives=12 BOOTS FINE
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd9)
map --hook
map --harddrives=12
root (hd9,0)
chainloader /bootmgr

On both PCs with files on (hd1,5) and (hd0,6)

 

alacran



#18 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 16 March 2019 - 02:05 PM

Now I am confused! Anyone have any theories? :hmm:



#19 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 March 2019 - 02:10 PM

 

What happens if root hd number is more than 1 digit.
root is (hd10,0)..(hd19,0) => mydisk=2
root is (hd20,0)..(hd29,0) => mydisk=3
root is (hd90,0)..(hd99,0) => mydisk=10
root is (hd100,0)..(hd127,0) => mydisk=2

 

 From: http://reboot.pro/to...e-8#entry209754



#20 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 16 March 2019 - 03:12 PM


Now I am confused! Anyone have any theories? :hmm:


why confused?

it is logical and the result is expected.

when the bios drive count covers the virtual hdX drive, then it gains success. otherwise it gets failure.

#21 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 16 March 2019 - 03:16 PM

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

This is a working menu.

Wont the BIOS drive count be less than the virtual drive?



#22 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 March 2019 - 03:22 PM

Just by curiosity I tested this:

title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map as (hd9) for WIMBOOT harddrives=20 BOOTING FINE
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd9)
map --hook
map --harddrives=20
root (hd9,0)
chainloader /bootmgr

title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map as (hd9) for WIMBOOT harddrives=30 BOOTING FINE
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd9)
map --hook
map --harddrives=30
root (hd9,0)
chainloader /bootmgr

 But IMHO with this we are creating more confusion that answers, as we are introducing additional artificial variables, I thing it is best to keep things (hd) as they are in reality in the system, in order to restrict the commands used to real conditions, and not find hundreds of commands that work but for an artificialy created environment, not our real case.

 

Aren't you agree?

 

In any case the VHD located on RAM on PC with files on hd1 is loaded always as hd2 and the VHD located on RAM on PC with files on hd0 is loaded always as hd1.

This do not change never, unless there is an additional USB device plugged before booting, then VHD loaded on Ram automatically becomes next number drive and it boots fine without any need to modify the commands:

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

Then the BCD located into the VHD is automatically addapted to this new location and OS boots fine.

 

During making this post I noticed 2 new post were made, take this in consideration please.

 

Attached a picture when booted from this title (files on internal hd1):

title 10x64-WB.vhd - SVBus RAMDISK - 1536 MB - map as (hd9) for WIMBOOT harddrives=20 BOOTING FINE

 

alacran

Attached Files



#23 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 16 March 2019 - 03:42 PM

title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map as (hd) for WIMBOOT (successful)
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr
This is a working menu.
Wont the BIOS drive count be less than the virtual drive?

no. it wont. the map command will automatically adjust bios drive count when the newly created virtual drive immediately follows the last drive.

#24 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 16 March 2019 - 03:45 PM

ahhhhhh :rolleyes:



#25 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 16 March 2019 - 03:57 PM

emmm.....

never create gaps in bios drive count.

trying to access a non-existent BIOS drive in realmode could cause hangup! bear in mind: bioses are buggy!

if a drive is not created by ROM power-on-self-test(real drive), then it should be a virtual drive created by grub4dos. the bios drive count should not include a drive which does not exist at all.
  • alacran likes this



Also tagged with one or more of these keywords: ramboot

2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users