Dear Wonko,
thanks for the prompt reply, I feel a little discouraged having read the long thread by Milindsmart and Sha0.
Very interesting indeed, but I'm not skilled enough to even start experimenting (it would take me endless time).
Besides the deception, every time I get a reply from you I have to study (and learn) something new
I'm sure someday someone here @ reboot.pro will find a way to boot bios PCs from gpt!
Have a nice day,
V.
Will try to, thanks, however trying to make a "XP Kansas City Shuffle" should not be particularly difficult using an "external kicker", and it is documented, the (if needed) addition of the "special" MBR code would be only a "perfectionist touch" to make it completely self-standing.
PS I'm trying to understand more about hybrid mbrs. What are the suggested tools under windows to create a gpt/mbr hybrid disk?
Is it really risky as I'm reading here and there?
Naah it is not "dangerous" in itself, the issue(s) only revolve around its compatibility against a number of (dual, triple or however concurringly) booting Operating Systems and - much more than that - the compatibility with tools that you may use to fiddle with the MBR and the partitioning table.
The "reference tool (and documentation) is still GDISK:
http://www.rodsbooks...isk/hybrid.htmlbut again your actual mileage may vary, the scope of the mentioned thread was (is) to have something that allows a Hybrid MBR WITHOUT having an Hybrid MBR
, i.e. allowing to have BIOS bootable GPT disks in such a way that a GPT enabled OS can boot from them nonetheless BUT that will appear (when connected to a "pure" UEFI system) as a "normal" GPT disk.
The "trick"(s):
http://reboot.pro/to...e-9#entry193659http://reboot.pro/to...able-usb-drive/http://reboot.pro/to...-11#entry197690and the "final" method:
http://reboot.pro/to...-14#entry198148work fine because the supported OS's already "understand" GPT, all in all what they do is simply to load grub4dos, which then can do *anything*.
So - with very little risk - we could have for the XP an added partition entry written "on the fly", and remove it from the partition table afterwards (leaving *only* the 0xEE partition), of course this only applies to BIOS and to <2.2 Tb volume.
In theory, once a volume is mounted, it is mounted, and you can remove from the MBR partition table the pointers to it, UNLESS you fiddle with programs that *need* those pointers, but in the worst case, at the most you would need to re-boot to grub4dos to reset the MBR partition table before booting to "other OS".
But in your specific case, you are attempting to do something different, I believe
, i.e. booting an XP (in VHD) residing on a GPT disk through a UEFI (or UEFI/CSM), this is IMHO the point where there may be flaws, as your specific UEFI implementation (ant the way the CSM module is "triggered") may make a difference.
I love standards, there are so many of them
, but in the case of UEFI it is a (stupid) non-standard described in over 2200 (badly written, BTW) documentation pages and noone actually fully respects it, not the good Linux guys, not the good MS guys, not the good Apple guys (which I believe invented their own sub-standard
) and SURELY NOT the UEFI/BIOS vendors (or if they do, the actual hardware manufacturers simply love to botch the original implementations by removing options/modifying them), hence the need to do specific experiments.
Wonko