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

Re: arm64 and isohybrid


> >>     -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 
The waste of 1 MB for an appended external partition seems

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 \

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 \

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


Reply to: