In fact, I was thinking this exact same thing prompted by your previous post : GPT does NOT restrict us from using raw code directly from sectors... And the gaps that are possible make it EASY to go even more crazy than possible in MBR disks in putting all sorts of code in all sorts of corners and gaps, while remaining COMPLETELY compliant.
BUT : There is a slightly better way! Use a BIOS Boot Partition and put whatever raw code you want there.... no interference of file systems, but ALSO sure that no random installer is going to assume your bootloader/ISO as free space Why WOULD anyone not want to use partitions instead of random sectors is beyond me. Just assign the right attributes and no OS will even show it.
I may be wrong, but you sound like believing that the "Bios Boot Partition" is *somehow* part of *a* "standard".
This is not exact.
The "Bios Boot Partition" is a "hack" done by the good GNU/GRUB2 guys, as a matter of fact it is a "proprietary" approach, that though (obviously) well devised and coded , is far form being properly documented:
https://www.gnu.org/...stallation.html
i.e. it is unsuitable to be even called a "proposed extension" to the "standard", they simply put together "a way out" for the GPT disks on BIOS and implemented it in their tool.
BTW, by design the "BIOS Boot Partition" does not even contain a filesystem, and as such it is not anything different from a "RAW" blocklist.
So, we have a de facto non-standard and the good Linux guys of the GNU/GRUB2 project put together a non-standard way to modify or "hack" it (for use with their own bootloader).
http://forums.fedora...ad.php?t=270586
http://forums.fedora...86&postcount=12
http://www.rodsbooks...sk/booting.html
BIOS-based computers, whether they use MBR or GPT, rely on a boot loader in the first sector of the disk to help get the computer booted. In fact, the first 440 bytes of the MBR data structure are devoted to this boot loader. DOS and Windows place a very simplistic boot loader in this space. Other OSes and third-party utilities enable placing more sophisticated boot loaders in the MBR, although these boot loaders usually rely on multiple stages—the boot loader code loads a secondary boot loader that's located elsewhere, and that boot loader may even load a third stage. In principle, these boot loaders can work just fine when the MBR is in fact a GPT protective MBR. In practice, the boot loader needs to be GPT-aware in order to work. The GRUB 2 boot loader, when used on a GPT disk, works best when you to have a BIOS Boot Partition (GPT fdisk code EF02) on the disk. Most boot loaders, including the patched versions of GRUB Legacy (version 0.97) that include GPT support, don't require a BIOS Boot Partition. If you do need it, the BIOS Boot Partition can be quite small—sometimes as small as 32 KiB, although I've seen reports that some configurations require more space than this—sometimes over 1 MiB. If you align your partitions to 1 MiB boundaries, 1 or 2 MiB is the logical size.
I feel free to invent my own non-standard ways to hack this non-standard .
Reality check
- BIOS reads the MBR (first absolute sector of the boot device)
- A "normal" MBR code does more or less the following:
- parses the partition table (that the defacto standard sets at offset 446 in the same sector, with 4 entries)
- checks that one (and one only) of the partition entries is Active (and primary)
- loads the corresponding partition bootsector
- do whatever the bootsector is supposed to do
more or less, the only "intelligence" the MBR code has is to recognize the (BTW simple) way partitions (please read as disk extensions) are mapped in the partition table and load the "right" address on disk.
What the "special" MBR for a "BIOS boot partition" does is instead:
- BIOS reads the MBR (first absolute sector of the boot device)
- the "special" MBR code does more or less the following:
- parses the partition table (that the defacto standard sets at offset 446 in the same sector, with 4 entries) to find the "EE protective" partition entry to find the start address of the "EFI PART" header or (OUTside of *any* standard) assumes that it is on LBA1, or (still OUTside of *any* standard) only parses the first of the four entries
- parses the "EFI PART" header to find the start address of the GPT partition table or (OUT of *any* standard) assumes that it is on LBA2
- finds the ID of "21686148-6449-6E6F-744E-656564454649" or "Hah!IdontNeedEFI" (which is ALSO OUTside of *any* standard) addresses (coded in complex way)
- loads the corresponding partition bootsector
- do whatever the bootsector is supposed to do <- the *whatever* is ONLY a specific loader (GRUB modified or GRUB2) that "knows" natively how to deal with the GPT partitioning scheme
To sum up, BIOS/MBR is simple (but limited in accessible size), EFI/GPT is not limited by size but is complex (and this extreme complexity led to a "standard" that is more than 2000 pages, that noone - seriously - can expect to actually fully comply with) and since the Intel geniuses that wrote the "standard" did not even think of a possibility to give BIOS accessibility, the good GRUB2 guys invented their own way.
More than a "proposed" standard, it is something that being overly (and needlessly) complex and having been "forced down the throat" of programmers/users led to a number of absolutely non-standard implementations, thus nullifying the whole validity of a "standard".
It is a situation not entirely different from the good ol' ISO9660 (or ECMA 119) for YEARS Bios and OS programmers have implemented non-standards around it, and some aspects (actually contained in the standard if read properly) have been misinterpreted till recently (though related a far less "important" matter), JFYI:
http://www.msfn.org/...ppy-emulation/
grub4dos - currently - knows nothing about GPT partitioning schemes, BUT is (IMHO) more flexible or, in any case, is a tool with which I am familiar and that allows me far more "freedom" than anything else.
Before or later the good grub4dos guys will have time (and will) to start experimenting with GPT but until then, we need to find other ways (and it is entirely possible that they will come out with another non-standard way to boot/load an OS on a GPT disk).
Though very improbable , it is also possible that the good GRUB2 guys (the ones that senselessly renamed GRUB to "GRUB legacy" and GRUB2 to "GRUB", thus creating among the biggest set of misunderstandings in computing history) will come to their senses and realize that grub4dos has tens of features in addition to their creature and they will start porting these features into GRUB2, but until then the U in GRand Unified Bootloader should more properly be used for GRand Unix Bootloader or GRand Unflexible Bootloader .
I am just putting together a different way to boot grub4dos from a GPT disk, it will take some time to be assembled, but I'll post it here as soon as I have a somewhat working prototype.
Wonko