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

Re: arm64 and isohybrid

On Tue, Apr 14, 2015 at 08:41:35PM +0200, Thomas Schmitt wrote:
>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.


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


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: