Hi, > >> -isohybrid-mbr null.mbr \ > >> -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \ > This may look valid, but gdisk and other code I've used don't cope > well with the PMBR being broken.
But that's not the fault of the NUL-bytes in null.mbr. The isohybbrid --gpt layout does not comply to UEF/GPT. Either there must be a "protective MBR" with a single partition of type 0xee, reaching from LBA 1 up to the backup GPT. In that case, GPT represents the partitions, which must not overlap. Or there may be a "Legacy MBR" with non-overlapping partitions of which one needs to have type 0xef and marks the EFI system partition with the FAT filesystem. When i plug the USB stick with the resulting image into my olde Linux, it probably uses the MBR to create a mountable /dev/sdb2 with efi/boot/bootaa64.efi in it. Further my Linux tolerates that partition 2 is located inside partition 1. That's the sin of overlapping. > >> -efi-boot-part --efi-boot-image \ > neither Gap0 nor Gap1 are usable That's a known disadvantage of grub-mkrescue partition layout. It complies to UEFI but the ISO can only be mounted by the base device. Especially udev and blkid do not handle this well. They happily let partition 1 inherit the filesystem identification of the base device. (On the other hand, who needs udev to find a CD or USB stick when the freshly booted kernel is the own well known one ? The list of possible device files is very finite.) > I guess I see what you've done, Urm. Blame Vladimir Serbinenko for that layout. He has good arguments for it. I have questioned it several times but he always staid firm. > However, this isn't helpful for the Debian installer > which now can't find the rest of the installer on any partition. Depending on udev early ? Your findings match the reasons why "Legacy MBR" won in my discussion of mini.iso https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776317#75 The waste of 1 MB for an appended external partition seems worthwhile. Stripping down my best proposal from BIOS+EFI to EFI-only: mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso # Get a copy of the El Torito EFI system partition cp /mnt/iso/boot/grub/efi.img arm64-efi.img # Append that copy as MBR partition of type 0xef xorriso -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -e boot/grub/efi.img -no-emul-boot \ -append_partition 2 0xef arm64-efi.img \ -partition_cyl_align all \ /mnt/iso This yields a non-overlapping UEFI compliant Legacy MBR MBR partition table: N Status Type Start Blocks MBR partition : 1 0x00 0x83 0 262144 MBR partition : 2 0x00 0xef 262144 2048 The NUL-bytes in the MBR are no problem because of UEF 2.4 5.2.1 "The boot code on the MBR is not executed by UEFI firmware." UEFI 2.4, table 13 shows that it needs at least one partition table entry and the magic 0x55 0xaa at bytes 510 and 511. The only effect of omitting option -isohybrid is that the type of partition 1 is 0x83 rather than 0x17. ------------------------------------------------------------- I am still hunting a bug in the pending changeset to enable production of a UEFI compliant protective MBR plus GPT layout with -append_partition. This would be the second best proposal from bug=776317#75. Disadvantages in comparison to above winner: You get a mountable ISO partition only if you use -partition_offset 16 The backup GPT makes mini.iso production postprocessing cumbersome. (This might be no problem with netinst.iso because no postprocessing shall happen in debian-cd anyway.) This proposal will look like the above one, with additional novel option -appended_part_as_gpt and partition offset 16: xorriso-1.3.9 -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -e boot/grub/efi.img -no-emul-boot \ -append_partition 2 0xef arm64-efi.img \ -appended_part_as_gpt \ -partition_offset 16 \ /mnt/iso will yield: ISO image size/512 : 264192 ... MBR partition table: N Status Type Start Blocks MBR partition : 1 0x00 0xee 1 265023 GPT : N Info GPT disk GUID : 95a21034fca5864bbf6738ff7f0c9a04 GPT entry array : 2 248 separated GPT lba range : 64 264960 265023 GPT partition name : 1 490053004f003900360036003000 GPT partname local : 1 ISO9660 GPT partition GUID : 1 95a21034fca5864bbf6438ff7f0c9a04 GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1000000000000001 GPT start and size : 1 64 264128 GPT partition name : 2 41007000700065006e006400650064003200 GPT partname local : 2 Appended2 GPT partition GUID : 2 95a21034fca5864bbf6538ff7f0c9a04 GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b GPT partition flags: 2 0x0000000000000000 GPT start and size : 2 264192 768 The bug i'm hunting does not affect the production of this ISO. So i can make one for you for testing, if you give me an opportunity to upload it somewhere. 130 MB. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3015954470108111...@scdbackup.webframe.org
