Jump to content











Photo
- - - - -

Making the smallest Win10 install (Wimboot mode) on 512 MB VHD

wimboot ramboot

Best Answer alacran , 20 March 2019 - 11:53 AM

Well, I think now this thread has all info, I'm going to make a summary of all relevant post you need to follow to be able to Create and Ramboot from a Wimboot VHD and also how to make a compressed copy (to keep as backup) of the coupled files required to wimboot.

 

I started this thread thinking the smallest the best, and was able to run a 512 MB VHD, as the name of the thread says, but during the development of this thread I change my mind and decided that a 1.5 GB VHD is a good size to load a VHD in RAM on an acceptable time, and this size VHD is also capable to Ramboot on PCs with a minimum of 4 GB of RAM.

 

Introductory info and required programs: http://reboot.pro/in...957#entry209470

 

Making the VHD:  http://reboot.pro/in...957#entry209472

 

Optionally apply unnatend.xml, services modifications and control Telemetry during install: http://reboot.pro/in...957#entry209480

 

Install your programs, SVBus driver and Capture Wimboot Image:  http://reboot.pro/in...957#entry209483

 

Apply Wimboot Image to a 1.5 VHD: http://reboot.pro/in...957#entry209485

 

Installing your Wimboot VHD on a USB device and Ramboot:  http://reboot.pro/in...957#entry209488

 

You may consider this as an Hybrid Ramboot:  http://reboot.pro/in...957#entry209518

 

Selecting to use wimlib on WinNTSetup:  http://reboot.pro/in...957#entry209568

 

What I put on my VHD:  http://reboot.pro/in...957#entry209602

 

Improve Portability: http://reboot.pro/in...showtopic=21957#entry209809

 

EDIT: I finally found some info about the WimBootCompress.ini file located on WinNTSetup\Tools\, see: https://wimlib.net/f...wtopic.php?t=16

 

cdob comments: http://reboot.pro/in...957#entry209834

 

Making copies of coupled files (VHD + wimboot wim file) for backup pourposes:  http://reboot.pro/in...957#entry209917

 

cdob suggestion for redirect on the VHD the path to source wim file:  http://reboot.pro/in...957#entry209947

 

WimBootCompress.ini very last version from 2020-05-18 (MBR only) and 2021-02-23 (MBR/UEFI): http://reboot.pro/in...957#entry214854

 

karyonix suggestion for redirect on the VHD the path to source wim file: http://reboot.pro/in...957#entry209952

 

More cdob comments:  http://reboot.pro/in...957#entry209976

 

Redirect the VHD path to wimboot wim file is finally a success:  http://reboot.pro/in...957#entry209979

 

NOTE: When relocating the files, edit the BCD(s) may be required, better check to be sure all will work fine.

 

EDIT: If for any reason you want to reduce the source wim file see:   http://reboot.pro/in...showtopic=21972

 

New version of WinNTSetup with new features, for more info see: http://reboot.pro/in...showtopic=22119

 

Capture and apply Windows Full Flash Update (FFU) images: http://reboot.pro/in...showtopic=22182

 

DismMountService (DMS) a GUI for Dism by Retokener: http://reboot.pro/in...showtopic=21534

 

Procedure to make Wimboot VHDs using DMS: http://reboot.pro/in...showtopic=22182

 

Useful info for WinPEs, Wimboot and Compact installs: http://reboot.pro/in...showtopic=22333

 

Hope this can be of any help for some of our members.

 

Best Regards

 

alacran

Go to the full post


  • Please log in to reply
245 replies to this topic

#51 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 06 March 2019 - 08:55 PM

that is exactly the one I got it and where I got it from. I do not know how I can use it, nor do I know why u guys won't anymore.



#52 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 March 2019 - 08:54 AM

that is exactly the one I got it and where I got it from. I do not know how I can use it, nor do I know why u guys won't anymore.

On a modern system (where we are talking of GB and GB on "fast" serving media) it has not any "real world" advantage.

 

It does have when you use some other techniques where the file is served through a slow channel, a good example is PXE booting. 

 

Usage is simple, you replace boot.sdi with it, taking up less space on source/booting media.

 

:duff:

Wonko



#53 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 07 March 2019 - 03:09 PM


In this way you have some learning on a couple of machines, but then the WIM has improved and can be used on all machines .... 

 

That principle of learning, where the SYSTEM registry is improving, is already working since the days of Windows eXPerience  ;)

 

This works very fine as long as all machines are only Intel or only AMD, but we need to be carefull because if there is a mix we will find big problems and the OS do not boot and only reboot again.



#54 wimb

wimb

    Platinum Member

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

Posted 07 March 2019 - 03:14 PM

This works very fine as long as all machines are only Intel or only AMD, but we need to be carefull because if there is a mix we will find big problems and the OS do not boot and only reboot again.

 

I have not yet tried to switch from Intel to AMD,  but I thought this might be fixed in Windows 10

 

If there is a problem then we might fix this in the registry by setting the Start value of the intelppm Service



#55 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 07 March 2019 - 03:23 PM

@ wimb or you have lets say 3 vhd files created with wimboot file they are just only 1 or 2 gb in size and make seperate boot entries for them.

for example 1 called "home" second "school" and another called "office"

 

First time let it boot as filedisk, capture all drivers then make it reboot into ram and you are ready to go.

 

You do not need the 10 gb vhd this way.

 

The drivers will take some space with this setup.

 

Also it is faster to use and more portable only downside is the size of 3 vhd files.

 

But with todays hardware that isn't a real problem anymore.

 

Please take this in a good way, do not bother to answer me, but think only for a moment this:

 

How did you load the drivers the first time on each one of your 3 VHDs?

 

Did you follow all the procedure to create a VHD since the begining on each machine/location?

 

Are you really improving wimb's idea?

 

Isn't this a nonsense idea?

 

Do you understand now why some of your comments desperate me sometimes?

 

Best Regards

 

alacran



#56 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 07 March 2019 - 03:37 PM

I have not yet tried to switch from Intel to AMD,  but I thought this might be fixed in Windows 10

 

If there is a problem then we might fix this in the registry by setting the Start value of the intelppm Service

 

Please could you explain me in detail what will be required to change on registry for Win7 and Win8.x, since it is a good info if you have to buy a new MB and CPU and you don't want to reformat your HD, It will be easier to just boot from WimPE, load a registry hive and make the required change from Intel to AMD or viceversa.  Just yesterday I was forced to format and re-install everything on a Win7 x86 Desktop PC.

 

I'll read your answer latter, now I have to go, See you latter.

 

alacran



#57 wimb

wimb

    Platinum Member

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

Posted 07 March 2019 - 04:08 PM

In Windows 7 and XP we had this problem in switching from Intel to AMD and to Intel

 

It was solved by offline mounting in regedit on HKEY_LOCAL_MACHINE the \Windows\System32\config\SYSTEM registry as systemdst

and changing to Start = 3 as value for the  intelppm Service.

 

I think in Windows 8 and 10 this is not necessary anymore and I see that my intelppm Service has indeed Start = 3

 

Open regedit > On HKEY_LOCAL_MACHINE > Menu File Component Load and select your offline SYSTEM registry and mount as systemdst

[HKEY_LOCAL_MACHINE\systemdst\ControlSet001\Services\intelppm]
"Start"=dword:00000003



#58 blackbalfur

blackbalfur

    Member

  • Members
  • 82 posts
  •  
    Netherlands

Posted 07 March 2019 - 04:49 PM

deleted.

 

not worth it.


Edited by blackbalfur, 07 March 2019 - 04:50 PM.


#59 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 07 March 2019 - 09:59 PM

@ wimb

 

Thinking a few more about this, starting on 8 or 8.1 MS started talking about the Widows to GO or something like that on VL OSs (I don't remember the name they used), so it is very possible they fixed this since then as you said.

 

But on the other hand just checked on my running 7x64 SP-1, (No more updated since Dec. 2017 to avoid Meltdown and Spectre mitigation updates) OS is on Intel platform since installed and the value is 3 see:

 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\intelppm]
"Start"=dword:00000003



#60 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 08 March 2019 - 12:42 PM

BTW,
I'm comparing boot times with various compression levels of both wim and vhd. So far, I have come to the realization that there is no hard and fast criterion whereby the smallest is the slowest. I will come up with more significant results, which will come out when I have found the happy medium.

#61 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 09 March 2019 - 07:44 AM

LIB (an phonetic acronym for texan Well I'll Be, or that's the way they say it, if u prefer),

the best of both worlds, the trade off, is what we had already expected, lzx-compressed wim + wimbooted vhd, both in terms of space and in terms of time. many other alternatives do work, but they are not so small and fast as the above-mentioned, as this is the only alternative that actually entails hard links (alacran's 0 files), while the others mostly occupy physical space inside the vhd. now one other challenge would be to find out to what extent, and at what rate, the data bulge inside the vhd occurs, because from time to time it does, and it is a bit of a nuisance to resize the vhd to accomodate it. it would be interesting to know which files or folders are the hardest hit in these respects, so as to send them elsewhere and junction them back in (believe me, it works, if we have to) and keep the size of the inside of the vhd as stable as possible. successive shrinks work only momentarily, but will cause even more bulges down the road, thus creating more problems than they solve. of course, what I am saying does not allude to temps and software backups, whose storage places might be customized via the software or just deleted when they are no longer needed. The best would be to keep a stable core anyway, though.

nino



#62 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 09 March 2019 - 09:03 AM

If you RamBoot from the VHD, VHD size remains immutable.

 

It is better to kept all other info as documents outside of the VHD on some folder/directory on the root of a drive this way it will not be erased every boot.

 

I know from time to time DiskBoot is necessary to install new software or make some changes to OS, but this should be an exception not the usual.

 

During boot all MS OSs need to write to the mass storage device (on RAMBoot it is on Ram), if this is not possible then we get a BSOD.

 

This means the OSs are writing to HD all time, even with updates, pagefile file, swap file and Windows Search disabled, it writes: Temp files, hundreds of log files, last accessed time on each file, icon caches, history of opened files, event log, prefetch, superfetch, thumbnail cache, internet cache, downloaded files, + all the forced TELEMETRY, etc.

 

Just to have an idea run CCleaner and take a careful look at all trash it removes, but in no way it removes all trash (TELEMETRY is not touched).

 

NOTE: following is what I have done to minimize FireFox and Avast writes on SSD, maybe it can give other users some ideas, it can be adaptated to other browser or AV):

 

I have made big effords trying to reduce all this writes on the SSD of my main (standard installed) OS (on one of my PCs) and have found the browser and the AV are the two programs writing more to the HD,  I know in this approach we are not using AV but I comment this because we all need to know this. To control the browser FireFox there is a way to do it on this post: http://reboot.pro/to...hd/#entry209602

To contol Avast AV writes on SSD, more than 300 MB (on hundreds of small files) every hour during all time we are using the PC, since it can not be installed on a drive different than C:\, before install Avast create a Junction Link from my SSD C:\Program Files\AVAST Software\Avast\defs to a location on my HDD as: X:\Avast\defs

 

But going back to our growing VHD, I'm convinced only final/radical solution is RamBoot, as said in the first line of this post.

 

alacran



#63 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 09 March 2019 - 01:37 PM

Thank u alacran for ur support. Can U confirm that all the stuff u have mentioned as being responsible for most of the "vhd bulges" would have ended up in appdata\roaming or would have more generally program files, program files (x86) and programdata? how about the winxs dir in windows?



#64 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 09 March 2019 - 06:19 PM

Yes, AppData\Roaming is a place where majority of OS, browsers and some programs trash is collected, but not the only place, but a big part of all info on this files folders should not be errased since it is necessary, the dificult part is find what to kept and what to delete (use CCleaner as a guide to know what can be safely deleted).

 

You also have Environment Variables (TEMP and TMP locations), all info on this locations is safe to delete every shut off, for them I created a RamDisk on my everyday OS and Inside it there is Firefox profile and also a Temp folder for TEMP >>> A:\Temp and TMP >>> A:\Temp This is on Win7, adaptate it to your Win10 if required (haven't check if MS guys made some change on Environment Variables).

 

You can be sure as I am, there are other locations where garbage accumulate,s but we haven't find them yet.  And with every new OS version there is always changes and more bloat.

 

C:\Windows\winsxs\ has all new and old versions of drivers and *.dll(s), this directory do not change every day unless you install new programs that require new drivers or *.dll(s), so do not worry so much for it, as it will be kept mainly on source .wim

 

Finally if you want to find exactly what folders have grow up, from another OS or a WinPE opend your just made VHD with 7 zip and as I told you before all 0 size files/folders are only hard links and are not phisically on the VHD, make some pictures of all those directories you think are suspicious and repit this after some time of use and by comparing the pictures you will have a guide where is the VHD growing up.



#65 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 09 March 2019 - 07:43 PM

Temps, already dealt with (ramdisk);appdata, for sure, wonder whether to junction them out my old style. And the rest, i'll do as u say. I never considered deleting anythi
ng
BTW, any use in preloading the wim file or am I just thinking out loud?

#66 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 09 March 2019 - 08:39 PM

BTW, any use in preloading the wim file or am I just thinking out loud?

 

There is no need to load (so also not preload) the wim source file, only thing loaded is the VHD.



#67 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 09 March 2019 - 10:42 PM

ok, as I suspected, just wanting to make sure.

as for your tendency to ramdisk the "superfluous" and mine to junction it, do u not think I am less subject to deleting it than you are? at least, if juctioned, they stay "away" from the vhd, but at least they do not go deleted, as they would from a ramdisk. is it not so? am I missing out on anything?



#68 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 09 March 2019 - 11:44 PM

oh, and another thing, before I forget: what is the substantial difference between booting vhd as filedisk with g4d and with conventional bootmgr? is either any better? and if so, in what terms?



#69 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 10 March 2019 - 04:15 AM

"If you RamBoot from the VHD, VHD size remains immutable."?

well, not here, it does grow instead. u probably mean that it is uninfluential in the end, as u restart or reboot, in the sense that everything will restart from the original size before rambooting in the first place; but while in ram, it does grow, at least from the drive status bar; i honestly have not checked out the directories in 7zip, though. have you?

nino



#70 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 10 March 2019 - 01:23 PM

"If you RamBoot from the VHD, VHD size remains immutable."?

well, not here, it does grow instead. u probably mean that it is uninfluential in the end, as u restart or reboot, in the sense that everything will restart from the original size before rambooting in the first place; but while in ram, it does grow, at least from the drive status bar; i honestly have not checked out the directories in 7zip, though. have you?

nino

 

Of course I mean the phisicall real size of the VHD, all changes during Ramboot will be lost and they only happend on RAM, and before you ask there will be allways some changes in size each time the VHD is loaded in RAM (it is all garbage mentioned on previous posts) depending wich programs you run each time, and you will have to live with this because if the OS can't write to the Mass Storage (Ram on this case) it do not boot, but as all this goes to RAM (and desapear every reboot), I don't see the point in worriying about this.

 

So if your RamBoot a VHD there will be a point when you have to reboot to re-start in a clean and pristine state again, this is the basicall reason to use RamBoot.

 

If you pretend to kept the system running forever without reboot, you better do not RamBoot and/or create a VHD, and just make a wimboot mode install directly on the root of a partition of your HD, then you are able to collect all garbage as usually OS does, and you don't have to worry until all that drive/partition is full of it, or use CCleaner periodically.

 

alacran



#71 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 10 March 2019 - 02:05 PM

Now I have a brand new Adata XPG enclosure with USB 3.0 connector, where I put a new Adata SU650 (120 GB) I had available at home, since this device is faster it helped me to run some more tests.

 

After running some tests, I can now confirm VHD's of 1.5 GB size can be RamBooted on PCs with a minimum of 4 GB Ram, and still have enought Ram available/free for run the OS and programs, after booting there was 1.3 to 1.5 GB of free Ram, this may vary depending also on how much Ram your Bios reserves for hardware.

 

Tried with VHDs of 2 GB size, and grub4dos said they can't be loaded on that systems.

 

alacran



#72 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 10 March 2019 - 10:30 PM

On post No.15 I said:

 

 

Some times on WinNTSetup Windows API do not let us install an OS on a very limited space (VHD on this case), as an example I wasn't able to wimboot install my  Full Win8.1x64 (dic 2014) on a 1 GB VHD, even if I previously used a tool to remove all (CR)Apps from the Iso before the first install (about 400 MB from the Iso).

 

But afortunatelly we can select to use Wimlib-Imagex (libwim-15.dll x64 or x86 respectively) if we previously put a copy ot it on WinNTSetup3.9.3.1 on its folder Tools\x64\wimlib or equivalent x86 folder as required,  and select to use it as on attached picture.

 

After some test, I have found that 1 Gb is a good size for VHD, if we don't install additional drivers and let the system use those it has into it.

 

Well, I have been trying to find the cause of this and after opening 8.1 and 10 wimboot VHDs with 7 zip I have found on 8.1 all drivers on Windows\System32\drivers\ are phisically on the VHD, not as pointers to source wim, as they are on 10, it is funny because WimBootCompress.ini of both are the same with the only diference of the multimentioned useless [PinningFolderList] section do not appear on 8.1 WimBootCompress.ini.

Then I went to look on WiNTSetup Tools folder and there we can find another version of WimBootCompress.ini having a bigger [PrepopulateList] section, where one of the lines is:  \Windows\System32\drivers\*.sys It seems pretty clear to me there is some hard code on WinNTSetup to use this version of WimBootCompress.ini on 8.1 and also on previous OSs in order to let those OSs made before 8.1 Update 1 as 8.1, 8 and 7 have wimboot capavilities that do not have natively.

 

That's the reason why all those drivers are phisically on my  8.1 VHD and not on my 10 VHD, and been so much files they cause an impact on deploying the OS on limited size as 1 or 1.5 GB (it seems as a bottle neck since they don't have room to expand, and VHD gets full to the top) and it allways blocks at about 36 % deploying when using Windows API, but if we select on WinNTSetup to use libwim-15.dll, then all runs fine. 

AFAIK Windows tools for wim files (as Windows API, imageX and Dism) use the final destination also as temporary location to expand the files/folders and wimlib-imagex uses OS memory as temporary location to expand the files/folders, not having problems to handle this situation then.

 

Well, we have found another strong point to use wimlib-imagex when possible better than Windows tools for wim files, anyway we have to remember the only tool capable to off line install drivers is Dism.

 

This also explains my final coment on the same post (talking about 8.1 VHD):

 

 

After some test, I have found that 1 Gb is a good size for VHD, if we don't install additional drivers and let the system use those it has into it.

 

This applies on 8.1 and previous OSs as drivers are located on VHD not as pointers to source wim file

 

But do not apply to 10 OSs since all drivers (with only very few exceptions) on VHD are only pointers to source wim, not occupying any space on the VHD.

 

And now (as mentioned on previous post) has also been probed that VHDs of 1.5 GB size can run on 4 GB RAM PCs

 

alacran



#73 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 11 March 2019 - 02:51 AM

Dear Alacran, the post-moving of critical folders was one hell of an experience, to say the least. yet, i have come out with some interesting findings, i guess. The almost automatic procedures that I have been used to carrying out for the past few years had to be revised a little bit, owing to what i think are some hard-coded links that prevented me from moving certain subdirs so easily, which has also entailed some instances of misconfiguration and various glitches here and there. The strange thing, well not so strange if u connect it to the above, was that the more u moved out the more the content of the vhd "inflated", so to speak - my poor understanding tells me, in very rough terms, that the wim would plead for keeping the management of these folders, feels it can no longer be in charge of them properly and tries to make up for their departure from the vhd (sorry for not being able to be more technical than this, but u get my meaning anyway, i am sure).  the only way to record that I have been able to safely make wim, vhd and moved folders coexist somewhat happily was in the case of my wife's laptop, where, as I had told u earlier on, I forgot to unjunction the outer folders back inside the vhd and captured the install state as it was before.  the resulting wim has been one of 1.8gb (quite comforting, compared to my 6.5gb now), but the outer folder sizes are insane (windows 23.5gb, programdata 6.94gb, program files (x86) 2.05gb, program files 2.62gb, users ca. 12gb (appdata 1.33gb) and the vhd is over 5gb). if u sum up there would be no point in having a small wim with all this bulk out, and her vhd is over 2ce mine just because i want to leave some space inside for later bulges. so, unless sensibly specified otherwise, I am bound by ur innovation and will not return to my junctioned-folder technique - much less tedious to extend the vhd from time to time, if need be.


  • alacran likes this

#74 quarky42

quarky42

    Member

  • Members
  • 38 posts
  •  
    United States

Posted 11 March 2019 - 04:56 PM

Alacran, I wanted to run this by you and see if I could get your input / critique or thoughts, please.  I have a bit different of an environment and a little bit different of a goal than you, but I think it is very close, but please understand that my request for input on my variations come from limitations I have in my environment. 

 

Because of the systems I am working with, it would really help me a lot deal with limitations in my own environment if I can do my initial setup in Windows 10 Pro x64 Hyper V.   Basically, In Hyper V Manager, I can create a VHD file of any size and load Windows 10 Pro to it.   I cannot or do not want to make any changes to the computer I am using to develop this image on, but the VHD file that I'm creating is 100% fair game.  I can make any changes to that Hyper V bootable environment I want.

 

For example; Currently, I have a Windows 10 x64 Pro Image that has the SVBus Ram Disk driver installed and a number of drivers / programs and settings / customizations applied to this VHD image file.  I am able to boot this VHD image to ram with grub4dos which is very excellent and desired.  I can also direct boot the VHD file to make changes.  Usually it is just as easy or easier for me to boot the VHD file in HyperV and make any changes to it that I want that way.    I have also been able to use HyperV to test my bootable external media without having to reboot my system.   There are a lot of reasons and details for why I am doing it this way . Some of it are requirements I just have to deal with.

 

So far the RAMDisk booting of the VHD file has been working great, with the only downside being the size of the VHD file means it takes about 3 minutes for me to boot.  From what I am reading about the WIMBoot mode, it seems like I should be able to take my fully configured Windows 10 customized VHD and run that through the process to obtain a Wimboot WIM file and a VHD source file which would let me boot the same OS but in a fraction of the time.   Am I misunderstanding here?   I do not have my development system with me today, so I am not able to try it right now.   Since I wasn't able to just give it a try,  I thought I would reach out to you and see if you had any thoughts on whether or not I should be able to take a VHD of a full Windows 10 install and turn it into a WIMBootable setup like you describe in your original posts?   (One of the reasons I have at least some doubts is because your original posts were written from the perspective of installing Windows 10 from scratch and then adding the customizations.  I'm skipping some of that by already having a fully ready VHD file, so I'd like to make sure I get started "on the right foot" so to speak if you are willing to share your thoughts on this proposed variation.   I am perfectly willing to start over from scratch if I need to, but I have a feeling that I might not need to.  If I do need to start all over, I would like to understand why I can't just use the VHD file I already have containing a full Windows 10 install.  Thank you for any thoughts you are willing to share given this potential variation.



#75 quarky42

quarky42

    Member

  • Members
  • 38 posts
  •  
    United States

Posted 11 March 2019 - 05:12 PM

On a side note, in reply to comments in the thread about external media, boot times, and having the media be as fast as possible while still being small / portable.  I just wanted to share that Addonics has a NVME compatible enclosures for M.2 drives.  It is USB 3.1 M.2 enclosure model M2NVMU31 that is the size of a memory stick.  Since it will take a M.2 drive, you can get them anywhere from 250GB up to 2TB pretty easily.    If your system has USB 3.0 instead of the USB-C / 3.1 port, then they do make USB 3.1 to USB 3.0 adapters.   OR,  Sabrent has USB 3.1 model that also comes with the USB 3.0 adapter as well:  Model EC-NVME.     For those that want USB memory keys I have found Patriot and Kanguru to both be pretty fast.   Kanguru even has some that are write protectable with a switch so you can have a physical write protect that would prevent changes being made to the media.  (That last one might only be for extreme cases, but one possibly usage would be on a system that you think might have an infected BIOS, or for those that just want an extra layer write protection for other reasons.)





Also tagged with one or more of these keywords: wimboot, ramboot

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users