Hi, i wrote: > > promised by UEFI 2.4,
Andrei Borzenkov wrote: > "promised" is encouraging :) More we can't get with all the implementations out there. > GPT starts at LBA 1. So we can deduce block size used to create this GPT > by checking location of GPT header. Ah. The first "EFI PART\000\000\001\000" wins. > But I am not aware of anyone else using the same technique. Everyone > else just assumes GPT matches block size device reports. I would have been in the dumbnut group who fixely assumes 512. Only good that i do not really interpret existing GPT on hard disk but only analyse those from xorriso and alike. (A new item on my todo list: Be as smart as GRUB2) > I do not think any BIOS works in 4Kn mode, That means me dumbnut has company. (Also in HFS implementation of Linux.) i wrote to Alexander: > >>> Nevertheless, your overlapping layout would have the appeal of > >>> giving a mountable partition: > >>> [...] > >>> It would travel on the ticket that EFI shall ignore MBR partition > >>> type 0x00. Andrei wrote: > Please do not confuse MBR support and protective MBR definition. I > replied in context of protective MBR, But my proposal is in the context of Legacy Master Boot Record. Alexander's tests with other partitionings had a 0xee partition, which i deem wrong like you do. But with 0x00 and 0xef it should be covered by UEFI 2.4: MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0x00 0 32804 MBR partition : 2 0x00 0xef 336 5760 > > The question is how far this ignoring goes. > > ishoybrid+GRUB2 as of mjg hopes for effective non-existence > > as far as EFI and its do-not-overlap demand is concerned. > Not sure I can parse this sentence :) Matthew Garrett obviously had a longer fight with several boot firmwares to get the Fedora hybrid ISO workable with all intended machines. He reported success in: http://mjg59.dreamwidth.org/11285.html "[...] if there's an MBR with overlapping partitions, the entire MBR will be ignored. Fortunately, [...] it turns out that partitions of type 0 are ignored when performing this check. So, there's a partition of type 0." This hybrid consists of SYSLINUX for BIOS, GRUB2 for EFI, and a small HFS+ image for some Macs. The partition with type 0x00 covers the whole ISO filesystem. Matthew's producer implementation is in tool isohybrid.c of SYSLINUX. I adopted that layout in xorriso for Debian's early amd64 EFI experiments (without HFS+). Some other distros joined. debian-8.1.0-amd64-netinst.iso : MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0x00 0 505856 MBR partition : 2 0x00 0xef 3980 832 plus GPT and APM. (APM useless because no HFS+ tree is present.) Vladimir for GRUB2 insisted in a layout without overlapping partitions. That's why grub-mkrescue produces its BIOS+EFI+Mac hybrid ISO the way of Alexander's minimal.iso: Protective GPT MBR, real info in GPT (and APM if present). Drawback is that no partition offers the ISO for mounting. > The question is how partition layout should look like. As said, my favorite is a legacy MBR with no overlapping. For the sake of a mountable ISO partition, i propose to waste space by appending a copy of the EFI system partition after the ISO. MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0x83 0 32804 MBR partition : 2 0x00 0xef 32804 5760 No GPT. With APM, if HFS+ gets produced. Debian's EFI partition shows that one can make it very small. Its 1 MB size is mostly due to partition alignment prescriptions of ISOLINUX. I will next try to repack Alexander's minimal.iso to this layout and ask him to do the same and test with his machine zoo. (Crossing fingers that xorriso can do without code change. Maybe the bootability flag needs to be set afterwards.) Have a nice day :) Thomas _______________________________________________ Bug-grub mailing list Bug-grub@gnu.org https://lists.gnu.org/mailman/listinfo/bug-grub