@antonino61Unless 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
Posted 10 February 2019 - 04:05 PM
@antonino61Unless 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
Posted 10 February 2019 - 04:37 PM
It was in fist post - 5gb big
Which first post?
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 .
Wonko
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.
Posted 10 February 2019 - 06:30 PM
try
map --top --mem /xx.vhd (hd1)
Posted 10 February 2019 - 09:35 PM
try
map --top --mem /xx.vhd (hd1)
TOP 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
@Wonko - Thanks to steve6375 there is no need to contact chenall about it anymore.
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
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
Posted 11 February 2019 - 07:44 AM
TOP 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. (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 , it is among the basic rules of any board that duplicate logins are a no-no.
Wonko
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.
Posted 11 February 2019 - 10:09 AM
rootnoverify (hd0,0) chainloader (hd0)+1
root (hd0,0) chainloader +1or:
rootnoverify (hd0) chainloader +1are "better".
root (hd0,0) chainloader /bootmgrwhich bypasses BOTH the MBR and the PBR code.
Posted 11 February 2019 - 10:37 AM
BOTH are anyway an "overlay" , the "right" one (in my perverted mind ) being:
root (hd0,0) chainloader /bootmgrwhich 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 .....
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
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).
Wonko
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
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)
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.
Wonko
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?
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.
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.
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.
Wonko
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\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.
Edited by antonino61, 11 February 2019 - 06:57 PM.
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
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.
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
Wonko
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.
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.
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.
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.
Boot methods & tools →
Boot from USB / Boot anywhere →
VHD_Compact - Repair and Install of Windows 10/11 x64Started by wimb , 15 Mar 2024 winntsetup, windows to go and 2 more... |
|
|
||
winntsetup
Boot methods & tools →
Boot from USB / Boot anywhere →
I can't boot Windows installed into a VHD using WinNTSetupStarted by pioj , 10 Feb 2024 winntsetup, vhd, ventoy |
|
|
||
Boot methods & tools →
Boot from USB / Boot anywhere →
USBDualPartStarted by rradjab , 14 Jun 2023 dualpart, usb dual part and 7 more... |
|
|
||
Groups →
Windows Extreme →
Windows 7 →
Recommendations 4 Multi-boot Install Order Win, BSD, LinuxStarted by gentisle , 11 Sep 2022 windows, freebsd, linux and 1 more... |
|
|
||
Groups →
Project forge →
VHD to fixed driveStarted by alacran , 16 Aug 2022 vhd, vhd mounter |
|
|
0 members, 1 guests, 0 anonymous users