Chainload Windows 10 Enterprise VHD with GRUB2/GRUB4DOS, located in an EXT4 partition?

I am commencing on a Linux-only setup, and I'm going to install 10 in a fixed-size VHD. I want to get to learn Linux more in-depth, but still need Windows for a few things, like flashing firmware onto Android devices, 3D graphics modeling, etc.

 

I am planning to place this VHD in my Fedora's /home partition, which will have an EXT4 filesystem. But I'm not sure if either G4D or GRUB2 can chainload a VHD located within an EXT4 partition. My preference is to use GRUB2 for this. I had wanted to try VBoot, but saw that it is relatively unsupported trialware, and cant be chainloaded from another bootloader. Do I need to place my VHD within an NTFS partition instead? My Windows boot files (bootmgr and BCD) will be located in a small System Reserved partition within the VHD itself. My current booting mode is BIOS/MBR.

 

Thanks!

 

Edit: I would also like to make it clear that GRUB2 will be in my laptop's MBR. I would like it to either:

1. Directly chainload the VHD located in the EXT4 partition

or

2 (less preferable). Chainload G4D, which will then find my VHD and load it.

Hmmm.

If I were you I would be much more concerned about whether the Windows driver that should load the actual .vhd can access that EXT4 volume and mount the VHD image.

Windows has no "native" support for EXTn filesystems, and it is unlikely (though possible) that any "third party" EXTn FS driver is usable/used in the very early part of booting.

Surely you will have an easier life if you put the .vhd on a NTFS partition (but then in your described setup you could install the windows directly to the NTFS volume and avoid the VHD altogether).

 

As a side note, and JFYI:
https://msopentech.c...x-development/#

https://gallery.tech...ageps1-0fe23a8f

The documentation and "features" are a bit (actually more than a bit) messed up, the thingy seemingly worked nicely when I tested it, but you will need anyway to check the reports as a few lines in the script might need to be changed, depending on your source.

 

Wonko

So this is a bad idea? There is a driver called ext2fsd, but I don't think it can load in the early boot stages. I didn't think it mattered what kind of partition the VHD is on, as long as the 10 volume *within* the VHD can be accessed. Windows can't be trusted to handle Linux volumes. Another issue is that my Linuxes are already installed and confugured, would rather avoid repartitioning.

So this is a bad idea? There is a driver called ext2fsd, but I don't think it can load in the early boot stages. I didn't think it mattered what kind of partition the VHD is on, as long as the 10 volume *within* the VHD can be accessed. Windows can't be trusted to handle Linux volumes. Another issue is that my Linuxes are already installed and confugured, would rather avoid repartitioning.

Not necessarily a bad idea in itself, simply something that personally I wouldn't do on a "production" and "configured" system, a nice experiment to verify the level of integration of the one or the other EXTn FS driver with the boot time VHD/VHDX driver, but that I would carry on a "test" system.

 

I would trust much more gparted (say) to shrink an existing partition and creating a new one for the new Windows install.

 

But then I tend to apply Occam's Razor whenever possible as IMHO making things complex without a real reason (while sometimes fun ) is more likely to result in issues.

 

Wonko

Well, the fact remains that I still need to access Windows every now and then, but don't want to install it into a physical partition on my drive. I guess I'll have to look into creating a portable Windows (perhaps in another thread, so I can take this in a slightly different direction). I know Easy2Boot can boot a VHD/VHDX, I have a spare 256GB Patriot Supersonic USB 3.1 flash drive I can use for this.

 

But I do think that testing the various EXT drivers with the VHD mounting mechanism would be an interesting project that might also benefit others (not that I would really have any inclination to share my results in the event of success, I'm just a selfish bastard like that).

 

How can I go about extracting the drivers from the handful of solutions available? Something like 7-Zip/WinRAR/Universal Extractor/etc would work? Or it is better to install the solutions and manually copy over the driver files (if they can be found)? Once obtained, how would I go about testing?

 

I sometimes don't mind using my everyday systems for testing, you'll never learn if you don't test in day to day scenarios. What works in an isolated test environment may not always work the same used on a "live" system.

 

Thanks!

Well, those drivers are usually in archive/installers accessible through 7-zip, and at the very minimum it should be just a .sys and a .inf, the point is the level of integration they have in the OS and the compatibility with Windows 10, as I see it, I would first try with the IFS:
http://www.fs-driver.org/index.html
If I recall correctly (but cannot really say for sure) Ext2fsd is not "fully "integrated" and needs a mounter/helper executable and the Paragon on is based on Dokan, i.e. it has an "added layer".
BTW I seem to remember having read - but never found a real confirmation for it - that Windows to go has some built in access to EXTn volumes, you may also want to try that.

YMMGV.


Wonko

I'm none too happy about trying the IFS driver, since it can't access EXT4, and EXT3 volumes are accessed without journaling benefits or maintaining access rights. I think I'll try the Ext2FSD drivers first. Maybe they can be accessed without the GUI, via plain text config files. I also prefer that my /home partition use the latest EXT available (4).

I'm about to scrap my ASUS ultrabook since I'm about to receive a package (Sager gaming powerhouse notebook). In the short term I plan to dual boot Windows and Linux on that PC, but longer-term I'm transitioning to running Linux as my main OS. I'll be running Windows in a hypervisor-like environment. With a bit of complexity i can pass-through one of the NVIDIA graphics cards to the hypervisor, while giving Linux exclusive control of the other card. With this setup you can get near-native performance in games without actually dual-booting. I trust Linux to manage a Windows VM, but not the other way around. I just want to remain immersed in a Linux environment without constantly having to dual-boot to play games. I'd rather avoid WINE because it's not mature enough to run many of the latest AAA titles. Another advantage of booting from a containerized image is that I can keep the 2 OSes nicely isolated from each other (in part to prevent Windows from mucking around where it shouldn't, like Linux's stuff), and Linux remains in control.

 

This brings me back around to the issue of either booting Windows in a VHD or raw disk image located on a ext*(4 preferred) partition. If I have to create an NTFS volume, then I might as well dual boot, because this basically defeats the purpose of what I'm trying to do, since the volume Windows' image is contained in isn't ext*, and it's easier to just natively boot Windows on NTFS anyway.

 

I realize that Windows expects its' VHD/disk image to be on NTFS, because when real mode passes into protected mode it will try to rediscover the image as well as the volume that image is located on, and if it finds an unrecognized FS then it will panic. I've also read about kernel mode and user mode drivers, I'm guessing that for Windows to boot from an image on ext*, there will need to be a kernel mode driver that loads early enough in the booting process. I'm not sure if Ext2Fsd fits the bill, since it seems to be partly dependent on its' GUI and services, etc, although it does seem to be the best option overall.

 

I'm looking into the IFS option, since it provides a kernel mode driver for ext2/3 but not ext4, although this doesn't necessarily mean things will work out.

 

A few questions:

1. Does the ext* partition (itself, not Windows' image) need to be writable, or is read-only good enough? The disk image itself does of course have to be writable for Windows to run from it, but the underlying partition shouldn't need to be writable if the disk image is of a fixed size, already committed to disk, and preferably contains no Windows boot files. IFS provides read and write access but only for ext2/3, not ext4.

 

2. How would I go about integrating the IFS driver into the booting procedure? Do I need to embed it into a WIM then use that WIM to install Windows? Or does the driver only need to be integrated into an already installed Windows? How can I ensure and check that the booting process is making at least trying to make use of the driver, and that ext* partitions/volumes are accessible during this time window?

 

Thanks!

As hinted before, it seems like Windows 10 "to Go" has support for EXT3/4, but I doubt that it extends to booting:

https://www.tenforum...ile-system.html

 

*somehow* you need a "whole booting chain" BEFORE the kernel is loaded, and this involves BOOTMGR (or the bootmgr.efi), and access to the \boot\BCD, which can be made using a FAT partition/volume (which is anyway needed in EFI, I believe, unless an EFI driver like the one Akeo made for NTFS exists for ext2/3/4) and anyway the bootmgr (or bootmgr.efi) needs somehow to be able to access the Windows System folder (and Winload.exe or similar).

 

Wonko