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

Re: arm64 and isohybrid


i wrote back in february:
> > 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 proposal will look like
> >  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

Steve McIntyre wrote today:
> Right. If you're still working on this I'd be very interested in
> testing it!

Well, the changesets are committed, meanwhile.
But when i now tested above proposal (before bragging), it
turned out that production of a true "protective MBR" partition
table works only with isohybrid MBR. (I wonder what use case
i tested 10 weeks ago ...)

... Now above sketch works. The risk of regression by my
last minute change is low.
Nevertheless have a sharp look at i386 and amd64 results
when this version of xorriso produces them.

I did not make any Jigdo tests with -append_partition yet.

As said: -partition_offset 16 is essential for a
mountable GPT partition 1 with the ISO filesystem.


The current GNU xorriso development snapshot has the new
-as mkisofs option -appended_part_as_gpt, which lets the
ISO and the appended partition appear in GPT, with UEFI
compliant "protective" MBR.


  MD5 9577c69da2591c683ca2cf84d29e6191
  Version timestamp :  2015.04.13.172501

(I finely mistyped the date when faking the timestamp.)

We would have to change the CD FAQ about verification of
ISOs, because this advises to determine the exact amount
of image bytes from the ISO filesystem size.

But with above layout there is a neat disk-like situation
where the ISO filesystem ends before the EFI System Partition
begins. So one will rather have to checksum up to the
end of the second partition (as inquired by gdisk or alike).

Best would be if the Debian checksum lists would be
accompanied by length lists, which simply tell the
original size of the images by which the MD5s were computed.


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

As soon as the image is on a block device with inquirable
size, the partition editors should offer an option to move
the backup GPT to the end of the device. That would be the
first step before installing further partitions.

The docs need to be checked whether they are updated for GPT.

Have a nice day :)


Reply to: