245 replies to this topic

[antonino61]

u r correct in what u say last, which already answers ur question. u can make a mother wim from a child install. but more practically, at least at the beginning, grab an install.wim and derive a child vhd thru winntsetup. this vhd will contain mostly hard links to the wim and will boot fast and call programs on an on-demand basis, by ur simply calling them. that is how u start. but if u want to keep whatever u have installed previously u can capture the state of ur pc thru gimagex (1st option, 1st menu). u will so obtain a .wim file. from this wim u can derive a child vhd as I described above, which will have kept all u had installed earlier. so u will have the same situation as before installation-wise, yet in a smaller space. the vhd is a booting and working medium (which u rightly called child), all the info about everything resides in the wim (which u rightly called mother). 

nino

[alacran]

I am failing to see where the wim and the vhd are connected, and how. 

Couldn't find it in the OP and didn't go through all posts thereafter. If anyone be so kind to show me how to connect the vhd to the wim, because if I get it all right, it seems to me that there's a mother wim from where a child vhd retrieves data from, during normal OS operations, ram or disk booted regardless. 

 

Well my friend, if you want full info you need to read at least all links on the Post marked as answer.

 

But your question makes me think you do not know wath is wimboot, to know what is wimboot see: https://docs.microso...94399(v=win.10)

 

But don't belive all limitations on that info.

 

alacran

[Camiel]

I think I've found the culprit.

Never knew there's wimboot option in capture mode. I've always used wimboot in apply only. 

Means more than 4 years hitting my head in the wall trying to reduce the size of the final wim with various ways to fit in a decent size vhd to boot it from ram. The minimum I have reached was 2.5G with all drivers installed. 

 

Thank you for bringing to my awareness this life changing fact. Out to abuse it as much as I can.  

[alacran]

I think I've found the culprit.

Never knew there's wimboot option in capture mode. I've always used wimboot in apply only. 

Means more than 4 years hitting my head in the wall trying to reduce the size of the final wim with various ways to fit in a decent size vhd to boot it from ram. The minimum I have reached was 2.5G with all drivers installed. 

 

Thank you for bringing to my awareness this life changing fact. Out to abuse it as much as I can.  

 

Well, the wim do not need to be on the VHD that will be loaded on Ram, that is the big advantage, load on Ram only the VHD and let the source wim file remain outside on the root of your device or on a folder or even on another partition if you want, here for simplicity we use a folder named Wimboot [containing the wim(s)] on the root of the same partition the VHD is located.

 

To save even more espace see: http://reboot.pro/to...-faster-on-ram/

 

You can make a file so small as 10x64-WB.vhd.lz4 of 135 MB wich in turn loads to Ram in a few seconds 10x64-WB.vhd of 1.5 GB (having about 1 GB free) bootable on PCs with a minimum of 4 GB Ram.

 

alacran

[Camiel]

I think I got the gist now. I was doing it all wrong. 

Thanks alacran

[alacran]

I think I got the gist now. I was doing it all wrong. 

Thanks alacran

 

You may also try: http://reboot.pro/to...-for-os-in-vhd/from wimb, it has all you need to do, on a single little program.

 

alacran

[quarky42]

EDIT:  I might be barking up the wrong tree here.  I see that I have gotten off track again and confused you with WIMB.  I remember now that it was WIMB That came up with the VHD_WIMBOOT package...so maybe I should be asking him instead?  I apologize...  I lost track of who was who.  I have had some starts and stops in working on this with some time elapsed in between.

 

alacran:   Would you help me consider a slight variation and how to handle it?

 

I already have an existing VHD that I boot up into Hyper V.  It has all the customizations (and it has SVBUS installed with the test mode signing / disable integrity checks, disabled pagefile / disabled hiberfile already built into it).   I was able to mount it and I have completed the first capture of the capt_f.wim file from this VHD.  It is a fresh install of Windows 10 that is fully updated.   This is the same VHD that I use as part of a Windows 10 RAM Boot.  So, my goal here is to take an existing ram bootable image and wanting to convert it into a VHD + WIM RAM Bootable.

 

As I am working through the VHD_WIMBOOT.pdf I am at the step where I use my captured .wim file from the full Windows 10 Install.  I'll be feeding that WIM file into WinNTSetup to install this customized version to a new 2GB file with wimboot enabled.  Here is where I have a problem I'd like help with:  I believe the WinNTSetup wants to modify my boot loader under "Select location of the Boot drive".  I don't want to modify the bootloader of my computer.   I already have an external drive that is setup with Grub4DOS.  So, once I get a VHD and WIM "set" I should be able to add it to my existing Grub4DOS bootable drive.

 

My ultimate goal is to end up with a VHD file that I can ram boot from the Grub4DOS bootloader that referemces the wimboot file.   So my goal is similar to yours, but I am trying to get there through a path that doesn't involve me changing the bootloader on my existing computer.

 

To boot up the 2GB VHD file and complete the setup, I should already have SVBUS baked into it...so I should be able to boot it as the FileDisk straight from the Grub4DOS external drive.

 

Do you mind helping me work through this variation?  I know it is a deviation from the way you presented it, but I think it has value.    At the end of this, if successful, I should be able to provide some useful input on how to do all of this through HyperV.   It may or may not be clear what the benefit of this would be, so let me just add that by using HyperV to create all of this it makes testing changes to the image / adding updates and much more far easier.  I've already been testing a SVBUS RAM Disk bootable image from HyperV quite a bit and have had a great time working with it.  The revision process is far easier this way and if I break my image, I can easily restore a previous version with a single file copy operation or extraction from an archive.

 

EDIT #2:  I went ahead and went to the next Setup screen after selecting my local boot drive and tried choosing "do nothing" from the drop down list.  I really don't want to mess with my running system.  I'd like to get it all booting under HyperV and/or the Grub4DOS disk.  I hope I am on the right track.

Edited by quarky42, 05 April 2019 - 07:33 PM.

[alacran]

@ quarky42

 

Our friend wimb is the author of VHD_WIMBOOT, but I can try to help you.

 

Well, according with your previous post you already have created the first VHD and capture it, take a look to my post No. 7 about partitions on the USB device and follow instructions to repartition yours in accordance.

 

I suggest you to use new wimb's tool: http://reboot.pro/to...-for-os-in-vhd/

 

And make an install on your external USB device, selecting the boot partition and the system partition of your USB (They may be the same if you made only one partition), this tool will do all for you, including create all required Windows bootmanager and grub4dos on your USB device,

 

alacran

[quarky42]

Before your reply, that was the path I was heading down.  I setup a different external (to preserve what is working on my main one) and I have not been able to get it to work using that method.   

 

I didn't see any errors during the VHD_WIMBOOT processes.   

 

I think the problem is my BCD file(s).  Neither the BCD on the boot partition nor the BCD inside the VHD file make any reference to the WIM file.  My best guess is that one of those should be pointing to the WIM file somehow.   I tried to add attachments here, but I lost my entire writeup instead.

 

So here are some screenshots and descriptions of what I have. 

[antonino61]

i do not think it should refer to the wim; it should refer to the vhd.

why do u not use bootice to verify both g4d and bootmgr entries?

[quarky42]

That's not what I said Antonino. Also I linked to graphics showing my BCD files (inner and outer) that you didn't look at before replying.

I believe one of the BCD's should refer to both the vhd and the wim. I could be wrong but the errors seem to be pointing towards something is missing.

[antonino61]

i did look at ur pics, but what u say is true not of what u showed: the double reference should only be in the top right hatch, where the option chosen is supposed to say LOCATE ... VHD + WIM or something of the kind. if it is not so, as I think, make sure it is set to LOCATE...

nino

[quarky42]

If you have a working one, then you could post it and I could compare. Both the outer BCD config and the inner BCD config inside the VHD. Without something precise to compare to or someone that knows for sure what is wrong, it is just guessing.

How does the VHD know where to get the WIM if it isn't set somewhere? Maybe there is somewhere else inside the VHD that refers to the WIM, but I think I saw an example of a BCD with WIM / VHD boot before and I think it referred to both. I can't find that example again right now, though.

[antonino61]

what u said last is exactly what I mean. 

as for pointing, it is the wim that knows which vhd is the one.

posting, I wish I could, but I have never got around to sending pix here. 

I can tell u exactly where it is on the bootice screen.

once in bootice, select bcd, on the bcd screen for the vhd entry (not for the g4d one) look top right and make sure vhd(x) is selected (instead of partition or ramdisk)

in the hatch below, the first option is to be selected ***BOOT(WIM) / LOCATE(VHD)***

two hatches down, make sure u have \*.vhd

(* being the vhd filename)

now look down to the bottom: all squares must be ticked  but the top right and bottom center ones, which have to be half-ticked (black squares inside the squares)

I think u should be good to go once all these things are accomplished.

all the above is good for external booting (bootmgr)

as regards the internal bcd, ***BOOT(WIM) / LOCATE(VHD)*** is still the same but u have to have partition selected this time instead of vhd(x)

there is no such thing as \*.vhd two hatches down and down at the bottom  the top left and right squares should be half ticked this time and the bottom center is to be left unselected (blank); the rest are ticked.

[quarky42]

A picture is worth a thousand words. I took the time to point you towards how to share images before but you didn't take the time to try. I am having a hard time following what you're saying above, so you really want to help me, you can sign up for a free Imgur account, click "Post", and literally drag and drop the pictures onto the browser window while making the post. At the end you get a URL that you can share here and I can see an exact picture of what you are talking about.

If you need help taking the screenshot itself, there is a Snipping Tool built into Windows. It'll help you take the screenshot and save it as a file.

[antonino61]

I think I got it now, check

nino

Attached Files

•  Capture.PNG   834.17KB   0 downloads
•  Capture1.PNG   912.45KB   0 downloads

[alacran]

How does the VHD know where to get the WIM if it isn't set somewhere? Maybe there is somewhere else inside the VHD that refers to the WIM, but I think I saw an example of a BCD with WIM / VHD boot before and I think it referred to both. I can't find that example again right now, though.

 

To satisfy your curiosity, Just See:

 

http://reboot.pro/to...e-6#entry209947

http://reboot.pro/to...e-6#entry209952
 

 

But after seen your pictures it is clear to me that is not your problem,  During boot some driver(s) can't be found/loaded, you should use http://reboot.pro/to...-for-os-in-vhd/, to capture the first VHD and then reaply it as wimboot, because it has integrated a modded WimbootConfig.ini that has some changes to include drivers UNCOMPRESSED as per my list here http://reboot.pro/to...-6#entry209949, and also it will apply all required changes to BCD(s) and menu.lst, so both possible causes to not load/find the drivers will be avoided this way.

 

alacran

Attached Files

•  External BCD.png   88.02KB   0 downloads
•  Internal BCD.png   74.6KB   0 downloads

[quarky42]

I'll try again tomorrow, but I think I did try capturing the initial WIM using that tool on my last attempt. I don't mind trying again that way to be certain.

[alacran]

@quarky42

 

Don't forget to format/partition your USB drive as per my post: http://reboot.pro/to...hd/#entry209488

 

I strongly suggest use a FAT-32 first primary active partition for booting files/folders, and a second NTFS primary partition for your VHD and wimboot source wim files.

 

Then using VHD_WIMBOOT capture your VHD (where SVBus driver was previously installed) from its actual location, copy the resulting wim file to a folder on the root (8 characteres max. for folder name) or directly to the root of NTFS partition and using again VHD_WIMBOOT create the wimboot VHD on NTFS partition, all required BCDs will be created and also grub4dos files, to let you boot by means of Windows boot manager or Ramboot by means of grub4dos

 

alacran

[quarky42]

Yes. It is already formatted like that. That is how I captured it the last time I tried to get it to work. I'll try it again tomorrow though and verify that I didn't miss something. The svbus driver was installed but it isn't required for wim vhd boot though right? Just needed if I was going to ramboot the wim vhd.

[alacran]

The svbus driver was installed but it isn't required for wim vhd boot though right? Just needed if I was going to ramboot the wim vhd.

 

Yes, you are right.

[alacran]

From my post: http://reboot.pro/to...e-4#entry210609

 

 

I have a new addition to moded WimBootCompress-2019-03-31.ini (attached).

 

[ExclusionList]
\MSOCache\*  >>> This is the hidden cache folder after installing Office (saving to compress in your wim file from about 300 MB to almost 1 GB, depending on version), sometimes it may be created on other partition if available.

 

 

alacran

 

Attached Files

•  WimBootCompress-2019-03-31.7z   1.22KB   6 downloads

 

Sorry just forgot to mention this here before.

 

alacran

[wimb]

Also on attachement download you will find an unattend-Basico folder containing a basic unattend.xml file that requires to be edited to your preferences before using it to let you make a silent install (no questions from OS during install).  Even if this file says on first line <?xml version="1.0" encoding="utf-8"?> it is not true it is ANSI encoded but this first line is a requirement to let the OS follow the instructions, and do not commet mistakes in non en-US versions AFAIK,

 

 

I have used your unattend.xml file modified for my case. Thanks for sharing this unattend.xml file

 

The Unattended Windows Setup Reference PDF downloaded from here , does Not contain any info on 2 lines found in the OOBE Section

                <SkipMachineOOBE>true</SkipMachineOOBE>
                <SkipUserOOBE>true</SkipUserOOBE>

May be these lines can be removed. In any case it works well without these lines.

 

Also there is probably no need for the AdministratorPassword Section, since everything works well without this section.

[alacran]

Hi wimb.

 

Remember there have been a lot of changes on every new version of 10, and my unattend.xml file is maybe based on a source older than yours. Having those parts there do not hurt or create any issue, since I have used it that way many times.

 

About this:

 <SkipMachineOOBE>true</SkipMachineOOBE>
 <SkipUserOOBE>true</SkipUserOOBE>

See: https://qtechbabble....-moment-screen/

 

And also this comment on that page:

 

They are and have been deprecated for years, yes. Despite this, Microsoft has confirmed that enabling these settings will still skip OOBE altogether. The newer supported method involves addressing each individual OOBE page in the answer file, but I haven’t yet built a longer XML like that since this older method is still working fine in my environment. See this article for details on skipping individual pages: https://docs.microso...p/automate-oobe

 

EDIT: And about removing AdministratorPassword Section, you are not removing it, you are using same name and password as for user. (from your attachmend on http://reboot.pro/to...x/#entry212337)

 

But if you have already tested it your way, and it works fine, then I trust your tests and don't see any problem if user wants to use your way.

 

Just to make this info more useful for future readers please tell us in what Win10 versions you tested the unattend.xml file with those parts removed.

 

Additional/Optional Info:

This page Windows Answer File Generator can be useful too:   https://www.windowsafg.com/

I recommend to test the answer files on a virtual machine before using them on real hardware.

 

alacran

[wimb]

I have tested my unattend.xml file on Windows 10 Home NL with Release ID 1903

 

Thanks for giving details about why SkipUseOOBE and SkipMachineOOBE were used.

They don't hurt indeed, but are Not needed anymore for the newer Windows 10 versions.

 

I like to use the unattend.xml file in WinNTSetup since it saves a lot of time thinking about all the questions otherwise encountered during Windows 10 Setup.

It is completely Unattended when creating a Local Account.

Later, After Install of Windows 10 one can switch to MS On Line Account.