Jump to content











Photo
- - - - -

ramloading Windows 10 vhd-core

windows linux window10 vhd ramloading

  • Please log in to reply
188 replies to this topic

#1 nino61

nino61
  • Members
  • 8 posts
  •  
    Italy

Posted 22 January 2018 - 06:58 PM

title W10 VHD RAM
map --mem (hd0,0)/WXLT.vhd (hd0)
map --hook 
root (hd0,0)
find --set-root --ignore-floppies /bootmgr
chainloader /bootmgr
 

I have adopted this policy for years. My vhd (which is anyway faster than an ordinary machine deployment scenario on conventional booting) is only 5gb big. how? program files, program files (x86), program data, users and most of windows (exept for those subdirs that the system requires on c:\ (the vhd) to arrive at the desktop interface) reside elsewhere, in d: (you will have twigged it is the physical 1st disk) and are junction-linked to c:\. So, persistence is not an issue to me, unless I have to install new software, which I always do on a conventional system loading basis; nor is it preloading time an issue, as it preloads in about 6-7 secs. I also use 20gb of my ram for temp and swap (4gb (for any of those stupid programs that actually require it) with primoramdisk) and other 20gb committed to read&write cache (primocache, which speeds up disk writing after the Windows built-in caching takes care of everything). I insist on booting off a vhd-residing core as it is the best way of having it almost unchanged in size and content, as anything new practically takes place outside of it. The steady-core vhd contains what windows seems to need to find in it in order to arrive at the interface; whatever is strictly application-bound and consequently prone to change stays outside of it. I might change windows version, but the software I use is still the same, so I do not see why it should be "bundled" into that specific windows software architecture. Let us consider it an extended form of relocation. The only slight issue that I have been able to keep track of is that bootup process diagnostics shows that the system persists on looking for a couple of system files on c:\, without this being of practical hindrance to arriving at the windows interface. I perceive a less snappy initial bootup stage (the starred circle rotating underneath the logo at the beginning), though, probably due to the above glitch. Is there anything I can do to improve? So far, neither from the registry (cannot delete entries) nor from the windows events (I really do not know how to) have I managed to redirect the system to most of the files it insists on looking for (which are expected to be on the vhd and are in fact softlinked to it from the SSD). Any suggestions on how to redress the windows grievance and give it a smoother bootup? 

I am looking forward to yuor learned suggestions.

 
Nino


#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15103 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 January 2018 - 08:43 PM

 

title W10 VHD RAM
map --mem (hd0,0)/WXLT.vhd (hd0)
map --hook 
root (hd0,0)
find --set-root --ignore-floppies /bootmgr
chainloader /bootmgr

 

Are you booting from the \BOOTMGR inside the .vhd? :unsure:

If yes, then you don't need to find anything, i.e. this would do:

 

 

title W10 VHD RAM
map --mem (hd0,0)/WXLT.vhd (hd0)
map --hook 
root (hd0,0)
chainloader /bootmgr

 

Now, if you actually LIST the "couple of files" you are having issues with, that might help.

 

Generally speaking (not necessarily your case, mind you) softlinks are not "instantaneous", they depend on the filesystem driver (and the softlink related filter driver, cannot say if it is self-standing or integrated in the filesystem/volume driver in Windows 10) so it is possible that in the earlier part of booting they are not available.

 

If this is the case :dubbio: it is possible that the slowdown you noticed is not really due to the files residing on the SSD (which is anyway very, very fast) but rather the OS that while booting performs some desperate search for a file that is not (yet) where it believes it to be.

 

:duff:

Wonko


  • nino61 likes this

#3 nino61

nino61
  • Members
  • 8 posts
  •  
    Italy

Posted 22 January 2018 - 10:33 PM

Wonko,
 
title W10 VHD RAM
map --mem (hd0,0)/WXLT.vhd (hd0)
map --hook 
root (hd0,0)
chainloader /bootmgr
 
the "ignore-floppies" line I added it just yesterday, in the attempt to speed up preloading, as I must have profanely understood that the process would somehow be sped up by "ignoring what was not needed" (e.g. floppies). If it is totally ineffective, I will certainly remove it and restore it to the original sequence. Concerning bootmgr location, since I started ramloading vhds I have always had  two of them, one on the actual SSD and the other inside the vhd, both together with their boot directories (bcdboot #:\windows /s #:, you know what I mean). The few times I deleted bootmgr and its directory from the SSD root, I never got it to boot after the preloading stage. If you tell me how to boot it with bcd in vhd only, I will act accordingly. From reading the past literature here I think one of you said that in order to start the process, bcd has to be found in the ssd and then in a next stage the activities would be transferred to the bootmgr inside. If you mean that I boot directly from the vhd in such a way than my answer is yes, but I very much doubt it. I hope I am wrong anyway. 
 
Talking about the couple of files glitches, as I have always suspected, @the slowdown I noticed is not really due to the files residing on the SSD (which is anyway very, very fast) but rather the OS that while booting performs some desperate search for a file that is not (yet) where it believes it to be@. As for those files that were unavailable in the earlier part of the booting, I had quite a few system lockups and BSODs before I found out which files could be safely "exported" to the SSD and which not for the system to complete its process to the interface. But if you say that this still does not mean that the system is not better off having them available asap, tell me if it could still be "oriented" or "shown" to them when it wants them or if they and only they should be brought back inside the vhd. Smartfix 1.5.9 with the autorun selection found the following "couple of files" unavailable to the system:
 
\Microsoft\Windows\rempl\shell File not found: C:\Program Files\rempl\remsh.exe

_Wow64 File not found: C:\Windows\SysWoW64\Wow64.dll

_Wow64cpu File not found: C:\Windows\SysWoW64\Wow64cpu.dll

_Wow64win File not found: C:\Windows\SysWoW64\Wow64win.dll

 

Any ideas that you can think of?

 

Thanx in advance.

 

Nino


Edited by nino61, 22 January 2018 - 10:38 PM.


#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15103 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 23 January 2018 - 10:23 AM

It is not yet clear (to me at least) how exactly the whole thing boots.

There should be no issues if you have no \bootmgr or \boot\BCD on the SSD (as long as you have some way to load/boot to grub4dos.

 

As said it is likely that *somehow* you are booting in some form of "mixed mode" where a part of the needed boot files are actually in the .VHD loaded n RAM while a few (that are looked for there by the OS) cannot be found and thus the OS tries to find them *somewhere*, very probably on the "plain" hosting Disk drive/SSD.

 

At first sight the Wow64 should be related to the Windows 32 bit support subsystem so they shouldn't (at least in theory) be accessed during the early boot stage.

 

The rempl\shell  is more likely to be accessed early, if I get it right it is connected with scheduled tasks  and computer "wake up".

 

I have really no idea what SmartFix does (i.e. if it is accurate enough to detect the issue), it is more likely that it is doing a "static" analysis of the filesystem and those files you found are actually missing (they may actually slow down booting, but for a different reason from the one I guessed earlier).

 

What happens if you create a boot log? (no idea how it works/which level of details it has on Windows 10)

 

The next step would be a system trace.

 

The problem with it is that while making one is (relatively) easy (please read as "complex, but doable"), analyzing the result is actually complex/difficult:

 

https://msfn.org/boa...ernates-slowly/

 

:duff:

Wonko



#5 nino61

nino61
  • Members
  • 8 posts
  •  
    Italy

Posted 26 January 2018 - 06:39 AM

Wonko, 

 

I guess I just put a foot on my mouth: the missing files were actually missing from the directories they were supposed to be; something musta gone wrong during the file "transfers" from vhd to ssd. Once I placed them in the right directories, the system saw them even thru the softlinks and Smartfix did not detect them as missing anymore. Probably the syswoa directory is better off inside the vhd, speedwise I mean. As regards the rest, I have tried the system with and without primocache, and I can tell u that speed is noticeably higher with it than without it. What I have not yet been able to achieve is the boot thru grub4dos without the bootfiles being on the ssd as well (it loads and in the end it yields a bsod saying Inaccessible Boot device).

 

Nino



#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15103 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 26 January 2018 - 09:26 AM

What I have not yet been able to achieve is the boot thru grub4dos without the bootfiles being on the ssd as well (it loads and in the end it yields a bsod saying Inaccessible Boot device).

I am not sure to understand.

WHICH boot files?

The boomgr (and conversely the \boot\BCD) used in your menu.lst seem to be loaded from the .vhd, which after the map --hook command becomes first disk or (hd0) just fine. :unsure:

 

The grldr and menu.lst normally need to be somewhere accessible, but there is the possibility of using an unused space on disk, if you can use a "particular" MBR code, or use a "Vista boot floppy image" (though this has some issues with hybernate and with updates, which in your case of full RAM don't have any consequences anyway).

 

The info is here and there on this seemingly unrelated thread:

http://reboot.pro/to...in-bios-to-gpt/

 

 

:duff:

Wonko



#7 nino61

nino61
  • Members
  • 8 posts
  •  
    Italy

Posted 26 January 2018 - 07:09 PM

Wonko,

when you say somewhere accessible, do you mean inside the vhd or on the host ssd? I have boot bcd and bootmgr inside the vhd and menu.lst and grub4dos ouside on the host ssd. Is that correct?

nino



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15103 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 February 2018 - 11:24 AM

Wonko,

when you say somewhere accessible, do you mean inside the vhd or on the host ssd? I have boot bcd and bootmgr inside the vhd and menu.lst and grub4dos ouside on the host ssd. Is that correct?

nino

Sure, that is "correct" and "normal". :)

 

But - I believe - you are using *something else* as a "main" bootmanager (possibly another instance of BOOTMGR and \boot\BCD for a "resident" other install of Windows).

 

Depending on a number of factors you may be able to put also the grldr inside the .vhd using the UMBR and thus a "static", mapping of the file, but in that case there are a couple of caveats:

1) you cannot move the .vhd, nor defragment it (internally)

2) if you use the UMBR as your main MBR then the mapped grldr will become the "main" bootmanager (but of course you can chainload *anything* else from it)

3) you will need to edit the embedded menu.lst in the grldr adding to it the provisions for the .vhd booting

 

If you are using another BOOTMGR and \boot\BCD on the SSD it could be possible (never tried/tested it) to chainload the UMBR from the \boot\BCD, but all in all I don't think that it is worth the hassle.

 

On the other hand, even if finding and loading the menu.lst is usually very fast, editing the embedded one will allow to get rid of the file (the menu.lst) and shave a few milliseconds from booting time, though what remains the biggest time consuming activities will remain the loading of the .vhd in memory and that cannot be reduced.

 

:duff:

Wonko 



#9 nino61

nino61
  • Members
  • 8 posts
  •  
    Italy

Posted 04 February 2018 - 04:30 PM

Wonko, 

I honestly don't know what UMBR is? All I know is that I have bootmgr and bcd on and off the vhd. For normal vhd baremetal booting I was never asked for the one inside; conversely, for pre-ramloading booting, if I do not have it inside the vhd, at the end of the preloading session I get a BOSD saying inaccessible winload.exe or something of the kind. And as far as I have tried so far, the absence of boot and bcd on the host results in the system's failing to boot. boot and bcd were preemptied (if any previously) and re-created through bcdboot c:\windows /s c:\ and bcdboot c:\windows /s d:\. If  you spot anything wrong in my operation and description, pls do not hesitate to tell me and I will try to right the wrong.

nino



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15103 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 February 2018 - 05:30 PM

Wonko, 

I honestly don't know what UMBR is? 

Sure you don't, it is not like the most publicized feature around, in the already given thread:

http://reboot.pro/to...in-bios-to-gpt/

namely here:

http://reboot.pro/to...-11#entry197690

but you will need to read a bit on the thread to understand the reason why (and when/where) it may be useful.

 

Anyway it wouldn't be an "improvement", while editing the embedded menu.lst might be  ( a very marginal anyway) one.

 

:duff:

Wonko



#11 Coclend

Coclend
  • Members
  • 3 posts
  •  
    American Samoa

Posted 21 March 2018 - 06:25 AM

Thanks for your info



#12 quarky42

quarky42

    Member

  • Members
  • 35 posts
  •  
    United States

Posted 09 February 2019 - 05:01 AM

nino, did you do anything to the Windows 10 bootmgr to be able to load it from grub4dos?  I feel like I'm missing something here.

 

I have Windows 10 x64 running inside HyperV with:

TestMode ON and DetectHAL ON.

firadisk is installed and shows "device ok" in the device manager.

 

My system has 64GB of RAM.  My image is just a hair under 16GB.   (In fact a year ago, I had this working...I'm trying to set it up again from scratch and running into problems after the bootmgr takes over and it sounds like you have yours running well.  Can you give me an idea of what I can check next?)

 

My menu.lst: 

map --mem (hd0,0)/Win10x64Ent.vhd (hd0)
map --hook 
rootnoverify (hd0,0)
chainloader /bootmgr
 
When I step through the menu.lst I don't have any errors.  The Windows 10 bootmgr takes over, sits on the spinning circle for about 15 seconds and eventually gives me a blue screen with a INACCESSIBLE BOOT DEVICE message.   
 
BCDEDIT says:
Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume1
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {82b54cbf-2c04-11e9-b51e-00155d5d6b02}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30


Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \WINDOWS\system32\winload.exe
description             Windows 10
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {2e530078-2bfc-11e9-afdd-9c2d2e857889}
displaymessageoverride  Recovery
recoveryenabled         Yes
testsigning             Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \WINDOWS
resumeobject            {82b54cbf-2c04-11e9-b51e-00155d5d6b02}
nx                      OptIn
bootmenupolicy          Standard
detecthal               Yes

It seems like the bootmgr from the hidden partition is being run properly but it can't find the Windows partition.  I don't think this is a grub4dos problem and I don't think it is a firadisk issue, but I'm not sure what is left.  Thanks for any insight you might be able to give in how you got the Windows 10 bootmgr to cooperate.  

 

How many partitions do you have in your VHD file?   Mine has two...the hidden boot partition and the main windows partition.  Did you modify the bootmgr / bcd files?   Thanks for your time.



#13 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 481 posts
  •  
    Italy

Posted 09 February 2019 - 07:42 AM

I have only one partition on my vhd (mbr, not gpt). your menu.lst entries look fine. I am not sure u can have it working on a uefi basis without tweaks or glitches. anyway, before u do anything else, try bcdboot c:\windows /s c: from an administrator-level command line from the root directory of your vhd. I presume u will have to change c: in the command into some other letter, as u presumably will not yet have been able to mount it as c:

I hope I have made myself understood.

nino



#14 wimb

wimb

    Platinum Member

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

Posted 09 February 2019 - 07:51 AM

I think you should use root instead of rootnoverify.

http://diddy.boot-la...tm#rootnoverify

 

Also in BCD you need to set bootmenupolicy Legacy

 

More Info on Grub4dos FiraDisk menu http://reboot.pro/to...-grub/?p=208797

 

http://reboot.pro/to...ct-make-mini-8/

 

 

Also you should use MBR VHD with one NTFS partition.

 

You can use WinNTSetup for Install of Win10 in VHD as described in

 

No Pagefile and Hibernate Off is also important so that the VHD is not entangled to the outside ....

 

Mount the VHD and use BOOTICE Professional mode to inspect or modify the Boot\BCD file inside your VHD.

Does the drive letter in Application Device and OS Device corresponds to the drive letter of the mounted VHD ?

If you see there <Unknown> then you need to make changes ...

testsigning and detecthal need to be set yes which is already OK in your case.

 

How about using Win10XPE WIM file for booting from RAMDISK ?


  • antonino61 likes this

#15 quarky42

quarky42

    Member

  • Members
  • 35 posts
  •  
    United States

Posted 09 February 2019 - 08:38 AM

I have only one partition on my vhd (mbr, not gpt). your menu.lst entries look fine. I am not sure u can have it working on a uefi basis without tweaks or glitches. anyway, before u do anything else, try bcdboot c:\windows /s c: from an administrator-level command line from the root directory of your vhd. I presume u will have to change c: in the command into some other letter, as u presumably will not yet have been able to mount it as c:
I hope I have made myself understood.
nino

Mine is mbr. The first partition is hidden and contains the boot folder, BCD file and the bootmgr in the root. I am able to boot windows 10 to hyperv directly with no problem. It is only when I boot the vhd through grub4dos that I get the behavior described above. I have tried both root and rootnoverify. No difference in behavior. I'll still with root going forward. I do have a working vhd elsewhere I can dissect to try and find out why it works and why this one I tried to create fresh doesn't, too.

I have a number of things to try thanks to you and wimb. Thank you both.

I do have the page file and hiberfile turned off already.

I'll try the other stuff and see what I can figure out. Thanks.

Edited by quarky42, 09 February 2019 - 08:45 AM.


#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15103 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 February 2019 - 09:24 AM

As a side note, another thing that you may want to try nowadays is to replace Firadisk with the new SVBUS driver by Schtrom:

http://reboot.pro/to...r-for-grub4dos/

 

:duff:

Wonko



#17 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 481 posts
  •  
    Italy

Posted 09 February 2019 - 10:19 AM

is it any better?



#18 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15103 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 February 2019 - 12:56 PM

is it any better?

I don't know :w00t: , but you should, since you tested it and  reported it as working first as ramdisk only, and then also as filedisk on that very same thread:

http://reboot.pro/to...r-for-grub4dos/

 

Loosely, the whole idea of that driver is that Windows 10 has some new behaviour that may (or may not) affect the working of older drivers (namely WinVblock, but possibly also Firadisk) expecially when used as filedisk on largish (20 Gb reported) .vhd images (explanation from the Author):

http://reboot.pro/to...b4dos/?p=207138

 

So, yes, I would say that it is "better" specifically when booting Windows 10 from largish .vhd's. 

 

:duff:

Wonko



#19 wimb

wimb

    Platinum Member

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

Posted 09 February 2019 - 02:35 PM

As a side note, another thing that you may want to try nowadays is to replace Firadisk with the new SVBUS driver by Schtrom:

http://reboot.pro/to...r-for-grub4dos/

 

:duff:

Wonko

 

I have used WinNTSetup to Install Win10x86 in 10 GB VHD located in 3rd partition of MBR harddisk.

After booting I used Instx86.exe to Install SVBus in VHD

 

I can MBR boot with Grub4dos the 10 GB W10x86.vhd file as SVBus FILEDISK

But for booting from Grub4dos as SVBus RAMDISK, then I get in Grub4dos

version grub4dos-0.4.6a-2018-12-23.7z using command

map --mem (hd0,2)/W10x86.vhd (hd0)

Error 28  Selected item cannot fit into memory

 

My Computer has 16 GB RAM, so I thought it might work ....

 

On same system I can boot Win7x32.vhd of size 2 GB using Grub4dos and FiraDisk RAMDISK driver.

 

What is the solution ?

 

WinNTSetup-2019-02-09_140126.png == SVBus-FILEDISK-2019-02-09_150106.png == Win7x32-VHD-FiraDisk-RAMDISK-2019-02-09_152104.png == Win10-RAM-2019-02-09_153845.png



#20 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15103 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 February 2019 - 04:29 PM

I have used WinNTSetup to Install Win10x86 in 10 GB VHD located in 3rd partition of MBR harddisk.

After booting I used Instx86.exe to Install SVBus in VHD

 

I can MBR boot with Grub4dos the 10 GB W10x86.vhd file as SVBus FILEDISK

But for booting from Grub4dos as SVBus RAMDISK, then I get in Grub4dos

version grub4dos-0.4.6a-2018-12-23.7z using command



map --mem (hd0,2)/W10x86.vhd (hd0)

Error 28  Selected item cannot fit into memory

 

My Computer has 16 GB RAM, so I thought it might work ....

 

On same system I can boot Win7x32.vhd of size 2 GB using Grub4dos and FiraDisk RAMDISK driver.

 

What is the solution ?

No ideas, though this:

On same system I can boot Win7x32.vhd of size 2 GB using Grub4dos and FiraDisk RAMDISK driver.

 

is totally irrelevant (from a common sense point of view).

 

Try using the SAME size (or the same file) for Win7x32.vhd with SVBUS (both as filedisk and ramdisk) AND try using the SAME size (or the same file) W10x86.vhd with firadisk and Winvblock (both as filedisk and ramdisk) and THEN you will have something to compare.

 

However, since the error happens long before the windows driver (be it Firadisk, WinvBlock or SVBUS) is used It could well be that there is something that prevents grub4dos (on your specific motherboard or the specific version of grub4dos) to see more than (say) 4 (or 8) GB of RAM.

 

I will repeat how the Author of the driver developed it expressly in order to use largish VHD's with Windows 10 in it as Ramdisk, and I trust him it is working, you could post your questions in a new thread or in the original release thread (hoping that he will see it) or try contacting him via PM or the like.

  

JFYI and for the record (as if you didn't know this) I use the SAME stick I used to NOT touch Vista to NOT touch Windows 10 and - being the old dinosaur I am - I have never seen 16 Gb of RAM all in a same computer, so you got the wrong person to ask this question, sorry. 

 

:duff:

Wonko



#21 wimb

wimb

    Platinum Member

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

Posted 09 February 2019 - 04:36 PM

It has nothing to do with the driver Or with the Win7 / Win10 OS.

 

Even if I use Grub4dos to load various empty VHD's into memory, then the size is limited to 2 GB max.

 

3, 4 and 6 GB VHD all fail to load into memory allthough I have 16 GB available as RAM

 

I am going to test now other Grub4dos version.

 

What version do you prefer to test ?



#22 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15103 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 February 2019 - 05:02 PM

What version do you prefer to test ?

Since the SVBUS driver was originally released in June 2018. I would try versions that were available a bit before that time, *like*:

http://grub4dos.chen....6a-2018-04-23/

 

BUT Misty (who is very reliable in his reports) posted (in November):

http://reboot.pro/to...b4dos/?p=208333

that he had success with "FULL" Windows 7 (presumably waaay larger than 2 GB) on his Lenovo Thinkpad W530 with 32 GB of RAM as a Ramdisk, so another that you could try could be:

http://grub4dos.chen....6a-2018-09-19/

 

Or maybe go all the way back to 0.4.5c:

http://grub4dos.chen....5c-2016-01-18/

 

:duff:

Wonko


  • wimb likes this

#23 wimb

wimb

    Platinum Member

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

Posted 09 February 2019 - 05:43 PM

Since the SVBUS driver was originally released in June 2018. I would try versions that were available a bit before that time, *like*:

http://grub4dos.chen....6a-2018-04-23/

 

BUT Misty (who is very reliable in his reports) posted (in November):

http://reboot.pro/to...b4dos/?p=208333

that he had success with "FULL" Windows 7 (presumably waaay larger than 2 GB) on his Lenovo Thinkpad W530 with 32 GB of RAM as a Ramdisk, so another that you could try could be:

http://grub4dos.chen....6a-2018-09-19/

 

Or maybe go all the way back to 0.4.5c:

http://grub4dos.chen....5c-2016-01-18/

 

 

 

Thanks for your suggested versions of grub4dos to be tested in RAM loading my 10 GB file. :thumbup:

 

The last one grub4dos-0.4.5c-2016-01-18 is working OK and all others fail in loading the 10 GB VHD into memory. 

 

But anyway the good news is that I have got W10x86.vhd booting from SVBus RAMDISK and also as SVBus FILEDISK   :)

 

SVBus-RAMDISK-2019-02-09_182726.png

 

:cheers:

title W10x86-VHD - RAMDISK
find --set-root --ignore-floppies /W10x86.vhd
map --mem /W10x86.vhd (hd0)
map --hook
rootnoverify (hd0,0)
chainloader (hd0)+1

title W10x86-VHD - FILEDISK
find --set-root --ignore-floppies /W10x86.vhd
map /W10x86.vhd (hd0)
map --hook
rootnoverify (hd0,0)
chainloader (hd0)+1


Misty is using here and Vortex here GRUB4DOS 0.4.5c 2016-01-18 for loading VHD into RAM



#24 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 481 posts
  •  
    Italy

Posted 10 February 2019 - 12:01 AM

I did actually report svbus as being good, even better than firadisk, at loading vhds either into ram or as filedisks. My report was stricto sensu confined to that. As soon as I saw that vhds loaded as filedisk did not retain changes to win install, I no longer saw any point in keeping on using svbus to load vhds as filedisks, and limited myself to using it only on a preramloading basis, which is exactly what I have always done with firadisk, with no issues. From that point on, i found no practical advantages of either one on the other. Sorry for not updating my report any earlier than I have done right now.

nino


Edited by antonino61, 10 February 2019 - 12:03 AM.


#25 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15103 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 10 February 2019 - 03:45 PM

@wimb

 

*Somehow* we must find a way to alert chenall or yaya about the issue, from your report it seems like the 0.4.6a introduced some changes that prevent grub4dos from working properly (as the last 0.4.5c version does).

 

Usually the "communication officer" is Steve6375 that (since he is usually using the latest-latest version in his Easy2Boot et similia) might be anyway interested in the matter.

 

If we don't see in a couple days a sign that Steve6375 noticed this thread, it might be the case of PM'ing him.

 

@antonino61

Unless I missed it, you never specified the size of the .vhd's you experimented with, if they are below or around 2 GB  most probably it doesn't make any difference.

 

:duff:

Wonko







Also tagged with one or more of these keywords: windows, linux, window10, vhd, ramloading

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users