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

@ quarky42

As long as you CAPTURE as wimboot, it can be even your full everyday system with all installed on it, the idea to start with a just fresh installed 10 OS on a VHD was mainly to reduce size of source wimboot wim file and avoid extra potential causes for problems. When you apply/deploy your wimboot image if you want to latter Ramboot from it is a requirement to do it on a FIXED SIZE VHD, NOT on a VHDX, to let grub4dos by means of SVBus driver Ramboot the OS located into the VHD.

Again for capture the OS in wimboot mode I recommend wimlib-clc because it uses wimlib-imagex wich is faster and give an smaller wim size than any other tool.

Also it is a good idea to download and read  VHD_WIMBOOT.pdf  from wimb.

It was good you also suggested more option for devices we can use in this project.

Good luck and happy Ramboot

alacran

Thank you for the thoughtful response, Alacran.  I was hoping that I was hoping that I was understanding correctly, and it seems I am on the right track then.  I understand your desire for the minimal sized WIM boot file.  I don't mind a little larger boot file as it should still be much smaller than my current VHD.  The method you shared is the "Best of Both Worlds" solution for me when it comes to being able to apply updates/add software and then run ccleaner / disk cleaner, and pull back wasted space.   I'm also familiar with ramdisk drives for browser cache and temp files.   I'm tempted to create an empty (or load an empty) ramdisk at boot time in grub4dos so that Windows can point to it as a temp folder.  That way the ramdisk temp/cache path is ready even before Windows starts to boot.

I will definitely be following your adivce for wimlib-imagex and -clc for the capture and thanks for the PDF.  Downloading it and reviewing it now.   I'm glad I could contribute a small piece of info back on useful hardware.  For some, keeping up front cost to a minimum is paramount.  For others, an investment up front will pay them back majorly in a terms of performance.  Thanks again again for taking the time to reply and have a good one.

Edit:  The other reason I'm interested in having the ramdisk be created or at least loaded at boottime is so that Windows can stuff it's pagefile there.  I have more than enough ram for the system, but some programs / windows interface (no matter what you do) want that pagefile, so it's no big deal for me to allocate 5 or 8GB of RAM for a combination of cache, temp, and pagefile purposes.  Being able to hopefully create the partition on the fly would be great, but I haven't even begun to look into that.  I know that I could just load another VHD image, if I need to, but not the best solution.

Edited by quarky42, 12 March 2019 - 04:58 PM.

As I'm working through the document VHD_WIMBOOT.pdf, this section was a little confusing and I would like to suggest a wording change could make the steps more clear:

Instead of:

"From Mounted W10x64_F.vhd and Windows\system32 make custom WimBootCompress_BCD.ini file in wimlib-clc folder
Add \Boot\BCD and \bootmgr to the [PrepopulateList] so that these files are copied as file instead of as pointers
Remove or disable with ; the [PinningFolderList] since it will give wimlib WARNING Unrecognized Section, which is safe to ignore"

I suggest / request something like this:

"From Mounted W10x64_F.vhd, browse to it's Windows\system32 and copy the WIMBootCompress.ini file to your wimlib-clc folder. Rename it to WimBootCompress_BCD.ini
Add entries to this new ini file for \Boot\BCD and \bootmgr to the [PrepopulateList] so that these files are copied as file instead of as pointers
Remove or disable with ; the [PinningFolderList] since it will give wimlib WARNING Unrecognized Section, which is safe to ignore"

In the original version I had to read it several times to figure out what I was being told to do.  Maybe it was just my misunderstanding, but I think something along the lines of what I am suggesting might be more clear.  I do understand that there is a minimum level of competence and understanding that a person must have before trying something like this, but I think my issue here was solely just trying to understand what was really meant by the original statement.   Thank you for your consideration.

I suggest / request something like this:

"From Mounted W10x64_F.vhd, browse to it's Windows\system32 and copy the WIMBootCompress.ini file to your wimlib-clc folder. Rename it to WimBootCompress_BCD.ini
Add entries to this new ini file for \Boot\BCD and \bootmgr to the [PrepopulateList] so that these files are copied as file instead of as pointers
Remove or disable with ; the [PinningFolderList] since it will give wimlib WARNING Unrecognized Section, which is safe to ignore"

 

Thanks for your feedback. 

I know that this section is unclear and needs improvement and will make use of the text above that you propose.

@ quarky42

The method you shared is the "Best of Both Worlds" solution for me when it comes to being able to apply updates/add software and then run ccleaner / disk cleaner, and pull back wasted space.   I'm also familiar with ramdisk drives for browser cache and temp files.   I'm tempted to create an empty (or load an empty) ramdisk at boot time in grub4dos so that Windows can point to it as a temp folder.  That way the ramdisk temp/cache path is ready even before Windows starts to boot.

About updates, each time you apply an update, all that changes made by the update will be outside the wim file, I mean they will be phisically on the VHD with the obvious high increase in consumed space.  This was the main reason that forced MS to stop promoting wimboot and almost deprecate it and introduce Compact mode (Something like the old Compressed OS on 7 and previous OSs), they had big troubles with the new stupid monolitic updates on Tablets with wimboot mode.

On the contrary I suggest this Ramboot wimboot approach as a way to avoid changes on the OS, and always boot from a clean and pristine OS.  On wimboot CCleaner sometimes do not recover space, and it spends more space, CCleaner is good for cleaning the first VHD that latter will be captured on wimboot mode. When you Ramboot an OS you do not need CCleaner since every shut off all changes are deleted/lost.

About create a Ramdisk with grub4dos I think it is better to do it during system boot with Softperfect Ramdisk Free as I do it (or maybe Imdsk ToolKit), you do not notice any wasted time doing it, and you can put there Temporary files and PageFile (if you have a good size RAM, PageFile may be very small, just simbolic for those stupid programs claming for it).

@ quarky42

 

 

About updates, each time you apply an update, all that changes made by the update will be outside the wim file, I mean they will be phisically on the VHD with the obvious high increase in consumed space.  This was the main reason that forced MS to stop promoting wimboot and almost deprecate it and introduce Compact mode (Something like the old Compressed OS on 7 and previous OSs), they had big troubles with the new stupid monolitic updates on Tablets with wimboot mode.

 

On the contrary I suggest this Ramboot wimboot approach as a way to avoid changes on the OS, and always boot from a clean and pristine OS.  On wimboot CCleaner sometimes do not recover space, and it spends more space, CCleaner is good for cleaning the first VHD that latter will be captured on wimboot mode. When you Ramboot an OS you do not need CCleaner since every shut off all changes are deleted/lost.

 

About create a Ramdisk with grub4dos I think it is better to do it during system boot with Softperfect Ramdisk Free as I do it (or maybe Imdsk ToolKit), you do not notice any wasted time doing it, and you can put there Temporary files and PageFile (if you have a good size RAM, PageFile may be very small, just simbolic for those stupid programs claming for it).

I understand where you are coming from on this.  For my use of this image, it is absolutely necessary that I have a means to update the underlying OS even if I have to repeat the capture process.   The ramboot is a "feature" that I would use day to day, but at other times I would need to perform maintenance on the source materials including updating applications, updating the OS itself, or making changes to settings that I would then feed back into creating a new ramboot version with all of those things incorporated.    So the ramboot is a very much desired feature but at other times it will be necessary to incorporate changes as well.  Having the VHD file grow somewhat over time is not a problem and neither is having to just recapture the whole thing and repeat the wimboot install with the WinNTSetup x64 application, either.

Questions:  

Are the steps in the correct order between the end of Page 2 (UEFI_MULTI) and then followed by WinNTSetup x64 on Page 3?  

On Page 3 #3 it says Y: mounted drive, but the screenshot doesn't show Y:...it shows X:.   Which is correct?  

It seems to me that the steps from Page 3 WinNTSetup should be ran first and then the UEFI MULTI?

On Page 3 screenshot it has L: and the location of the Boot drive.  Can you clarify what L: is?   I am running through these steps but getting a little confused with all the drive letters.  Some are clearly labeled, one drive letter might be a typo I asked about a moment ago, and a drive letter or two aren't labeled.   I'd like to be able to look at each drive letter in the document and see somewhere that it is spelled out what that drive letter is / where it came from or where it was created.   (I hope I'm making sense here.)   I ca see you've put a lot of work into this document and I hope that am not bothering you here, but just trying to help clarify things that might be confusing to others as well?    If I screwed up somewhere and didn't read something that I should have caught, I apologize.

 

Questions:  

Are the steps in the correct order between the end of Page 2 (UEFI_MULTI) and then followed by WinNTSetup x64 on Page 3?  

 

On Page 3 #3 it says Y: mounted drive, but the screenshot doesn't show Y:...it shows X:.   Which is correct?  

 

It seems to me that the steps from Page 3 WinNTSetup should be ran first and then the UEFI MULTI?

 

On Page 3 screenshot it has L: and the location of the Boot drive.  Can you clarify what L: is?   I am running through these steps but getting a little confused with all the drive letters.  Some are clearly labeled, one drive letter might be a typo I asked about a moment ago, and a drive letter or two aren't labeled.   I'd like to be able to look at each drive letter in the document and see somewhere that it is spelled out what that drive letter is / where it came from or where it was created.   (I hope I'm making sense here.)   I ca see you've put a lot of work into this document and I hope that am not bothering you here, but just trying to help clarify things that might be confusing to others as well?    If I screwed up somewhere and didn't read something that I should have caught, I apologize.

In VHD_WIMBOOT.pdf on page 2 you just Download UEFI_MULTI and a short description is given of this tool.

Of course you need to download it first if you want to use it on page 3

On page 3 we are working on Portable SSD, which is an USB device having FAT32 Boot Drive L:  and NTFS System Drive M:

These drive letters can vary and are given by Windows on connecting Portable SSD to USB.

You use WinNTSetup to create VHD on USB NTFS System drive and that VHD is then auto mounted by WinNTSetup as drive X:

So you are right that in the text it must be X: and not Y:

The pictures are correct so that you can see that the WIM file is located on USB System Drive M: and also the VHD is located on drive M:

The drive letters L: and M: are clearly labeled as USB Target FAT32 Boot Drive L: and USB Target NTFS System Drive M:

@ quarky42

I only wanted to warn you about updates, it is better to download and run them booting as Filedisk on a drive or VHD with plenty room (NOT on Rambooted OS), to avoid more problems than they already give to users.

From previous wimb post:

 

You use WinNTSetup to create VHD on USB NTFS System drive and that VHD is then auto mounted by WinNTSetup as drive X:

So you are right that in the text it must be X: and not Y:

If you make a VHD on WinNTSetup it allways use Y: for a mounted VHD unless this letter is in use (with some other device or virtual device) then it goes to X: or previous letter if required.

So I think that is the case on that picture.

Since the first time I put a link to VHD WIMBOOT.pdt for your convenience, I mentioned it was made by wimb, so please any thing (suggestion, request) related to this document, please address it to him, I can't make any change to a document I haven't made.

As you may have noticed he is a very friendly guy, always ready to help others and also to hear suggestions.

alacran

@ quarky42

 

I only wanted to warn you about updates, it is better to download and run them booting as Filedisk on a drive or VHD with plenty room (NOT on Rambooted OS), to avoid more problems than they already give to users.

From previous wimb post:

 

 

If you make a VHD on WinNTSetup it allways use Y: for a mounted VHD unless this letter is in use (with some other device or virtual device) then it goes to X: or previous letter if required.

 

So I think that is the case on that picture.

 

Since the first time I put a link to VHD WIMBOOT.pdt for your convenience, I mentioned it was made by wimb, so please any thing (suggestion, request) related to this document, please address it to him, I can't make any change to a document I haven't made.

 

As you may have noticed he is a very friendly guy, always ready to help others and also to hear suggestions.

 

alacran

Regarding the updates, I understand how the ramboot works in those regards.  I wouldn't try to update it and I understand the free space requirements for installing updates differs from the minimum space required to run the OS.  I appreciate you taking the time to make sure though.    My main point was to try and explain that my goals are very parallel to yours, but the ends I'm trying to reach are a little different in their trade-offs, but the process is still the same, just the end balance being a little different.

Thank you both alacran and Wimb for the explanations about the paths.  I apologize for missing the detail about the author of the PDF.  Thank you, Wimb for your help in clarifying the document and being agreeable to revisions.   It is not an excuse, but I think switching between reading this forum on my phone, replying on my phone, and sometimes being on a computer adds to the confusion.   Sometimes I am away from my computer but still like to read and reply though it is harder to go back and forth and double check things. 

I wasn't successful in my attempts yesterday.  I had some sort of problem with booting in the vhd file.  The BCD wasn't happy, but I need to do the steps over again and make sure I didn't miss something along the way.    One difference is that I am taking a regular existing Windows 10 install which is already in side a VHD file that I can mount and creating the initial WIM Boot image from that.   It is a fresh install of Windows but it wasn't initially installed the same way as the instructions start out.  I do have the VHD booting up from Grub4DOS as a ramdisk with no problems there using the SVBus driver, so all of that is loaded and working.  I'm pretty sure my problem has to do with the BCD or possibly I messed up an input in one of the applications when creating the UEFI_MULTI.    If I get stuck after trying again, I'll try creating a brand new image from scratch like how the instructions start and give that a try to help rule out any variations I might have introduced by starting with an existing RamBootable VHD Windows 10 x64 Pro Image.

Well, wimb's new version of UEFI_MULTI lets us Ramboot from external USB devices, and now an issue with Rambooting from internal HDs is fixed.
 

Since this subject seems solved now, I think it is time to try to improve portability, I have been looking at the WinNTSetup\Tools\WimBootCompress.ini (I have found this applies only to 7, 8.0 and 8.1 not for 10) and I remember JFX added wimboot capavilities to 7, 8 and first version of 8.1 (wimboot started on 8.1 update 1), meaning on that file are minimum requirements to have a sucessfull Ramboot of course with the help of the old version of Wofadk.sys also into WiNTSetup (after downloaded) located on WinNTSetup3.9.3.1\Tools\x64\DISM\wofadk.sys

Wof.sys on 10 is of course a newer version, but anyway this give me the idea to incorporate to WimBootCompress_BCD.ini at least to start this line \Windows\System32\drivers\*.sys in order to try to improve portavility (avoid troubles on limited space VHD during decompressing and loading drivers), this should not be a problem on VHD size as it is only a few less than 90 MB on this folder.

If this do not solve the problem next step is add (to the WimBootCompress_BCD.ini file, to be uncompressed on the VHD) only some selected basicall/comon drivers from \Windows\System32\DriverStore\FileRepository but trying to keep this to the minimum, since this file is pretty big, also I think it may be a good idea to take a look and see what drivers uses Win10XPE.

The goals are:

1 - Try to not go through the learning process before making a small size VHD.

2 - Keep the VHD not bigger than 1.5 GB which is an approximate limit to load it in RAM on PCs with 4 GB of Ram.

Any ideas or help is wellcome.

alacran

I think I found a hiden and AFAIK undocumented feature on WinNTSetup, since I never read about it on the program page, let me tell you I'm a big fan of that program, and an assiduous reader of that page, (even I was the first one to ask JFX to let me translate it, so more people could use it).

Well, if we select wimlib-imagex (libwim-15.dll) instead of Windows API during install, then automatically all files/folders on [PrepopulateList] section of the WimBootCompress.ini file located on WinNTSetup\Tools\ are applied (UNCOMPRESSED) during install (in addition to any other WimBootCompress.ini we used during Capture) and also copied that section to the new internal Windows\System32\WimBootCompress.ini so any new wim image made/captured latter from that install will keep this modded WimBootCompress.ini  (including wimb's suggested changes). Then just formated VHDs and made a new set of VHDs with this approach.

I have very good news, so far I have tested 10x64, 10x86 and 8.1x64 (each one on 1.5 GB VHD) on 4 different Intel Chipset PCs and after a brief load of new drivers all Rambooted very fine, I didn't want to boot by FileDisk on any of the tested OSs in order to do not make permanent changes to them and increase the used space. Remaining free space on VHDs after Ramboot is about 1 GB.

Portability seems to be feasible without the learning process, of course we need more test on more PCs to confirm this in a total way.

@ wimb

I noticed UEFI_MULTI do not apply Test Mode (testsignning) on 10x86 installs, well, if Rambooting (by grub4dos menu), this is not a problem it boots very fine, but if you run it from Windows boot manager it fails, and it was required to apply Test Mode to run fine, then as this do not hurt I also applied Test Mode to internal BCD used for Ramboot, just to be consistent.

I remember on 7 and 8 x86 Signed drivers was not a so hard requirement, but unsure for 10 x86 (so many releases and changes I got lost).

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

alacran

 

 

I have very good news, so far I have tested 10x64, 10x86 and 8.1x64 (each one on 1.5 GB VHD) on 4 different Intel Chipset PCs and after a brief load of new drivers all Rambooted very fine, I didn't want to boot by FileDisk on any of the tested OSs in order to do not make permanent changes to them and increase the used space. Remaining free space on VHD after Ramboot is about 1 GB.

I tried to tell you that days ago but guess what it was nonsense from a retarded drunk.

You can only think in a box.

I think I found a hiden and AFAIK undocumented feature on WinNTSetup, since I never read about it on the program page, let me tell you I'm a big fan of that program, and an assiduous reader of that page, (even I was the first one to ask JFX to let me translate it, so more people could use it).

 

Well, if we select wimlib-imagex (libwim-15.dll) instead of Windows API during install, then automatically all files/folders on [PrepopulateList] section of the WimBootCompress.ini file located on WinNTSetup\Tools\ are applied (UNCOMPRESSED) during install (in addition to any other WimBootCompress.ini we used during Capture) and also copied that section to the new internal Windows\System32\WimBootCompress.ini so any new wim image made/captured latter from that install will keep this moded WimBootCompress.ini  (including wimb's suggested changes). Then just formated VHDs and made a new set of VHDs with this approach.

 

I have very good news, so far I have tested 10x64, 10x86 and 8.1x64 (each one on 1.5 GB VHD) on 4 different Intel Chipset PCs and after a brief load of new drivers all Rambooted very fine, I didn't want to boot by FileDisk on any of the tested OSs in order to do not make permanent changes to them and increase the used space. Remaining free space on VHD after Ramboot is about 1 GB.

 

Portability seems to be feasible without the learning process, of course we need more test on more PCs to confirm this in a total way.

 

Very GOOD News indeed

Can we use such modified WimBootCompres.ini also in wimlib-clc 

Thanks, I will have a closer look at Testsigning for Win10x86 version.

Very GOOD News indeed

 

We can use such modified WimBootCompres.ini also in wimlib-clc

 

Thanks, I will have a closer look at Testsigning for Win10x86 version.

Please take a look to my previous post againg.    I just added a new a picture of 10x86 too, there you can see it Rambooted fine without Test Mode.

Yes the modded WimbootCompress.ini will work very fine also on wimlib-clc if required, by the way I suggested the author to keep active the option: - include-integrity.  Since it is good when you are making your full OS backup to verify latter the integrity of the image before apply it.

But in this case as it is for running several tests (as faster as possible) I suggest you to dissable it on Main Menu Options and on Capture Tab Options too, it will reduce a little the Capture time.

Just in case some one would like to see the modded WimBootCompress.ini, This is it:

; This is the inbox configuration file used for deploying or capture a
; WIMBoot system. Please do not remove this file because WIMCaptureImage
; and WIMApplyImage will fail if WIM_FLAG_WIM_BOOT flag is specified.

[CompressionExclusionList]
ntoskrnl.exe

[PrepopulateList]
*winload.*
*winresume.*
\Windows\AppPatch\drvmain.sdb
\Windows\Fonts\vgaoem.fon
\Windows\Fonts\vgasys.fon
\Windows\INF\errata.inf
\Windows\System32\config\*
\Windows\System32\ntkrnlpa.exe
\Windows\System32\ntoskrnl.exe
\Windows\System32\bootvid.dll
\Windows\System32\ci.dll
\Windows\System32\hal*.dll
\Windows\System32\mcupdate_AuthenticAMD.dll
\Windows\System32\mcupdate_GenuineIntel.dll
\Windows\System32\pshed.dll
\Windows\System32\apisetschema.dll
\Windows\System32\api-ms-win*.dll
\Windows\System32\ext-ms-win*.dll
\Windows\System32\KernelBase.dll
\Windows\System32\drivers\*.sys
\Windows\System32\*.nls
\Windows\System32\kbd*.dll
\Windows\System32\kd*.dll
\Windows\System32\CatRoot\*
\Windows\System32\clfs.sys
\Windows\System32\CodeIntegrity\driver.stl
\Windows\Boot\DVD\*
\Windows\Boot\EFI\*
\Windows\bootstat.dat
*bootres.dll*
\Windows\Fonts\segoeui.ttf
wof.sys
\Windows\System32\Config\SYSTEM
\Windows\System32\PlatformManifest\*
\Windows\System32\drivers\*.sys <<<< Please delete this, it is duplicated from an unsuccessful test.
\bootmgr
\Boot\BCD
\EFI\Microsoft\Boot\BCD

[ExclusionList]
\$bootdrive$
\$dwnlvldrive$
\$lsdrive$
\$installdrive$
\$Recycle.Bin\*
\bootsect.bak
\hiberfil.sys
\pagefile.sys
\ProgramData\Microsoft\Windows\SQM
\System Volume Information
\Users\*\AppData\Local\GDIPFONTCACHEV1.DAT
\Users\*\NTUSER.DAT*.TM.blf
\Users\*\NTUSER.DAT*.regtrans-ms
\Users\*\NTUSER.DAT*.log*
\Windows\AppCompat\Programs\Amcache.hve*.TM.blf
\Windows\AppCompat\Programs\Amcache.hve*.regtrans-ms
\Windows\AppCompat\Programs\Amcache.hve*.log*
\Windows\CSC
\Windows\Debug\*
\Windows\Logs\*
\Windows\Panther\*.etl
\Windows\Panther\*.log
\Windows\Panther\FastCleanup
\Windows\Panther\img
\Windows\Panther\Licenses
\Windows\Panther\MigLog*.xml
\Windows\Panther\Resources
\Windows\Panther\Rollback
\Windows\Panther\Setup*
\Windows\Panther\UnattendGC
\Windows\Panther\upgradematrix
\Windows\Prefetch\*
\Windows\ServiceProfiles\LocalService\NTUSER.DAT*.TM.blf
\Windows\ServiceProfiles\LocalService\NTUSER.DAT*.regtrans-ms
\Windows\ServiceProfiles\LocalService\NTUSER.DAT*.log*
\Windows\ServiceProfiles\NetworkService\NTUSER.DAT*.TM.blf
\Windows\ServiceProfiles\NetworkService\NTUSER.DAT*.regtrans-ms
\Windows\ServiceProfiles\NetworkService\NTUSER.DAT*.log*
\Windows\System32\config\RegBack\*
\Windows\System32\config\*.TM.blf
\Windows\System32\config\*.regtrans-ms
\Windows\System32\config\*.log*
\Windows\System32\SMI\Store\Machine\SCHEMA.DAT*.TM.blf
\Windows\System32\SMI\Store\Machine\SCHEMA.DAT*.regtrans-ms
\Windows\System32\SMI\Store\Machine\SCHEMA.DAT*.log*
\Windows\System32\sysprep\Panther
\Windows\System32\winevt\Logs\*
\Windows\System32\winevt\TraceFormat\*
\Windows\Temp\*
\Windows\TSSysprep.log
\Windows\winsxs\poqexec.log
\Windows\winsxs\ManifestCache\*
\Windows\servicing\Sessions\*_*.xml
\Windows\servicing\Sessions\Sessions.back.xml

[CompressionFolderList]
\Windows\System32\WinEvt\Logs
\Windows\Installer

Also attached, just in case someone wants it this way.

EDIT: I think maybe the forum software make the file look wrong (a lot of * were added), had to put it in "code". Also the previous attachment may be wrong since the 7z file was made latter from a copy from the post. Please verify you have the right version. Added new verified attachment too, just in case.

alacran

And there is something else I forgot to comment:

wimlib-clc has included into it a little program called BCDBoot GUI, to run it see attached picture, it may be usefull too and maybe all could be made on  wimlib-clc, It was made to be used on WinPE environment, to try it for the first time I suggest to play safe and run it on WinPE first or from a Rambooted OS, or use it very carefully on your running OS only after making backup of your system BCD(s), there is always the risk to overwrite your BCD(s).

Sorry I can't give you more info, I only remember about it from the time I made wimlib-clc Spanish translation, but haven't used it never until now.

Edit: Just tested and added more pictures, my comments about this test on post No. 93

alacran

wimlib-clc has included into it a little program called BCDBoot GUI

 

I think this is not useful for making vhd boot entry

UEFI_MULTI is the better option to make boot manager entries for vhd

I think this is not useful for making vhd boot entry

 

UEFI_MULTI is the better option to make boot manager entries for vhd

Yes, you are right, I'm just coming from test it on a Rambooted 10x64 and I made some pictures (attached to previous post), it seems usefull for a new OS standard install, but it's not as versatile as BootIce to manually deal on a graphic environment with VHD entries on BCD or UEFI_MULTI to make/edit them in a totally automatic way

alacran.

@ All

I already know wimb prefer and recommend VHDs size for Ramboot as 2 GB.

But would you please try as your first experiment OSs with no extra added drivers (just to test portability), wimboot installed as recommended on post No.86 on 1.5 GB VHDs when testing on several PCs, and report back your findings.

It will be very easy to run again latter yor base VHD and load/install all drivers you want and make another wimboot VHD to your prefered size, or follow this procedure to resize the VHD,  so please I'm not asking this for myself, but to let other people know if 1.5 GB is a good minimum size or not for a VHD capable to boot on several PCs.

I think the info coming from this tests, may be usefull for many people, as this is the teoretical aproximate maximum size for a VHD to Ramboot on PCs with a minimum of 4 GB of RAM.

NOTE: The selection of wimlib on WiNTSetup needs to be done each time you run it.

alacran

Post No. 90 has been Edited since I detected wrong format on the file, please see it again if the Edit was not there when you first read it.

This is from the copy into WiNTSetup folder tools:

[PrepopulateList]
*winload.*
*winresume.*
\Windows\AppPatch\drvmain.sdb
\Windows\Fonts\vgaoem.fon
\Windows\Fonts\vgasys.fon
\Windows\INF\errata.inf
\Windows\System32\config\*
\Windows\System32\ntkrnlpa.exe
\Windows\System32\ntoskrnl.exe
\Windows\System32\bootvid.dll
\Windows\System32\ci.dll
\Windows\System32\hal*.dll
\Windows\System32\mcupdate_AuthenticAMD.dll
\Windows\System32\mcupdate_GenuineIntel.dll
\Windows\System32\pshed.dll
\Windows\System32\apisetschema.dll
\Windows\System32\api-ms-win*.dll
\Windows\System32\ext-ms-win*.dll
\Windows\System32\KernelBase.dll
\Windows\System32\drivers\*.sys
\Windows\System32\*.nls
\Windows\System32\kbd*.dll
\Windows\System32\kd*.dll
\Windows\System32\CatRoot\*
\Windows\System32\clfs.sys
\Windows\System32\CodeIntegrity\driver.stl
\Windows\Boot\DVD\*
\Windows\Boot\EFI\*
\Windows\bootstat.dat
*bootres.dll*
\Windows\Fonts\segoeui.ttf

As you can see it looks fine, it need to be added to the usual file or wimb's modded version.

Well, after checking what is altering the file I found the cause, if after make a VHD I open Windows\System32\WimBootCompress.ini inside the mounted VHD and make a copy of the file and put it somewhere on the Win10 PC when I open it all those lines added by WiNTSetup got an asterik * at the begining of the line, like this (just to show you, it's not complet, it is only [PrepopulateList] section):

[PrepopulateList]
*\Windows\AppPatch\drvmain.sdb
*\Windows\Fonts\vgaoem.fon
*\Windows\Fonts\vgasys.fon
*\Windows\INF\errata.inf
*\Windows\System32\config\*
*\Windows\System32\ntkrnlpa.exe
*\Windows\System32\ntoskrnl.exe
*\Windows\System32\bootvid.dll
*\Windows\System32\ci.dll
*\Windows\System32\hal*.dll
*\Windows\System32\mcupdate_AuthenticAMD.dll
*\Windows\System32\mcupdate_GenuineIntel.dll
*\Windows\System32\pshed.dll
*\Windows\System32\apisetschema.dll
*\Windows\System32\api-ms-win*.dll
*\Windows\System32\ext-ms-win*.dll
*\Windows\System32\KernelBase.dll
*\Windows\System32\drivers\*.sys
*\Windows\System32\*.nls
*\Windows\System32\kbd*.dll
*\Windows\System32\kd*.dll
*\Windows\System32\CatRoot\*
*\Windows\System32\clfs.sys
*\Windows\System32\CodeIntegrity\driver.stl
*\Windows\Boot\DVD\*
*\Windows\Boot\EFI\*
*\Windows\bootstat.dat
*bootres.dll*
*\Windows\Fonts\segoeui.ttf
*winload.*
*winresume.*
wof.sys
\Windows\System32\Config\SYSTEM
\bootmgr
\Boot\BCD
\EFI\Microsoft\Boot\BCD

All lines not starting with an asterik were there before since the time the wim was captured.

I don't know where the hell that asterisk comes from, and that made me edit the post. I start thinking it may be something related to the pointers/hard links and the OS or WinNTSetup creates them to identify some info, like a recent change, but I'm not sure.

So in order to have a file without the astericks I had to add manually the section to previous file and that is now what was posted.

alacran

Dear Alacran, Dear Flying Dutchman, Dear Wonko, Dear everybody wise and brave, 

I need your advice: 

Can I merge one wim into another from the same machine on the same machine and do so effectively, or will I have consistency problems?

If I can, how is that done?

I will give you a practical example: I have had my vhd+wim run smoothly for quite a few weeks. now I want to try another version of windows (smaller, promising to be faster, or whatever) and still keep all the configuration that I have enjoyed so far. do I have to install the software and configure things all over again?

nino

sorry for my stupid question. Me as a speaker-now can venture to say that - I have just learned how to do it. it is the append command that I was not familiar with, so as a speaker-then it was not so stupid. now that I have appended the content of a working vhd to a new wim (winpe), will the resulting wimboot have the source wim or the appended vhd as its core? viz, will it carry over any possible defects characterizing the appended vhd, or will it assert the base wim's correct features? I was wondering whether this operation could be used to correct possible errors or misconfigs in the vhd to be appended.

Any ideas or help is wellcome.

But several hardware depending drivers are Start=0 at install.wim.
At installation, StartOverride is set to unused drivers, these drivers are disabled at current hardware.
If you like to boot at different hardware, then delete StartOverride and add the driver *.sys files to the vhd image.

Enable bootlog at bcd file. And read ntbtlog.txt after boot.
All files before mup.sys are used early at boot.
Create a new WimBootCompress.ini, include required system32\drivers only.

Thanks for interesting info.

How to enable bootlog is described here