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

#26 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 - 04:02 PM

sure - it was just an experiment to try to figure out why only the last hard disk + 1 would work. I was not proposing it as a solution, just a test.



#27 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 16 March 2019 - 04:33 PM

map --status will report the original BIOS drive count and the updated drive count (the current one that is in effect).

#28 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 16 March 2019 - 05:04 PM

too many bad bioses! look at this:

it is rather common. usb booting. the usb is recognized as (hd0), and the system has no floppy drive at all. but, the bios floppy count is 1, surprisingly! but more surprising is, trying to access the floppy gives hangup! it should fail and simply give error, but not die out totally!

the newish grub4dos already handled it. the workaround is this way:

when grldr find it was booted from harddrive (not floppy), it clear out the bios floppy count, effectively disabled the floppies. so it wont accidentally hangup.



#29 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 March 2019 - 12:27 AM

excuse me, I do not know if it is connected to what you are trying to find out, but since I started internal (non-usb) rambooting, I have always had the following menu.lst content:

 

title Windows 10 - FILEDISK1
map (hd0,0)/vhd1.vhd (hd1)
map --hook
root (hd1,0)
chainloader /bootmgr
 
title Windows 10 - RAMDISK1
map --mem --top (hd0,0)/vhd1.vhd (hd1)
map --hook
root (hd1,0)
chainloader /bootmgr
 
to wonko and co.'s perplexity, it has always booted fine, with one glitch, though. everytime I cold-boot my pc, it has to be as FILEDISK, because as RAMDISK it always yields an acpi.sys (or whatever *.sys) error bsod. I manage to boot as RAMDISK only on a reboot-from-FILEDISK basis. how come, or, for the Brits, how so? 


#30 steve6375

steve6375

    Platinum Member

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

Posted 17 March 2019 - 01:53 AM

How many disks are in the system? Just one?

#31 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 March 2019 - 03:47 AM

I have 4 disks

#32 steve6375

steve6375

    Platinum Member

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

Posted 17 March 2019 - 08:07 AM

OK, well you will need to exactly specify your complete method of preparation of the vhd, including exact versions used and exact settings in BCD, etc.

It is not enough just to give us your grub4dos menu and say it works for you...

 

Also, if you place your vhd on a grub4dos-bootable external USB, does the same menu still work OK?



#33 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 17 March 2019 - 08:31 AM

@antonino61

 

it could be a driver bug, a hardware issue, or a conflict.

 

you may do more work to see if firadisk would have the same problem.

 

Suppose, imagine, if SVBus use chipset (DMA) to support memory address above 4G, then the result would be affected by a chipset issue, or in other words, there could be conflicts between SVBus and the chipset.

 

So, in the case of direct mapping (without --mem), no problem, but failed with --mem (cold boot). On a warm boot, the previous windows 10 OS might have fixed the chipset issue in some way (temporarily), thus "--mem" also succeeded.



#34 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 March 2019 - 09:01 AM

To whom it may concern,

I never did try booting off usb. I have always been talking of internal drives. My present findings on wimbooting are based on tries on 2 types of machines only: mine, which I had already described (4 disks, no floppy, no cd- or dvd-rom) and told you it works fine according to the above menu.lst (as almost all of u later stated even as regards other machines according to u guys' tests posted here), and my wife's (an AMD laptop with only one hard drive, one dvd-rom, no floppy either). I tried all the successful menu.lst posted here, even some unsuccessful ones, as the failure applied to different machines from the ones I am talking about. no dice. After a good many hours, I have decided to copy grdlr, grdlr.mbr, menu.lst (both from root and from NST along with the whole NST content) from my machine to my wife's, and it eventually worked, both as filedisk and as ramdisk. I also would like to notify you of some sporadic erratic rambooting behavior (booting/not booting) earlier on during those hours, but systematically no filedisk booting (inaccessible boot device). btw, now that I remember correctly, before the final successful attempts, I had to expand my vhd because it was gonna "bulge" (from 1gb to 2gb). I am saying this because I do not know if the previous failures were also due to the too small size of the vhd. What I am able to confirm here is that the only configuration that I have seen working so far on 2 machines are those posted above.

nino



#35 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 March 2019 - 09:10 AM

as for my machine's last-nite glitch, i can tell you that this morning it coldbooted fine as ramdisk but some startup entry crashed, which did not on the later filesystem boot, and I presume it won't on next ramdisk reboot. I still wonder what it could be.

back to my previous post, want me to try your menu.lst entries to see if they work with a calm large-enough vhd?

nino



#36 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 17 March 2019 - 09:45 AM

as for my machine's last-nite glitch, i can tell you that this morning it coldbooted fine as ramdisk but some startup entry crashed, which did not on the later filesystem boot, and I presume it won't on next ramdisk reboot. I still wonder what it could be.

back to my previous post, want me to try your menu.lst entries to see if they work with a calm large-enough vhd?

nino

 

With your description, it appears that the SVBus driver loaded too early or too late. some times it works fine, but some times it does not work.

 

And still I have the impression of hardware conflict, between driver and mainboard. The SVBus driver might have a timing issue with this hardware.



#37 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 March 2019 - 09:58 AM

believe me, I probably forgot to tell you before, firadisk has always failed all the way down thru my past 30 days or so tests. those hours I have spent on my wife's computer this morning i remember her machine having firadisk which I later replaced with svbus and it behaved the same as before using the above menu.lst commands, even on my machine that i am typing from. i never got wimboot to work with firadisk anywhere.



#38 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 17 March 2019 - 11:34 AM

believe me, I probably forgot to tell you before, firadisk has always failed all the way down thru my past 30 days or so tests. those hours I have spent on my wife's computer this morning i remember her machine having firadisk which I later replaced with svbus and it behaved the same as before using the above menu.lst commands, even on my machine that i am typing from. i never got wimboot to work with firadisk anywhere.

 

Test, just need a test, if you have enough time, to see if firadisk could work fine with your hardware.

 

Sure, firadisk might not support Win10. So you may consider using Win7 32bit (or whatever OS that firadisk supports) to test.

 

Use the same OS to test, and the same map options "--mem  --top".

 

The result, as I expect, would be Success with firadisk and Failure with SVBus.

 

If it was confirmed, then this would be helpful for the developer schtrom to fix it, I suppose.



#39 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 March 2019 - 12:18 PM

Dear tinybit,

what I have said so far refers exclusively to wimboot and I can confirm the exact opposite of what u are saying, svbus does work, and firadisk does not. before the wimboot era, it was exactly as you said, regardless of the os. I used to have firadisk always working fine with windows 10 (version is 16299 and i won't go any higher). before the wimboot era, it was svbus that did not work properly and made me stay with firadisk until I had to switch to svbus if wanted to wimboot. I had already used my hours with firadisk before resorting to something more viable since I started wimbooting. I think it has to do with the combination of vhd and wim. whatever changed with the introduction of wim, as far as I am concerned. Svbus is not the culprit.

nino



#40 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 17 March 2019 - 01:27 PM

antonino61, on 17 Mar 2019 - 8:18 PM, said:

Dear tinybit,
what I have said so far refers exclusively to wimboot and I can confirm the exact opposite of what u are saying, svbus does work, and firadisk does not. before the wimboot era, it was exactly as you said, regardless of the os. I used to have firadisk always working fine with windows 10 (version is 16299 and i won't go any higher). before the wimboot era, it was svbus that did not work properly and made me stay with firadisk until I had to switch to svbus if wanted to wimboot. I had already used my hours with firadisk before resorting to something more viable since I started wimbooting. I think it has to do with the combination of vhd and wim. whatever changed with the introduction of wim, as far as I am concerned. Svbus is not the culprit.
nino

Yes the newly SVBus would work fine with win10 and, as you told, with wimboot too. But what I want to emphasize is, the new, good, ideal SVBus might unluckily have bugs, or say, it might depends on the hardware. On some hardware it works, on others it might not work smoothly.

Your description on the problem intimates that something is wrong with the driver, not with other aspects of the whole thing. And the problem only links to the --mem --top. This hints that the issue has something to do with the memory handling portion of the driver.

The only role of SVBus is "to drive the image" or say "to provide sector-data-access service". If this work is finished, there shouldn't be any problems. Problems occurs, so the work is not done.

You may carry out another test: load VHD in low memory, i.e., below 4G (without --top option) and see how it goes. If that goes fine, then it also indicates that the problem is related to "over 4G" high memory handling.

"Sector data not offered", I think that is (almost) certain. Uhhhh...... I am wondering if karyonix could have a look at this issue and help to fix the memory handling issue.

#41 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 March 2019 - 01:46 PM

 

excuse me, I do not know if it is connected to what you are trying to find out, but since I started internal (non-usb) rambooting, I have always had the following menu.lst content:

 

title Windows 10 - FILEDISK1
map (hd0,0)/vhd1.vhd (hd1)
map --hook
root (hd1,0)
chainloader /bootmgr
 
title Windows 10 - RAMDISK1
map --mem --top (hd0,0)/vhd1.vhd (hd1)
map --hook
root (hd1,0)
chainloader /bootmgr
 

How is your HD partitioned/formated, because first point to check since the begining is:

 

 

The only limitation is that booting from RAMDISK requires booting in BIOS mode with Grub4dos.

Hopefully we can have UEFI Secure support when Grub2 in future might be able to load such VHD into memory and launch Windows by chainloading bootmgfw.efi  :rolleyes:  :unsure:

But anyway booting from Windows Boot Manager menu as FILEDISK using Microsoft vhdmp.sys driver is available in BIOS and in UEFI Secure mode.

 

 

Answer this first before going furter, please.

 

alacran



#42 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 March 2019 - 01:59 PM

My dear Alacrán, 

I had taken this for granted all the way through - single mbr partitions everywhere on my workstation and my wife's laptop. as for the asus transformer, which forces me to have 3 partitions or so, as it has no traditional bios, I am waiting for the innovation (*.efi) you have mentioned. getting back to the previous machines, I boot them through windows bootmgr, through last version of grub4dos as filedisk and through last version of grub4dos as ramdisk. I have no grub2.



#43 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 March 2019 - 02:02 PM

@tinybit, 

what works does and what does not does not with --mem, --mem --top, --top --mem and nothing (filedisk)

nino



#44 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 March 2019 - 02:03 PM

Assuming your HD is MBR formated:

 

You said, you are using this on your menu:

title Windows 10 - FILEDISK1
map (hd0,0)/vhd1.vhd (hd1)
map --hook
root (hd1,0)
chainloader /bootmgr
 
title Windows 10 - RAMDISK1
map --mem --top (hd0,0)/vhd1.vhd (hd1)
map --hook
root (hd1,0)
chainloader /bootmgr

Previous Menu is valid only for the case where files are on (hd0,0), and as the VHD is mapped to hd1 it should work fine.

I suggest you better use this generical menu (it is valid for any location of your files) and also maps them to the next free hd allways.

title Windows 10 - FILEDISK1
find --set-root --ignore-floppies /vhd1.vhd
map /vhd1.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

title Windows 10 - RAMDISK1
find --set-root --ignore-floppies /vhd1.vhd
map --top --mem /vhd1.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

Also in order to boot from Ram (Ramboot), verify from FileDisk running OS the BCD located into C:\Boot\BCD is as my pictures, of course addapt the VHD name/location/lang to yours. After this, open the same BCD this time on Professional Mode and verify Boot Menu Policy is Legacy as on attached picture.

 

alacran

 

EDIT: "No integrity checks" is not mandatory to Ramboot, you can let it unchecked.

Attached Files



#45 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 March 2019 - 02:29 PM

Ok, I'll check that out when I get home, at least on an internal basis.

#46 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 17 March 2019 - 02:29 PM

@tinybit, 

what works does and what does not does not with --mem, --mem --top, --top --mem and nothing (filedisk)

nino

This sentence is too complex. Sorry but I cannot understand.



#47 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 March 2019 - 02:51 PM

I meant that it makes no difference here; only hd addressing does.

#48 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 March 2019 - 03:36 PM

both

 

title Windows 10 - FILEDISK1
find --set-root --ignore-floppies /vhd1.vhd
map /vhd1.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

and 

title Windows 10 - RAMDISK1
find --set-root --ignore-floppies /vhd1.vhd
map --top --mem /vhd1.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

work perfectly.

 

boot menu policy is standard (in the case of ramdisk)

give me a few mins to tell you if it is the same in the case of filedisk, pls

nino

ps.: another thing i have always taken for granted --> why have vhd and wim have to be on a drive other than the same drive, i.e. the most natural drive where a system would have booted in the conventional way as well? 



#49 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 March 2019 - 03:39 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



#50 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 17 March 2019 - 04:14 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

 

By this description, it again appears to me a hardware issue, maybe a defective memory bank.


  • 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