On 07/02/2010 02:13 AM, Elliott, Robert (Server Storage) wrote: >>> In the UEFI Working Group (which defines GPT) and the T13 (ATA) >>> standards bodies, we defined a slightly different method: the GPT >>> partition record now includes a Legacy BIOS Bootable bit that can be >>> set for a partition like the BIOS boot partition, The algorithm is >>> documented in T13 EDD-4 revision 2 and later (see >>> http://t13.org/Documents/MinutesDefault.aspx?DocumentType=4&DocumentSta >>> ge=1). >>> >>> >>> >> At last. It's refreshing from the usual lie that you need EFI to boot >> from GPT-partitioned disk. >> But I don't see the need to standartise the interface between MBR code >> and the rest. Standartisation is good only for interoperability between >> different software. But in this case both parts are from the same >> bootloader so it will only reduce flexibility. >> > The "handoff" contents are defined to better support MBRs and VBRs that > aren't tightly coupled. Why such schemes are of concern? Someone who wrote the whole bootloader can write 440 bytes more and doesn't need another company for it. If it's for loading one bootloader from another multiboot is much more appropriate. GRUB tries to go away from chainloading as far as possible. It's now still used only for windows but even this will change soon with "ntldr" command which is able to load ntldr or bootmgr file. > The VBR can ignore the data structure if it > doesn't need it. Syslinux felt it helpful to support legacy VBRs > (particularly when they are located < 2.2 TB). > > Unless VBR itself is designed for this you can't load it this way. > > >> When we added GPT support virtually unlimited embedding zone was the >> great plus. Switching to msdos-like scheme would be a huge step >> backwards (especially that you have no MBR gap). It's a repetion of old >> mistakes under new sauce. MSDOS scheme already forced anti-patterns and >> any new scheme must be based on saner pattern. >> > What's an "anti-pattern"? > > A design decision to avoid. > The change here would be that the grub MBR code would locate the > grub VBR code (the BIOS Boot Partition) by looking for the Legacy BIOS > Bootable bit in the GPT partition record, rather than have hardcode > the LBA at some offset in the MBR. > > This scheme already showed its flaws in the past. Multibooting by changing this flag is impratical to say the least and over-reliance on this flag to locate boot partition made it that bootloader must set this flag before chainloading, so no bootloader other than microsoft one implements msdos scheme. You would need a flag per bootloader. It boils back to GUID. Using GUID in GPT to locate the embedded zone would be good but it has nothing to do with this standard. Robert made some work in this direction but never finished (he wrote MBR but not some required changes to diskboot.img) and nobody picked up his work. > Although all legacy BIOS boots will fail if LBA 0 goes bad, this allows > inclusion of more than one legacy bootable partition on the disk to > tolerate a failure in those LBAs. Bad sectors are pretty rare and overwritten boot partition would need manual clear of bootale flag which requires some environment which would be able to just reinstall bootloader. > It would also tolerate failures of > the GPT region (since there's a backup GPT at the end of the disk > that can be used). > > Whether or not use GPT to locate embed partition would be a separate thread and as I said using GUID would be good but noone ever completed it for GRUB.
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
