[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:
>> >>     -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.

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

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: