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:
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.