Hi Thomas! I said I'd get back to you *ages* ago. Sorry. :-/
On Wed, Feb 04, 2015 at 06:06:45PM +0100, Thomas Schmitt wrote: >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. Right. >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. OK. >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. Yup. I think that may be the problem I'm seeing in fact - we're using blkid etc. in debian-installer. >(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. Right, I don't think it's a major problem. >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. Right. I honestly don't think that's an issue to worry about. >------------------------------------------------------------- > >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.) Maybe not by us directly, but I think a fair number of Debian users like the ability to extend/modify images later and we have docs telling them how to add partitions once an image is written to a USB stick, for example. >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. Right. If you're still working on this I'd be very interested in testing it! -- Steve McIntyre, Cambridge, UK. st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150414135125.gc13...@einval.com