Jump to content











Photo
- - - - -

ramloading Windows 10 vhd-core

windows linux window10 vhd ramloading

  • Please log in to reply
10 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
  • 14132 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
  • 14132 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
  • 14132 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
  • 14132 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
  • 14132 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







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