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