So, I'm trying to come up with a solution to a particular issue. Windows 10 is currently booting in legacy/CSM compatibility mode on a Samsung SSD, with an MBR partition table. I would like to use BestCrypt Volume Encryption to encrypt Windows. And it works fine, that isn't the problem. But in legacy mode, BCVE installs boot code to the MBR of the drive. Entirely reasonable, how else do you expect to authenticate and get in? I can directly chainload the MBR of the drive with GRUB4DOS, as long as G4D is installed to the MBR of another drive. And I can make a copy of BCVE's MBR and tell G4D to chainload that file, then just authenticate and I'm in Windows.
BCVE has the option to move a volume's encryption key(s) to external storage, either a flash drive, ISO, or network boot. Which allows me to boot from an external device. With this setup, the presence of BCVE's MBR on an internal drive shouldnt be necessary. I posted the following topic in Jetico support forum:
A company engineer confirmed that BCVE will enforce the presence of its' MBR on the drive, even you have have configured the software to otherwise boot from external media. You can overwrite BCVE MBR when not in Windows, but as soon as you are back in it will detect the change and restore its' boot code. Even with a MBR write-blocking driver like MBRFilter, it seems not possible to prevent BCVE from restoring its' code. And, even if you could, it will still nag on every boot about the MBR having been changed by an unknown program.
In my tests I did notice something that I overlooked before, see the following screenshot:
On the first disk (disk 0), it shows that the C drive is the Boot partition (because it's where the OS is), not marked as active, and contains no boot files. On the 2nd disk (disk 1), there is a System Reserved partition, which is marked as active, contains boot files, and is called the System partition by Windows. I did not create this partition setup, it just happened that when 10 was installed, it chose to place C drive onto disk 0 and System Reserved onto disk 1. I discovered it after the fact and decided it wasn't worth bothering with, since it wouldn't affect my ability to create new partitions, install new OSes, etc. Getting to the point, in this setup BCVE installs its' MBR code to disk 1 rather than disk 0. So, it doesn't necessarily care where the C drive lives, its' real concern is the location of the volume that contains boot files (System). And that in turn will determine what drive the MBR code is installed to.
However, this means that I still have to give BCVE control of the MBR of one drive or another (whatever it is), and I much prefer to be in control of what boot code my drives have. I may want G4D on disk 0, GRUB2 on disk 1, and Clover on disk 2.
So, I would like to try something new but am not sure how to proceed:
Windows 10 installed into a "real" partition on any drive (preferably disk 0 since it is the fastest SSD I have), I don't think it matters whether the partition is primary or logical
Create a small VHD disk, up to 1GB in size. Create a primary partition on that, mark it as active, and install default Windows 10 MBR code into sector 0 of that VHD. Then, find a way to chainload that entire VHD with GRUB4DOS. Once in Windows, I can install BCVE and try to encrypt, to see how BCVE reacts to System Reserved being in a VHD. If it works then it *SHOULD* install its' boot code into the VHD's MBR, which should be trivial to load with G4D. Then I can have whatever loader code I want on whatever drive I want, and BCVE can enforce its' MBR code onto a virtual disk that I don't care about, because its' only purpose will be to house BCVE's MBR and 10's boot files. As for the location of the VHD itself, it will be on a bigger unencrypted NTFS partition that will serve other purposes ( I could probably make it FAT32 so it could also be used for UEFI booting, but it would be quite large for that purpose).
I just need instructions on how to create this setup. Another concern will be, whether encrypted or not, will the VHD remain mounted after Windows is booted? It is, after all, where the boot files live, so I'm sure Windows will try to maintain access to it while the system is in operation. And Windows can natively mount a VHD without 3rd-party drivers, no issue. If everything works as expected, then hibernation should, as well as updates. With none of the negative side effects discussed in the 'Hack Bootmgr to boot Windows in BIOS to GPT' thread.
Another option is to do a UEFI on MBR setup, which I've tested, BCVE works fine in this setup once a few quirks are worked out. Install and boot encrypted Windows in UEFI, while booting other OSes in legacy mode.
Or, I could just do a standard UEFI on GPT, but I'm not a 'standard' type of guy. If I wanted to boot my OSes in the 'normal' way then there is no need for me to post on this forum, there are other places for that. BIOS on GPT would also work, but may wreak havoc if I intend to encrypt, I'm not sure how BCVE would react to such a setup, and prefer not to test that if it isn't necessary. Linux booted in legacy mode on GPT would present no real issues, I have done it and it works fine. It is always Windows being the wild card that throws a monkey wrench into the mix.