Jump to content











Photo
- - - - -

ramloading Windows 10 vhd-core

windows linux window10 vhd ramloading

  • Please log in to reply
188 replies to this topic

#26 sebus

sebus

    Frequent Member

  • Advanced user
  • 363 posts

Posted 10 February 2019 - 04:05 PM

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

 

It was in fist post - 5gb big



#27 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 10 February 2019 - 04:37 PM

It was in fist post - 5gb big

Which first post? :unsure:

First post in this thread?

But it is by nino61.

 

First post in the SVBUS thread (the thread I was making reference to) by antonino61 seems this one :

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

 

antonino61:

http://reboot.pro/us...650-antonino61/

 

 and nino61:

http://reboot.pro/user/69337-nino61/

 

are two distinct members, both Italians, i.e. coming from the people of "POETS ARTISTS HEROES SAINTS THINKERS SCIENTISTS NAVIGATORS TRANSMIGRATORS" and (seemingly) confusion due to similar names ;).

 

:duff:

Wonko



#28 steve6375

steve6375

    Platinum Member

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

Posted 10 February 2019 - 06:06 PM

I think this is https://github.com/c...4dos/issues/186

Which was reported some time ago

grub4dos changed the way upper memory is allocated.

I asked the user to try various commands.


  • quarky42 likes this

#29 steve6375

steve6375

    Platinum Member

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

Posted 10 February 2019 - 06:30 PM

try

map --top --mem /xx.vhd (hd1)


  • quarky42 likes this

#30 wimb

wimb

    Platinum Member

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

Posted 10 February 2019 - 09:35 PM

try

map --top --mem /xx.vhd (hd1)

 

TOP  :thumbup: The problem is solved by using the --top option as described.

 

grub4dos-0.4.6a-2018-12-23.7z version is loading OK my 10 GB VHD into RAM

 

W10x86-RAM-G4d-top-2019-02-10_222425.png

 

@Wonko - Thanks to steve6375 there is no need to contact chenall about it anymore.

 

:cheers:

title W10x86-VHD - RAMDISK
find --set-root --ignore-floppies /W10x86.vhd
map --top --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


  • quarky42 likes this

#31 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 11 February 2019 - 12:39 AM

@Wonko

I am afraid antonino61 and nino61 are one and the same person. I did not mean to schizophrenically split my personality. I simply did not know, when nino61, that it was so simple to re-sign oneself to be still able to heed comments and stuff, so I thought I had to re-subscribe, and I was obviously allowed to do that only with a different id. nino is the short for antonino anyway. 

As regards your pointing out the small size of the vhd to anul the functional difference between firadisk and svbus, I think you have perfectly read my mind. I have tried big vhds for this week thru, to check if I could take advantage of the "new" superfast g4d in preramloading, which i did appreciate. I thought I would also appreciate the operating speed of the 10gb-or-so vhd, which had spared me the trouble of moving all those folders out of the vhd, thus leaving the clean windows install all intact on it (c:\). Unfortunately, and counterintuitively, I can assure you that the best and fastest working vhd is the shrunk one (which contains the core of files and folders windows strictly needs to reach the interface) and of course place the rest of the folders I once mentioned out of the vhd and junction them back in. I know the procedures by heart by now, and I am prepared to rewrite the list of what to keep in and what not to anyone interested in it.

nino



#32 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 February 2019 - 07:44 AM

 

TOP  :thumbup: The problem is solved by using the --top option as described

....

@Wonko - Thanks to steve6375 there is no need to contact chenall about it anymore.

 

Very good. :smiling9: (and good to know :))

 

Everything is back to normality (though we still have this (accidental) dual identity of nino/antonino, but now that we know it and that presumably "antonino" (or "nino") won't come back anymore, all is cool and dandy).

 

@nino61

Each and ever report/experience/idea/result of tests/whatever is always welcome and useful, even if it may seem not initially, someone may find it of use at a later time, so - by all means - do report your experiences.

 

You should however IMHO take a decision and decide to post from  now on ONLY as "nino61" or "antonino61", besides the confusion, this double identity could easily bring you to a ban :w00t: :ph34r:, it is among the basic rules of any board that duplicate logins are a no-no.

 

:duff:

Wonko



#33 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 11 February 2019 - 08:04 AM

I understand and, as u can see, it is much more comfortable to stay antonino61, now that I have learned to re-sign automatically with just one click. Conversely, it would be much harder for me to catch the exact password for nino61, which would make me keener on choosing it as the one identity thru which I would not come back anymore, if I may, on a stare-decisis-et-quieta-non-movere basis.


Edited by antonino61, 11 February 2019 - 08:05 AM.


#34 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 February 2019 - 10:09 AM

Good. :)
 
Time to go back to the (endless) issue on root vs. rootnoverify.  :frusty:

root should be ALWAYS used whenever the target is an actual volume/filesystem which is "sound" and accessible (i.e. formatted as FAT12/16, FAT32, CDFS, NTFS or CDFS, and I believe also recently UDF) .

rootnoverify MUST be used whenever the the target is NOT an actual volume/filesystem OR it is not accessible (i.e. it is encrypted or whatever)
.
Once a root has been established it makes NO SENSE whatsoever to hardcode the device root, nor using find --set-root.
 
This:
 
rootnoverify (hd0,0)
chainloader (hd0)+1
 
is essentially "absurd", either of:
 
 
root (hd0,0)
chainloader +1
or:
 
 
rootnoverify (hd0)
chainloader +1
are "better".

The first proposed chainloads the PBR code bypassing the MBR code, the second one (like the originally posted by Wimb) chainloads the MBR code of the VHD.

BOTH are anyway an "overlay" :w00t:, the "right" one (in my perverted mind ;)) being:
 
root (hd0,0)
chainloader /bootmgr
which bypasses BOTH the MBR and the PBR code.
 
In a nutshell you could have a MBR with ONLY the partition table and a PBR with only the BPB and the .vhd would boot anyway.
 
:duff:
Wonko
  • wimb and quarky42 like this

#35 wimb

wimb

    Platinum Member

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

Posted 11 February 2019 - 10:37 AM

BOTH are anyway an "overlay" :w00t:, the "right" one (in my perverted mind ;)) being:

 
root (hd0,0)
chainloader /bootmgr

which bypasses BOTH the MBR and the PBR code.

 

In a nutshell you could have a MBR with ONLY the partition table and a PBR with only the BPB and the .vhd would boot anyway.

 

 

 

OK, i agree completely with you and will use your "right" menu.lst entry in UEFI_MULTI

title W10x64.vhd - SVBus  FILEDISK - 10240 MB
find --set-root --ignore-floppies /W10x64.vhd
map /W10x64.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

title W10x64.vhd - SVBus  RAMDISK  - 10240 MB
find --set-root --ignore-floppies /W10x64.vhd
map --top --mem /W10x64.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

which is working OK for booting W10x64.vhd from RAMDISK.

 

However, the size of the full Win10x64 VHD should be increased at least to 12 GB .....

 

W10x64-SVBus-RAM-2019-02-11_120913.png == UEFI_MULTI-SVBus-2019-02-11_132449.png

 

The menu entry that I used previously was advised by schtrom the creator of SVBus driver.

 

Use the following menu.lst entries to boot the VHD file with TrueCrypt:

 

Thanks for your help  :)



#36 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 February 2019 - 12:47 PM

The menu entry that I used previously was advised by schtrom the creator of SVBus driver.

No, you see how it is easy to generate urban legends? ;), it wasn't really-really advised by him.

 

It was advised by him - after Vortex and Soltis reported success directly chainloading bootmgr - in a "special" case:

 

in combination with TrueCrypt V7.1a full system disk encryption

In this case you actually need to chainload the MBR (though I still doubt that it is needed to set root to the volume,  but if it is, then the rootnoverify is actually needed because the volume is encrypted and thus root would throw an error).

 

:duff:

Wonko



#37 wimb

wimb

    Platinum Member

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

Posted 11 February 2019 - 01:26 PM

Yes, the menu.lst entry that schtrom published was  meant and may be needed for the TrueCrypt case.

 

Win10x64 VHD will need at least 12 GB Size.

 

More useful is to go for Win 8.1 x64 booting from RAMDISK

Here I can use my program to reduce size and work with a VHD of 7 GB for Portable Win 8.1 x64 VHD

 

W864_SVBus-RAM-2019-02-11_141504.png



#38 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 February 2019 - 02:48 PM

You should use double quotes when you use "portable" on the same line with 7 GB (let alone 12 GB) ;)

:rofl2:

More seriously, and back to the original topic, the approach by nino61 is IMHO the smartest one, 5 GB (whilst what I would define "a senseless amount of bloat") + the "whatever" needed (fetched from the "outer" volume) is much better than 12 GB.

 

I mean, if one has "only" (please note the double quotes) 8 GB of RAM, he/she may still be able to run a Windows 10 VHD.

 

When (if) Nino will be able to detail his setup, we will see if it is possible ("common sense" tells me that it should be possible, but Windows 10 is the living negation of ANY "common sense") to further reduce the size of the VHD.


:duff:
Wonko



#39 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 11 February 2019 - 04:31 PM

Wonko, would you rather I posted a few screenshots of my directory trees in the vhd and the host disk than I listed the 2 directory lineups?



#40 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 11 February 2019 - 04:38 PM

as far as the "will be ready" is concerned, I am ready to do it right now, as I believe this less-than-5gb vhd layout is the most advantageous of all regardless of how much ram you have. I can say so because I tested 10gb vhds on 64gb of ram, and I can tell you that for some reason unknown to me their not as fast as small vhd. the only why i can think of is that windows apparently prefers running things one by one to keeping what is unneeded in memory.



#41 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 11 February 2019 - 04:42 PM

another advantage to take into account is that you can time-and-space-wise afford to install a new system whenever, and as often as, you wish without losing 1 setting (including website passwords, for example). You actually change the core in the vhd and keep all the software as it was when you had the previous vhd, by doing this copy-over, of course.



#42 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 February 2019 - 05:40 PM

Wonko, would you rather I posted a few screenshots of my directory trees in the vhd and the host disk than I listed the 2 directory lineups?

 

Screenshots are NOT useful.

 

Text files are fine :), as made by a (example):



DIR /S /B C:>D:\VHDDIR.TXT

and (again example)



DIR /S /B D:>E:\OUTERDIR.TXT

It is IMPORTANT that you use the /B switch (or equivalent, if you use another way to get the listing), so that each line is "complete in itself" and can be re-used for *any* script, there is no need to know size, date of files, etc.

 

:duff:

Wonko



#43 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 11 February 2019 - 06:43 PM

My dearest wonko, 

I can provide the lists almost by heart. It will have been my 2nd time, as I have already given an unofficial detailed accounting of file and folder placement in previous posts. Now I see that you are talking of scripts. Are you up to an automation of the process I have carried out manually? Whatever I am going to post is to be done on a post-install basis, but I gather you want to do that on a pre-install basis. Have I understood correctly?Shall I be glad if I have!

Anyway

this is the agenda leading to my present deployment

1) clean windows install on a 20gb vhd (the famous shift/f10 and diskpart as soon as the first install screen comes up) (if possible, there would not even be an installation proper, as you sometimes can prepare the vhd with gimagex if you have a clean install.wim coming with the w10 build, which is almost never the case though)

2) driver install until everything is fine in device manager

3) turn as many features on from the control panel (in my case I always blank internet explorer and windows media player as I prefer 3rd party software (maxthon and media player classic)

4) debloat windows with windows debloater (it is just out there when you google it)

5) for making things straight I suggest you use registry first aid (it finds and corrects many path problems / believe me, there are so many of them even on a clean install before debloating)

6) merge "install takeownership.reg", "copy to.reg" and "move to.reg" into the registry (they are just out there when you google them)

7) install HardLinkShellExt_X64.exe 

8) install easybcd (another one out there if you google it)

9) Now the relocation proper - I suggest you copy your vhd to the same folder, so you would have 2 vhds named differently from each other.

10) mount the copied one and move "program files", program files (x86) and program data off the vhd onto the host disk (the one windows sees as d:\, most typically) 

11) pick the 3 link sources from d:\ and junction them to the just deprived vhd (pick link source and drop them as junctions (2nd option on the drop list).

12) unmount the copy vhd and include it as a possible booter in the easybcd list.

13) restart and reboot into the just made easybcd entry from the boot list

14) now that you are in the windows interface delete the original vhd and copy the copied one you are booted on as the new "original" (keep the same names when you do these things, so you won't have to reconfigure bootlists thru easybcd).

15) mount the new "original" and perform on the whole users folder the same as you have done with program files, program files (x86) and programdata.

16) after you have repeated the same procedure with users (up to the junction stage), restart and reboot with the new "original"

17) repeat the same operation and this time it is the copied vhd's turn to work on - go to the windows folder and open it; be careful now - you want to move everything to a windows folder on d:\, except for the following directories:

c:\windows\boot

c:\windows\en-us

c:\windows\fonts

c:\windows\inf

c:\windows\system32

these directories I have just listed, together with the files on the c:\windows root (to the best of my knowledge and belief) must remain on c:\, so don't move them anyplace else.

18) repeat the same operations as before and of course always choose to boot into the more "lightened" vhd (the one that contains the most recent changes) 

19) delete the other one and copy the most recent you are just booted on with the same name as the one you have just deleted.

20) mount it, go to the system32 folder and open it - now you wanna move all subfolders to a windows\system32 folder on d:\, except the following ones:

c:\windows\system32\catroot

c:\windows\system32\codeintegrity

c:\windows\system32\config

c:\windows\system32\drivers

these directories I have just listed, together with the files on the c:\windows\system32 root (to the best of my knowledge and belief) must remain on c:\, so don't move them anyplace else.

21) repeat the same operations as before and of course always choose to boot into the more "lightened" vhd (the one that contains the most recent changes) - at this point, still to the best of my knowledge and belief, which I wish were much greater, I do not think you can lighten the vhd content anymore - If wonko or anyone else discovers otherwise, pls tell - I haven't yet. I suggest u should make no further moving off the vhd until elsewhere and otherwise verified.
22) now shrink the vhd with any partition resizer and leave at least 700mb empty space on it.
23) restart and reboot from the other vhd
24) resize the shrunk vhd with vhd resizer and you must have a 4-5gb vhd ready to go.
Should you run into problems, restart from the other vhd, which was actually the last to boot ok.
If you have any questions, do not hesitate to ask.
nino

Edited by antonino61, 11 February 2019 - 06:57 PM.


#44 quarky42

quarky42

    Member

  • Members
  • 38 posts
  •  
    United States

Posted 11 February 2019 - 07:09 PM

(...) I know the procedures by heart by now, and I am prepared to rewrite the list of what to keep in and what not to anyone interested in it.
nino


This whole thread has been immensely helpful. I would be very grateful for a list of what you've moved off of the C: drive. I am moving non-essential things to a second vhd file that will be loaded after windows is booted up. I have a good start on it, but would love to learn what you've found to move in your experience. I really appreciate being able to learn from others. Thank you so much for being so helpful in the forums.

I am able to boot my old previously working Windows 10 image using the new grub4dos with the --top option added to it. I'm glad that works and even better thanks to you guys sharing the info on how it changed. Now that I am back to a working baseline with the new grub4dos bootloader on the disk, I can try and figure out what I need to do to the new image to make it work.

#45 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 11 February 2019 - 07:15 PM

Dear Quarky,

my experience only entails moving folders off of the c:\ (which is a vhd) into the root of the host drive (presumably d:\). it does not extend to a 2nd vhd loaded after the booting. if it can be done and is quicker, pls help. I would not know how to reload the 2nd vhd in time for windows to reach the interface ok. in my case, the files that have been moved to the host drive are junctioned to the vhd (c:\) anyway.


Edited by antonino61, 11 February 2019 - 07:17 PM.


#46 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 February 2019 - 07:36 PM

Antonino, with all due respect (as you already achieved a very good result) :), your steps are "a lot" and it is easy to get confused with them, hence (IMHO) the need to script at least part of them, or, if you prefer, I doubt that many people will have the patience and perseverance to try and replicate them, let alone replicate them successfully.

 

The point on which I cannot agree:

 

 

these directories I have just listed, together with the files on the c:\windows\system32 root (to the best of my knowledge and belief) must remain on c:\, so don't move them anyplace else.

the whole point being that a large number of files in C:\Windows\System32 (surely most if not all the command line tools, but not only them) do not *need* to be there, and can be moved *anywhere* as long as the new path is in the PATH variable.

 

All in all, I see not your current achievements as a point of arrival, but rather as a starting point ...  ;)

 

http://reboot.pro/to...rthday/?p=15859

 

:duff:

Wonko


  • quarky42 likes this

#47 quarky42

quarky42

    Member

  • Members
  • 38 posts
  •  
    United States

Posted 11 February 2019 - 07:41 PM

Dear Quarky,

my experience only entails moving folders off of the c:\ (which is a vhd) into the root of the host drive (presumably d:\). it does not extend to a 2nd vhd loaded after the booting. if it can be done and is quicker, pls help.

 

There is nothing wrong with doing it your way.  In fact it is a rather elegant simple approach.    I was just meaning to say that I was requesting your list.  I see, now that I am on a real browser instead of my phone, that you did provide a list and I will check that out shortly with the time it is definitely due.

 

I'll take care of putting the files into a VHD and mounting them as a ramdisk.    It just helps to have something to start with where I don't have to reinvent the wheel.   If you think of things that might not have made it into the detailed post above, please feel free to edit it and add to it.  It's a great resource for people trying to shrink their Windows installs to the bare minimum.     Once I do it, if you are interested, I'll be glad to share, but it isn't necessarily better than what you are already doing.  I'm just indicated that the information you shared will help in creating new solutions for other challenges.  I hope that makes sense.   No critique of your method / means was intended or meant to be implied by what I said.



#48 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 11 February 2019 - 07:48 PM

@wonko

So, you mean that if i add d:\windows to the path variable i can also move the files on the c:\windows and c:\windows\system32 folders to d:\windows and d:\windows\system32 folders and the system will boot ok? it it will, do I need to add d:\windows\system32 to the path variable as well? if not all, which ones should not be moved anywhere as the system needs them on c:\ for booting up ok?

As far as the script is concerned, what shall I do to make it simpler?


Edited by antonino61, 11 February 2019 - 07:54 PM.


#49 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 11 February 2019 - 07:54 PM

Dear Quarky, 

there musta been a misunderstanding here. I am not in the least upset; I really meant what I said - I do not know how to automate the loading of a second vhd in time for windows booting requirements (viz, if windows needs a certain file on c:\ in the booting routine, how can it be fetched to suit its liking if the d:\ still has to be recognized and it has not yet been?), nor do I know whether it would be quicker that way. one step forward would be to move the files normally in the windows and windows\system32 root subfolders off of the c:\ vhd into d:\windows and d:\windows\system32 respectively in order to shrink the c:\ vhd even further.

As wonko adds, the d:\ path or paths in the environment variable should be added as well.


Edited by antonino61, 11 February 2019 - 07:57 PM.


#50 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 11 February 2019 - 08:49 PM

As regards the point of arrival, I think it will be reached when we do know which files windows needs for booting up and reaching the interface, which should be placed or kept exactly where windows expects them to be. all the rest, with our efforts and contributions, should stay off of c:\ anywhere. if only we could have a list of all the files involved in the process from switching the computer on to the appearance of the windows interface, that would be the greatest help. I am also referring to c:\windows\inf and c:\windows\system32\drivers directories, which contain files that do not get involved in the booting of this particular machine but do get involved in the booting of another particular machine (drivers and infs related to devices that are not part of the machine concerned - eg, does windows need to load 10 printer drivers for only 1 printer? and so on and so forth).

pls correct me if I am wrong and fruitfully contribute to the discussion.
 







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

2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users