Re: arm64 and isohybrid
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. steve@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.
Reply to: