Hi, Andrei Borzenkov wrote: > [proposal how to define synthetic partition entries] > Otherwise the most safe approach is probably based on design of mjg
... which does not comply to EFI specs. Its trick is that any misunderstanding by the firmware shall finally end up at the same address where the correct interpretation would end up. > MBR with single ESP > GPT with single ESP > APM with ESP, HFS+ I experimented with libisofs source and was able to produce this layout by replacing option -efi-boot-part --efi-boot-image by -append_partition 1 0xef ...disk.path.../efi.img where efi.img is the El Torito EFI boot image and ESP. (I will explain below why at least APM with HFS+ needs this copy for now.) Further i had to add after "-e /efi.img" this option: -isohybrid-gpt-basdat in order to trigger GPT production at all. The experimental behavior is enabled by macro definition export CPPFLAGS="-DLibisofs_mjg_boot_for_grub2" before the run of ./configure && make clean && make The xorriso run shown below then yields: System area summary: MBR GPT APM ISO image size/512 : 32204 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status Type Start Blocks MBR partition : 1 0x00 0xef 32204 5760 GPT : N Info GPT disk GUID : c21f87d201a3c947bc1900c6ccc80351 GPT entry array : 16 192 separated GPT lba range : 64 37966 38015 GPT partition name : 1 490053004f004800790062007200690064003100 GPT partname local : 1 ISOHybrid1 GPT partition GUID : 1 c21f87d201a3c947bc1b00c6ccc80351 GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1000000000000001 GPT start and size : 1 980 5760 GPT partition path : 1 /efi.img APM : N Info APM block size : 2048 APM gap fillers : 0 APM partition name : 1 HFSPLUS_Hybrid APM partition type : 1 Apple_HFS APM start and size : 1 84 7967 APM partition name : 2 Appended1 APM partition type : 2 Data APM start and size : 2 8051 1440 El Torito catalog : 229 1 El Torito cat path : /boot.catalog El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 230 El Torito boot img : 2 UEFI y none 0x0000 0x00 5760 245 El Torito img path : 1 /boot/grub/i386-pc/eltorito.img El Torito img opts : 1 boot-info-table grub2-boot-info El Torito img path : 2 /efi.img The experimental macros -DLibisofs_protective_msdos_plus_boot_dummY -DLibisofs_pmpbd_on_lba0 cause a dummy partition with boot flag to be added to MBR MBR partition table: N Status Type Start Blocks MBR partition : 1 0x00 0xef 32204 5760 MBR partition : 2 0x80 0x00 0 1 Also available with classic GRUB2 MBR partition 1 and boot flag (by -append_partition 2 ... rather than -append_partition 1 ...) Boot flag in MBR needs no special macros, because this case runs on the ticket of GRUB2 BIOS-only: MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0xcd 1 32203 MBR partition : 2 0x00 0xef 32204 5760 Fashionable this spring: Mountable partition 1 with boot flag (by -append_partition 2 ... and by omitting --protective-msdos-label) MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0x83 0 32204 MBR partition : 2 0x00 0xef 32204 5760 Before i replace the macros by run-time options i would like to get feedback whether this setup and some of its variations offer any advantage over the normal grub-mkrescue output. (Creepy code changes: http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1299/libisofs/system_area.c http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1299/libisofs/make_isohybrid_mbr.c ) --------------------------------------------------------------------- A new GNU xorriso development tarball is uploaded http://www.gnu.org/software/xorriso/xorriso-1.4.3.tar.gz MD5 eea74ebbf79a884a2943f4f63844d593 Version timestamp : 2015.12.27.150821 Run tests by mounting an EFI+BIOS grub-mkrescue ISO as "/mnt/iso", and copying the first 512 bytes of such an ISO to file "minimal-grub2.mbr". Obtain the ISO modification date by ISO=minimal-grub2.iso MOD_DATE=$(xorriso -indev "$ISO" -pvd_info 2>/dev/null | \ grep '^Modif\. Time :' | sed -e 's/^Modif. Time : //') Then run with the experimental xorriso binary ...absolute.path.../xorriso/xorriso -as mkisofs \ -o minimal-grub2-repacked.iso \ -r -no-pad \ --modification-date=$MOD_DATE \ --grub2-mbr minimal-grub2.mbr \ -c '/boot.catalog' \ -b '/boot/grub/i386-pc/eltorito.img' \ -no-emul-boot -boot-load-size 4 -boot-info-table \ --grub2-boot-info \ -eltorito-alt-boot \ -e '/efi.img' \ -no-emul-boot -isohybrid-gpt-basdat \ -hfsplus \ -apm-block-size 2048 \ -hfsplus-file-creator-type chrp tbxj \ /System/Library/CoreServices/.disk_label \ -hfs-bless-by intel_bootfile /System/Library/CoreServices/boot.efi \ \ -append_partition 1 0xef /mnt/iso/efi.img \ --protective-msdos-label \ \ /mnt/iso Play with the hindmost options to achieve different MBR partition tables. --------------------------------------------------------------------- Perky comments about this variation of the mjg layout: > MBR with single ESP This will suffer from the ambiguity of the storage device, as i had to learn from you. USB stick typically has 512 bytes per block, CD/DVD/BD bear 2048. A 4 KB sector disk might be encountered, too. (GRUB2 could recognize its own ISO 9660 pseudo APM Block0 MBR hybrid and then assume block size 512. In APM, the start bytes 45 52 08 00 eb 02 ff ff ... mean: APM Block0 magic number, block size 2048, device size 3,942,842,367 blocks. Quite improbable that any real APM has these values.) > GPT with single ESP This should not be recognized by a standards compliant EFI. > APM with ESP, HFS+ The Block0 of the GRUB2 MBR is quite a fake: Fantasy device size. Fields filled with x86 code for BIOS USB stick booting. Further, the El Torito boot images are inside the HFS+ filesystem. So for having ESP and HFS+ in APM and avoiding partition overlapping, we need an extra ESP like in my MBR-only EFI favorite. mjg's HFS+ in Fedora LiveCD is a rather small image file inside the ISO, not an alternative superblock and file tree which leads to the same files as the ISO. Debian has no HFS+. (Only a remnant APM option with its xorriso run.) This is totally contrary to Vladimir's ideas from 3.5 years ago. mjg's layout has been used by several large Linux distros in the last about 4 years, though. Shall this become an alternative to the current layout of grub-mkrescue ? (Can we then have my MBR-only favorite, too ?) --------------------------------------------------------------------- Have a nice day :) Thomas _______________________________________________ Bug-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-grub
