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.
More deeper understanding of Mapped drive number for RamBooting Wimboot VHDs from internal HD using grub4dos + SVBus driver
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#26
Posted 16 March 2019 - 04:02 PM
#27
Posted 16 March 2019 - 04:33 PM
#28
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
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:
#30
Posted 17 March 2019 - 01:53 AM
#31
Posted 17 March 2019 - 03:47 AM
#32
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
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
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
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
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
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
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
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
Posted 17 March 2019 - 01:27 PM
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.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
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
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 - FILEDISK1map (hd0,0)/vhd1.vhd (hd1)map --hookroot (hd1,0)chainloader /bootmgrtitle Windows 10 - RAMDISK1map --mem --top (hd0,0)/vhd1.vhd (hd1)map --hookroot (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
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
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
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
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
Posted 17 March 2019 - 02:29 PM
#46
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
Posted 17 March 2019 - 02:51 PM
#48
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
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
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
Groups →
Project forge →
Summary of new tools for UEFI and MBR/CSM boot and RambootStarted by alacran , 24 Jul 2021 mbr, csm, uefi, grud4dos, grub2 and 1 more... |
|
|
||
Boot methods & tools →
Boot from USB / Boot anywhere →
SVBus_v1.3 signedStarted by alacran , 12 Dec 2020 ramboot |
|
|
||
Answered
Groups →
Windows Extreme →
Windows 10 →
Reducing wimboot source wim file using LZX Compression, and VHD using gzip or LZ4 Compression, to save room, and also load fas...Started by alacran , 21 Mar 2019 wimboot, ramboot, lzx, gzip, lz4 and 1 more... |
|
|
||
Answered
Groups →
Windows Extreme →
Windows 10 →
Making the smallest Win10 install (Wimboot mode) on 512 MB VHDStarted by alacran , 24 Feb 2019 wimboot, ramboot |
|
|
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users