245 replies to this topic

[alacran]

@ wimb

 

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

 

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.

 

Thanks for commenting on what specific version you have tested your modified unattend.xml file (I haven't used 10 1903 yet), I'm still on 1809, I prefer to go slowly and at least one version before last one, to avoid troubles.

 

Yes, I allways use my unattend.xml file with WinNTSetup and also my OEM folder to control better some other things, in order to have a fully unattended install just the way I like it. For additional info you may see: https://forums.mydig...-mrp-mk3.71555/

 

alacran

[alacran]

New version of WinNTSetup with new features, for more info see: http://reboot.pro/to...ntsetup-4-beta/

 

alacran

[quarky42]

I have an external drive that is able to do a "normal boot" (filedisk) of the VHD+WIM variety under UEFI and under Grub4DOS. The RAM boot option in Grub4DOS fails with this error:
"Error 13: Invalid or unsupported executable format" after the chainloader /bootmgr command is executed.

I was originally having a lot of problems getting this drive to boot into Grub4DOS because the VHD_WIMBOOT and RMPrepUSB neither of them made the FAT32 partition active when installing Grub4DOS. When I finally noticed the FAT32 partition wasn't active, I made that change, and was able to get into the Grub4DOS bootloader finally. During that troubleshooting, I figured out that the UEFI BCD file is the one under /EFI/Microsoft/Boot and not the one under /BOOT/.

Anyway, I would really like to get the RAMDISK boot of this VHD+WIM working. I am currently using Grub4DOS 0.4.6a 2019-09-09. I am happy to try any other versions recommended. After I post this I'm going to make sure that I load version that came with the VHD_WIMBOOT instead and try that one. That looks like 0.4.6a 2019-06-17.

Edit: Same error with the 2019-06-17 version that came with VHD_WIMBOOT.

Edited by quarky42, 09 October 2019 - 07:37 PM.

[alacran]

@ quarky42

 

I just edited some post with updated info, this may be usefull for you, please see:

 

http://reboot.pro/to...hd/#entry209483

 

http://reboot.pro/to...hd/#entry209485

 

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

 

Signed SVBus installer attached for your convenience.

 

About your comment related to your Fat-32 partition not active: It was said on Bold on Post No. 7:

 

 

Installing your Wimboot VHD on a USB device.

 

For puting your VHD on a portable USB HDD or SSD (preferable), partition and format your device as following:

1 .- Your HDD or SSD has to be inicialized as MBR disk, to let you Ramboot the VHD.

2.- If you want to boot as MBR first primary active partition can be NTFS or FAT-32.

3.- If you want to boot your device on MBR and also on UEFI, first primary active partition has to be FAT-32.

4.- First primary partition needs to have bootmanager PBR.

5.- Second primary partition has to be NTFS so you can mount  and run VHDs fron it.

 

If you need further assistance just ask and I will do my best effort to help you.

 

Best Regards

 

alacran

Attached Files

•  Signed_SVBus_x64.7z   19.91KB   8 downloads

[quarky42]

@ quarky42

 

I just edited some post with updated info, this may be usefull for you, please see:

[...]

About your comment related to your Fat-32 partition not active: It was said on Bolt on Post No. 7:

 

Thanks, I'll check those out.

 

Regarding the FAT32 partition:  I did not see Post 7 recently.  I will read it again.  When I got to Post6 I thought that was it.  Could the VHD_WIMBOOT not be made to check if the FAT32 partition is not marked as Active and ask the user if they would like to make it active for Legacy Boot?   (Something like:  "Would you like to mark the the FAT32 partition as "Active".  This is required for Non-UEFI / Legacy Booting of the drive.")   If the user clicks yes, the tool makes the partition active,  If the user clicks No, then it skips that.

 

I was using the PDF for most of the setup and it says:  "1st partition 20 GB FAT32 Set Active for Boot Manager and Grub4dos Boot files and 2nd partition NTFS for VHD + WIM System files"  and this isn't true.   Boot Manager doesn't care if the FAT32 partition is active.  I was able to boot with Boot Manager under UEFI multiple times, no problem at all.   For Legacy Boot (Non-UEFI), the user must go and make the FAT32 partition active.   So this could be adjusted to make it more accurate and more clear:    Something like -  "Make the first partition on the drive 20GB in size, FAT32 Type, and set that first partition to "Active" in Windows Disk Management or other disk management application so that Grub4DOS Boot files will work under Legacy / Non-UEFI Booting.  The second partition should be NTFS for the VHD + WIM System files."    Or really, that whole quote could be made into two lines / two instructions.  One instruction that is clear for the first partition.  Another instruction that is clear for the second partition.

 

This is an example of some of the wording that can be confusing in the PDF file or on forum posts. 

 

Of the three links you just gave me, I do not see how the first one applies to the issue I am having with RAMBooting.   My original VHD file that I created my WIM from was already fully setup and working as a full ram boot of around 16GB.

 

Your second link, looks like you added info about "wimlib-clc" used to apply the WIM Boot Image to the smaller VHD file.    I used wimlib-clc for the capture.  I used VHD_WIMBOOT to create the new VHD file and apply the WIM Boot Image to it.   I did not use the wimlib-clc separately to apply anything.  What am I missing here?      The process for me was to take a working full VHD image of Windows 10 that has the test signing turned on, SVBUS driver installed, and the metro style boot manager disabled and is setup the way I want it with any applications and setttings I want.   I run that VHD through wimlib-clc to capture a new WIM using the settings provided in the VHD_WIMBOOT.pdf file including the files that are to be compressed using that ini file.    I take that WIM file and apply it to a newly created 2GB VHD file with RAMBOOT selected in the VHD_WIMBOOT application and I apply all of that to a drive that has a 20GB FAT32 Boot Partition that is set to Active, and a NTFS System partition for the large files to sit on.    I do not see how the second link applies to any of this.  I feel like I am maybe missing something here, unless the VHD_WIMBOOT is just a wrapper for wimlib-clc and is using that tool under the hood?

 

Your third link:  I was using that ini file that I downloaded from that post.  I extracted it from the 7z file and used that with wimlib-clc during the capture process I talk about above.

 

None of those things have anything to do with my situation:  I can boot the VHD+WIM directly using Boot Manager (UEFI) or directly using Grub4DOS now.   When I try to do the RAMBOOT in Grub4DOS, that fails with the error message that I gave.   This post talks about the RAMBoot: http://reboot.pro/to...hd/#entry209488

I thought the VHD_WIMBOOT application set everything up for the RAMBOOT.    I ran the GRUB4DOS commands manually and was able to run every one of them without error until the chainloader /bootmgr command... so it did fine the VHD file, it did load the 2GB to RAM... but when I tried to chainloader into the bootmanager it fails telling me Error 13 that I described above.

 

So assuming I need to edit a BCD entry still to get this to work, can you please explain this section better from that link:

"Ramboot

 

Also there is another set of BCD(s) located into the VHD that will be used when Rambooting, you need to verify/modify only the one located on C: \Boot \BCD in accordance with Other BCD.png and BCD into VHD.png (so far there is not possible to Ramboot on UEFI, so it is unnecessary to edit that BCD).

 

Also you will need to Download grub4dos-0.4.6a-2018-12-23.7z 516K, extract it on a folder and add to your USB device first partition (FAT32) the following files: grldr.mbr, grldr and create a menu.lst, I'll attach part of mine as a guide for you. Also you will need to create a new entry on Boot\BCD located on first partition (FAT32), open it on Easy mode and on the left sellect Add New Real Mode Entry (Grub/Linux), once created Save Gloval Settings, go to it and on right panel rename it to Grub4dos Menu, then Save Current System and that is all, now you can Ramboot from your VHD.

 

Use attached pictures as a guide.

 

NOTE: Added a new picture VHD BCD.png for a latter and more generical option suggested by karyonix to use into BCD located into VHD boot folder (actually used by wimb's tool http://reboot.pro/fi...for-os-in-vhd/)"

 

I looked through the attached screenshots, but none of them seemed to show the Grub4DOS entry that you are talking about.   I'll try to follow those instructions, but they aren't real clear to me at the moment.

 

Specifically:  "you need to verify/modify only the one located on C: \Boot \BCD"       What C: drive?   Do you mean I need to boot up into the VHD file and use BootICE from within that DISKFILE boot and edit the BCD file in there?     C: drive is confusing in this context.   Also when creating the new entry further down...is that for \grbldr.mbr ?

Edited by quarky42, 09 October 2019 - 11:17 PM.

[alacran]

I'm not the author of VHD_WIMBOOT so I can't modiffy anything on that program.

 

This thread is my manual method to make the smaller possible Wimboot VHDs.

 

On Rambooting Wimboot VHDs usually all problems (after loading to ram) during booting are caused by some drivers not available on the VHD during boot, or they are pointers to the source wim and not real extracted files. And I have seen many different messages but allways the same cause.

 

As you posted your questions on this thread I edited those post with the updated info related to the possible causes of the issue you have, trying to help you solve the problem.

 

Only during Ramboot the svbus driver is used/required, so it may be corrupted, be a pointer file not a real standard file or not loaded during boot process because it is not signed and/or approved by MS and your BCD do not allow to load it.

 

Open your unmounted VHD with 7-zip and go to Windows\System32\drivers\svbusx64.sys and if its compressed size is = 0 it is a pointer file, if it is > 0 then it is a normal file (not a pointer), also since you are there take a look to all other *.sys (drivers) files using same criteria.

 

alacran

[alacran]

In case all looks fine with previous test, and just to make sure this is not the cause, then now mount your VHD (don't run it) and copy the file svbusx64.sys to somewhere on your local OS, and open it with a hex editor (as the free TinyHexer) and verify it is not full only with zeros.  As this happened to wimb with some other drivers, (when using WinNTSetup) see bottom pictures on this link: https://msfn.org/boa...comment=1171035

[quarky42]

Thank you. I was not complaining, but rather saying I didn't see the connection to my problem, so if it was related, I would need more information to try and understand how. Otherwise it didn't apply.

The chainloader /bootmgr command in Grub4DOS fails immediately. If that command worked, the next command would be boot since I was at the command line entering everything manually.

I'll go check that svbus driver file anyway, but it wasn't even starting to load windows. It was giving that error in Grub4DOS when trying to chainload the windows bootmgr.

I can try applying the wim to a new vhd using wimlib-clc, but that is where I don't fully understand the instructions you've given for your method to get it setup. It may make more sense if I try it again. Sometimes I just have to work through something a few times to finally get what is going on.

[alacran]

The chainloader /bootmgr command in Grub4DOS fails immediately. If that command worked, the next command would be boot since I was at the command line entering everything manually.
 

 

You didn't say this at the begining, there is necesary a little special code in menu.lst, this is an example adapt this to your needs:

 

# Valid for VHD+Wim on internal HD (located on any partition)

title 10x64-WB.vhd - SVBus  RAMDISK  - map as (hd) for RAMBOOT
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr


# Valid for VHD+Wim on external HD (located on second partition)

iftitle [if exist (hd0,1)/10x64-WB.vhd] (hd0,1)/10x64-WB.vhd - SVBus  RAMDISK  - map as (hd-1) for RAMBOOT
map --top --mem (hd0,1)/10x64-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

You can edit (hd0,1) in acordance with your VHD location but Do NOT edit (hd), (hd-1) & (hd-1,0)

 

YFYI: There is no need of boot command after chainloader /bootmgr
 

If you want to know where this menu.lst entries come from see: http://reboot.pro/to...s-svbus-driver/

[alacran]

Also before trying to Ramboot, first filedisk boot your VHD and on the root of it (wich will be C.\ when booted) locate: Boot\BCD (it will be hidden you need to make it visible first on explorer settings, unselecting Hide protected files of OS) and edit it (with BootIce) as in the attached picture, the picture is for signed SVBus, if yours is not signed then you need to select also No Integrity Checks.

 

Quote from my Post No. 7

 

Ramboot

 

Also there is another set of BCD(s) located into the VHD that will be used when Rambooting, you need to verify/modify only the one located on C: \Boot \BCD in accordance with Other BCD.png and BCD into VHD.png (so far there is not possible to Ramboot on UEFI, so it is unnecessary to edit that BCD).

 

The meaning of the sentence marked in red text is:

 

so far there is not possible to Ramboot on UEFI, so it is unnecessary to edit the [UEFI] BCD [located on EFI\Microsoft\Boot\BCD]

 

I think this should also answer your previous question on Post No. 180:

 

 

Specifically:  "you need to verify/modify only the one located on C: \Boot \BCD"       What C: drive?   Do you mean I need to boot up into the VHD file and use BootICE from within that DISKFILE boot and edit the BCD file in there?     C: drive is confusing in this context.   Also when creating the new entry further down...is that for \grbldr.mbr ?

Attached Files

•  BCD.png   31.52KB   0 downloads

[alacran]

Another option is to use UEFI_MULTI made by wimb and it will modify the Boot\BCD into the VHD and on the external BCD (located on boot partition of your system or the USB), and create a new or add to the menu.lst (if it was present) the required code for fileboot or Ramboot automaticaly,

[Wonko the Sane]

 

YFYI: There is no need of boot command after chainloader /bootmgr

Strictly speaking, that is not entirely correct, worded like that it is ambiguous for anyone not already familiar with grub4dos.

 

There is an implied boot command executed after the last line in a menu.lst entry, (i.e. anything that begins with "title" or "iftitle" and that is followed by either another "title" or "iftitle" or by an EOF) that makes the boot command not needed in this specific case where the last line in the menu.lst entry is "chainloader /bootmgr", but the command is obviously needed on command line. 

 

Wonko

[quarky42]

I thought it was clear when I said:

"The RAM boot option in Grub4DOS fails with this error:
"Error 13: Invalid or unsupported executable format" after the chainloader /bootmgr command is executed."

Though I didn't use the word immediately, I also didn't use the words "after a long wait". So, I do see why it was hard to understand. I am sorry. I will try to be more clear.

When you step by step manually enter the commands to test a boot in G4D commandline, the last command you end with is: boot. When you use an entry in the boot menu, the boot command isn't in the menu file but it is automatically applied. So yes, the boot command is necessary when you are testing and stepping through each line manually entering them. Yes the boot command is not required in the menu.lst file. Both are true and are how it is being done already. There is no boot command in my menu.lst.

Every command works without error until chainloader /grubldr. When it hits that one it immediately fails with the error I've described. The other commands before that are all the same as the ones you've posted except of course for my vhd file name being a little different.

Remember, this vhd+wim are able to boot directly with G4D or windows boot manager. It is only the ramdisk boot that fails when it tries to chainloader over to the bootmgr file on the roof of the mounted vhd. The BCD is already edited to be able to ramboot. (It already has test signing, and the metro screen disabled.)

When I get to my desk I will read the links you've posted and I will also try applying the wim to a new vhd using the wimlib-clc instead of the vhd_wimboot and see if that helps.

[wimb]

I have an external drive that is able to do a "normal boot" (filedisk) of the VHD+WIM variety under UEFI and under Grub4DOS. The RAM boot option in Grub4DOS fails with this error:
"Error 13: Invalid or unsupported executable format" after the chainloader /bootmgr command is executed.
 

 

If you would have used VHD_WIMBOOT to Capture the WIM file then the WimBootCompress.ini is used that contains \bootmgr and \Boot\BCD in the PrePopulateList section.

These entries are essential to get rid of error 13.

 

So if you really did everything according to  the VHD_WIMBOOT.pdf manual and only used VHD_WIMBOOT for Capture and Apply then there was no problem ....

The problem is that you used wimlib-clc for Capture and then VHD_WIMBOOT for Apply ......and then you miss the essential entries for booting with grub4dos.

 

Also is clearly mentioned in the PDF how to set the FAT32 partition active ....needed for booting in BIOS mode with grub4dos.

 

[quarky42]

Thank you. That makes perfect sense and I'll fix those entries in the WIMBootCompress.ini file and retry.  

 

Regarding the PDF:  It is hard to follow.  That is why I ended up using wimlib-clc to capture... because I understood wimlib-clc and its capture process better.   This is not a defense here:   It is my mistake by using two different guides that created this problem.  It is totally my fault, but I had a hard time following either guide because they are in fact hard to follow.   

 

Once I have this working and I can see how to improve the guide further, I'll be making some suggestions or if you were willing to give me the document file version, I could edit that directly and send it to you for any additional modification/correction needed after I am done with it.    

 

There are two different processes written by two different people for achieving the same goal, but neither process is documented in a way that is fully easy to follow.  There are assumptions and disconnects in both sets of documentation.    The FAT32 statement about the partition being active is written in an indirect way.  Indirect language is hard to follow.   Direct language:   "Use Windows Disk Management, right click on the "BOOT" FAT32 partition and set it to active in order for Grub4DOS to be Non-UEFI / Legacy bootable"  is much easier to follow.   With indirect language it is easier to miss important parts of the sentence / miss the meaning.      The forum based instructions are also hard to follow as they are spread out across different posts.   

 

There are times in the PDF where it feels like I'm just supposed to know how it should look...or I should know that the screenshot that a step is referring to is on a different page.   I've written user guides before, so I feel like I could help make this one easier to follow if I may contribute to it once I understand fully where the issues are, but in order to understand the issues in the documentation, I have to understand exactly how to achieve a fully working vhd+wim boot image.

 

For me: Step 1 - Get a RAMBoot and Direct Fileboot working so that I have something to compare against / so that I can see all the pieces in place and how they are connected.   In this case where I am at now, I could see that the problem was the handoff to the /bootmgr but I couldn't see why.   The file being compressed and not directly executable from within G4D makes perfect sense.

 

Step 2 - Go back and start over with the VHD_WIMBOOT and try again to capture the WIM from my original full VHD and then apply using that.  If I have problems, the fact that I have a working one to compare against should help me spot any differences and see where I messed up.

 

Step 3 - Once I have a good grasp on how to use it, I should be able to help make some edits to the document, add some screenshots, add some clear references to the screeshots so that it is clear what steps they apply to  (Figure labels and referring to those figure labels is common in user guide documentation.)   

[quarky42]

When I used wimlib-clc to capture:  I used the WIMBootCompress.ini from here:

http://reboot.pro/to...e-4#entry209815

 

It already has these entries under the PrepopulateList:

\bootmgr
\Boot\BCD
\EFI\Microsoft\Boot\BCD

So, Was there something else wrong with the WIMBootCompress.ini that I was using since I got it from there?

 

I am attempting a capture from VHD_WIMBOOT and will apply with the same utility and see what I get.  If that gives me a set of images that can be rambooted, then I can always try to do it all over again using alacran's method and see either where I messed up or try and see what the difference is.

[wimb]

When I used wimlib-clc to capture:  I used the WIMBootCompress.ini from here:

http://reboot.pro/to...e-4#entry209815

 

The question is how did you use in wimlib-clc that WimBootCompress.ini .....

Does it really arrive inside the captured WIM File ?

Use 7-zip to analyse your WIM-file and see what is the content of Windows\System32\WimBootCompress.ini

[quarky42]

"How did you use in wimlib-clc"...   See page 4 of the VHD_WIMBOOT.pdf.   That is how I captured my original WIM file.  Instead of G:\wimlib-clc\WimBootCompress_BCD.ini, I had it pointing to the one I downloaded from the post above.

 

Update though:  I was able to us VHD_WIMBOOT to capture a new wim file, created a new VHD with it, and applied the newly captured wim to that VHD.  It successfully boots up into RAM.  I also was able to direct boot it using the UEFI / Windows Boot Manager.   I need to go create a Grub4DOS file boot entry, but that should be pretty easy and there are plenty of examples to draw from.  It would be nice if the VHD_WIMBOOT would create both entries under Grub4DOS though.

[alacran]

So finally you got it working, congratulations.

 

Next time select the procedure you want to follow, and follow it very carefully, and also DO NOT mix it with another procedure to avoid mistakes.

 

Once you make it first time, you can try a second procedure to make another test, but also follow it without mixing instructions and all will be fine.

 

Later when you are familiar with all things involved on the task, you may try some variations, and see it they work fine or not.

[quarky42]

Next time select the procedure you want to follow, and follow it very carefully, and also DO NOT mix it with another procedure to avoid mistakes.

 

Of course.   However that is assuming that either procedure made sense all the way through and I didn't get stuck part way through it, which I did. 

 

On both procedures, I had trouble understanding what to do at different points because there were parts that were vague.  In several places a picture that was directly and clearly labeled for which step it went with would be much more clear.   I would like to help make both procedures more clear.  I think it would save everyone involved a lot of time if I may contribute in this way.   Since I was able to get the VHD_WIMBOOT working, that would be where I would start.

 

Also, because the instructions weren't fully clear to me at first, it was a lot harder to start at the point I needed to start:   I already had a fully prepped VHD file that already had SVBUS/test mode/etc, so some time was spent trying to figure out where to start with that.     BTW:  It was the bottom of your PDF file that had the wimlib-clc application so it seemed to me that I should be able to use that to capture a wim file when using a provided .ini file.   Yes, after the fact there is some compatibility issue, but hindsight is always much more clear than trying to get through something the first time.

 

I am noticing that a ton of drivers are missing from my wim boot that were installed in my original VHD before the capture... graphics drivers, chipset drivers... many components lost their drivers in the WIM Capture / VHD Apply process.  I thought the drivers were supposed to be carried over?

[alacran]

This line on custom WimBootCompress.ini under [PrepopulateList]: \Windows\System32\drivers\*.sys should take care of copy all drivers on that location from the source wim to the same location on the VHD uncompressed, if all was done right. All drivers on this location are required to improve booting on several different PCs. IF the OS licence allows it, if not the OS will lose activation on different hardware.

Some OEM may have the bad idea to put drivers also under Programs or other locations during install, then in this case they should be compressed on the source wim and only be present as pointers (basically empty files with hard links to the wim) on the VHD.

 

If you want to verify your drivers located on \Windows\System32\drivers\*.sys are uncompressed see this: http://reboot.pro/to...e-8#entry212900 you will not need to check svbusx64.sys since it is fine as you can Ramboot, but make this check for all previously installed drivers that are malfunctioning.

[wimb]

Update though:  I was able to us VHD_WIMBOOT to capture a new wim file, created a new VHD with it, and applied the newly captured wim to that VHD. 

• Back to top

[alacran]

I think with a fast Micro-SD on the cellphone with 2 partitions, a big Fat-32 active partition (for usual user storage + just boot files) and an small NTFS partition, maybe 5 GB (just enought for the source .wim and the VHD) and connecting the phone by USB cable to the PC, it may be possible to Ramboot or fileboot the VHD on the PC, Of course it totaly depends of the options available on the phone for USB connection.

 

I already have in use a 32 GB Micro-SD + an USB adapter capable to do this. Also my phone is able to boot WinPE(s) and Linux Live(s) on the PC from the Micro SD on the smartphone.

 

My 10x64-WB.wim is 2.92 GB and my 10x64-WB.vhd.lz4 (for Ramboot) is only 128 MB so even 3.5 Gb is a good size on this case for the NTFS partition and having still about 1/2 GB free space on it.

 

alacran

[bin]

Hi Alacran,

 

It is kind of mind blowing for your great work. Although some users mentioned that was not a "full-loaded into RAM," as you have made it very clearly: "You may consider this as an Hybrid Ramboot: http://reboot.pro/to...d/#entry209518"

Since the WIM file had all static info, only reading, this will greatly increase the SSD drive life time.

 

As a newbie, what you had accomplished is really too challenging for me to following through, I think you may know that.

For the beginning, would you mind giving me a list of your NTFS partition root directory (your USB drive), I think both your .VHD and .WIM reside. You can use "Dir /a >ListHD01.txt" (under Command prompt, of course, you must have other great ways) and share with me, please keep all the info intact, especially the the date and time stamps, as we know the sizes do not change.

 

Warmly from Far Far Away!

 

Bin

 

 

[alacran]

@ bin

 

Thanks for your kind comments.

 

You are right, the VHD(s) are on the NTFS partition root and coupled WIM file(s) required (into Wimboot folder), the first primary active FAT-32 partition only require to have into it the Windows boot files and folders and grub4dos files/folders, BCD for Bios and BCD for UEFI are edited to locate and boot respective VHD(s) as Filedisk and grub4dos menu.lst let you Ramboot the selected VHD.

 

I understand the procedure on this thread is a little long to follow and make all entrances for VHD(s) on both BCDs and also on menu.lst, but our fellow wimb made a little program to do all this automatically for you, download also includes a pdf file with instructions, see: http://reboot.pro/to...-for-os-in-vhd/

 

In my NTFS partition I also have several WinPE files, MBR and UEFI bootables from boot manager BCDs, and also some Live Linux distros bootables using grub2 (called from the BCD), then as you can see partitions contents may vary a lot depending on user preferences.

 

You may also see UEFI_MULTI from wimb if you want to include WinPE files and some Live Linux distros on your USB drive, see: http://reboot.pro/fi...boot-usb-drive/

 

NOTE: It is better to run this programs under Win10

 

alacran