Re: arm64 and isohybrid
On Tue, Apr 14, 2015 at 08:41:35PM +0200, Thomas Schmitt wrote:
>Hi,
>
>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.
>
> http://www.gnu.org/software/xorriso/xorriso-1.3.9.tar.gz
>
> MD5 9577c69da2591c683ca2cf84d29e6191
> Version timestamp : 2015.04.13.172501
OK, I've just built and done a very quick test with an arm64 netinst
build. This gives me the following:
$ gdisk -l iso/tmp.iso
GPT fdisk (gdisk) version 0.8.5
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk iso/tmp.iso: 313408 sectors, 153.0 MiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2573D2EC-456B-4D75-A0F3-DA94B2713406
Partition table holds up to 248 entries
First usable sector is 64, last usable sector is 313344
Partitions will be aligned on 64-sector boundaries
Total free space is 1 sectors (512 bytes)
Number Start (sector) End (sector) Size Code Name
1 64 311295 152.0 MiB 0700 ISO9660
2 311296 313343 1024.0 KiB EF00 Appended2
3 313344 313343 0 bytes 0700 Gap1
(using the command line options:
~93sam/xorriso-1.3.9/xorriso/xorriso -as mkisofs -r \
-checksum_algorithm_iso md5,sha1,sha256,sha512 \
-V 'Debian testing arm64 1' -o tmp.iso \
($jigdo_opts) \
-J -joliet-long -cache-inodes -e boot/grub/efi.img -no-emul-boot \
-append_partition 2 0xef CD1/boot/grub/efi.img \
-partition_cyl_align all \
-appended_part_as_gpt -partition_offset 16 CD1)
I've tried both with and without the "-partition_offset all" and it
(obviously) affects the partition alignments and the overall image
size, but otherwise the images produced *look* ok apart from the
odd-looking zero-sized 3rd partition. It's a cosmetic issue only, but
I'm curious why it's there. :-)
>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.
Ah, yes.
>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.
Maybe, yes.
<snip>
>> 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.
ACK.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
as meaning someone who's only ever written one device driver." -- Daniel Pead
Reply to: