Comment 8 for bug 1914587

Hi,

> 1. download [2]
> 2. xorriso -indev focal-live-server-ppc64el.iso -report_el_torito as_mkisofs

The adventure moves to the question how this ISO got its partition table.

  $ xorriso -indev focal-live-server-ppc64el.iso -report_system_area plain
  ...
  ISO image size/512 : 2440600
  ...
  MBR partition table: N Status Type Start Blocks
  MBR partition : 1 0x80 0x96 0 2440000
  MBR partition : 4 0x00 0x08 1718121313 1634545267
  ...

Partition editors see it even worse

  $ /sbin/fdisk -l focal-live-server-ppc64el.iso
  ...
  Device Boot Start End Sectors Size Id Type
  focal-live-server-ppc64el.iso1 * 0 2439999 2440000 1.2G 96 unknown
  focal-live-server-ppc64el.iso2 ? 31335 31335 0 0B 74 unknown
  focal-live-server-ppc64el.iso3 33554432 33554432 0 0B c9 unknown
  focal-live-server-ppc64el.iso4 1718121313 3352666579 1634545267 779.4G 8 AIX

Inquiring the Primary Volume Descriptor:

  $ xorriso -indev focal-live-server-ppc64el.iso -pvd_info
  ...
  App Id : GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM
  ...

Partition type 0x96 means CHRP. My cheat sheet says:

  CHRP is marked by an MBR partition entry of type 0x96 spanning the whole
  ISO 9660 image.

It seems that i interpreted this in the recognition code for CHRP as
"only one partition is allowed and that must be of type 0x96".
Possibly this is too narrow.

After overwriting the debris in the partition table by

  cp focal-live-server-ppc64el.iso test.iso
  dd if=/dev/zero conv=notrunc of=test.iso bs=1 count=48 seek=462

i get

  $ /sbin/fdisk -l test.iso
  ...
  Device Boot Start End Sectors Size Id Type
  test.iso1 * 0 2439999 2440000 1.2G 96 unknown
  ...

So xorriso's proposal mutates from copying the debris as appended partition
to producing a CHRP ISO:

  $ xorriso -indev test.iso -report_el_torito as_mkisofs
  ...
  -V 'Ubuntu-Server 20.04.2 LTS ppc64'
  --modification-date='2021020910083100'
  -chrp-boot-part
  -partition_cyl_align off
  -partition_offset 0
  --mbr-force-bootable
  -apm-block-size 512
  -G --interval:local_fs:0s-15s:zero_mbrpt,zero_apm:'test.iso'
  -iso_mbr_part_type 0x96
  ...

(-iso_mbr_part_type 0x96 is already impled by -chrp-boot-part.)

But this cannot replay completely what the focal-live-server-ppc64el.iso
image contains:

  $ xorriso -indev test.iso -report_system_area plain
  ...
  System area summary: MBR CHRP cyl-align-off APM
  ISO image size/512 : 2440600
  Partition offset : 0
  MBR heads per cyl : 0
  MBR secs per head : 0
  MBR partition table: N Status Type Start Blocks
  MBR partition : 1 0x80 0x96 0 2440000
  APM : N Info
  APM block size : 512
  APM gap fillers : 0
  APM partition name : 1 Ubuntu-Server 20.04.2 LTS ppc64
  APM partition type : 1 Apple_HFS
  APM start and size : 1 16 2439984

So here we obviously have an ISO/HFS hybrid, which explains why this ISO
was not made by xorriso. xorriso can do HFS+, thanks to a contribution
by Vladimir Serbinenko, but it cannot produce the older HFS.

-------------------------------------------------------------------------

For the make-edge-iso.sh this means that it has to use genisoimage and
cannot rely on xorriso's proposal of mkisofs-ish options, if the ppc64el
ISO was made with genisoimage.

I see in Debian debian-10.8.0-ppc64el-netinst.iso that it was made by
xorriso without any HFS.
An interesting question would be if there are ppc64el machines which need
HFS, and if so, if they all would work with HFS+, too.

-------------------------------------------------------------------------

For me it means that libisofs has to recognize CHRP if debris is present
and that xorriso needs to refrain from making mad xorriso proposals derived
from that debris.

Have a nice day :)

Thomas