Re: [Bug-xorriso] xorriso and Fedora livecd-tools

[Thomas Schmitt]

Hi,

mail directly to me is fully ok, too. It merely depends on the wish of
the sender whether to have it discussed in private or in public.
Since you sent yours again to the bug-xorriso list, i assume that public
discussion is ok. 


Neal Gompa wrote:
> As some of you may or may not be aware, the Fedora tooling
> for creating live and installer media leverages cdrkit, specifically
> genisoimage, and even more specifically, a patched version of
> genisoimage.

I believe to know that Fedora invented genisoimage option -e.

> I want to move from genisoimage to xorrisofs,

Let's see how far we get.


> -hide-joliet-trans-tbl

xorrisofs does not offer option -T for generating TRANS.TBL files and thus
needs not to suppress that generation for Joliet.

> "-T" generates a translation table[4]. Again, I'm not sure how
> important this is...

It is a human readable hint how the input files were named before they
were mangled by the ISO 9660 name rules. Needed only if the reading system
understands neither Rock Ridge nor Joliet.
A line in the TRANS.TBL file of a directory looks like
  F FIGEDIT.;1                            Figedit
and tells that ISO 9660 file "FIGEDIT.;1" originally had the name "Figedit".
Both, Rock Ridge and Joliet show that original name (if not explicitely
altered by program options).

Hardly anybody will miss TRANS.TBL files.


> The thing I
> was more concerned about was the drastic loss of options for setting
> up PowerPC images.
>  "-hfs" , "-part", "-map",

This might be a problem. If the intended reading computers need HFS without
tolerating the "+" aspect, then you need to stay with genisoimage.
The "powerpc" arch of Debian is the only one which still gets built by
genisoimage there.

> "-hfsplus"

This should serve the x86 systems which Fedora Live addresses by its
third El Torito boot image (possibly with path /isolinux/macboot.img).
See http://mjg59.dreamwidth.org/11285.html

xorrisofs option -hfsplus is used by grub-mkrescue for x86.


> I had to drop all the UDF support, which wasn't good.

That's another hard problem. No UDF in libisofs.


> there are downstream consumers of livecd-tools who make
> large images that require UDF

How that ? Do they need to read files of 4 GiB or more on Solaris or
one of the BSDs ?


> Is UDF support in the
> cards in the near future for xorriso/xorrisofs

Surely not near, although i made friends with an UDF expert recently.


> Also, the previous developer of livecd-tools indicated that there was
> a problem with producing hybrid ISOs that support more than one EFI
> image[6].

I know that case. You can easily work around this limitation of SYSLINUX
postprocessor "isohybrid" by letting xorriso do the isohybridization.

The xorriso images with one El Torito boot image for BIOS and two for EFI
are not digestible for the hasty changes which Matthew J. Garret did to
isohybrid.c for its option --uefi. genisoimage -e produces a new
El Torito Catalog section for the second EFI boot image, libisofs puts
it into the same section as the first EFI boot image.
isohybrid.c wrongly assumes a 1:1 relation between catalog section and
boot image.

My regression test uses these xorrisofs options to rebuild 
Fedora-Live-Xfce-x86_64-rawhide-20150704.iso with equivalent boot
equipment:

  -V 'Fedora-Live-Xfce-x86_64-rawhide-'
  --modification-date='2015070415073700'
  -isohybrid-mbr 
--interval:local_fs:0s-15s:zero_mbrpt,zero_gpt,zero_apm:'/dvdbuffer/Fedora-Live-Xfce-x86_64-rawhide-20150704.iso'
  -partition_cyl_align on -partition_offset 0
  -partition_hd_cyl 64 -partition_sec_hd 32
  -apm-block-size 2048
  -iso_mbr_part_type 0x00
  -c '/isolinux/boot.cat'
  -b '/isolinux/isolinux.bin'
     -no-emul-boot -boot-load-size 4 -boot-info-table
  -eltorito-alt-boot
  -e '/isolinux/efiboot.img'
     -no-emul-boot -boot-load-size 10136
     -isohybrid-gpt-basdat -isohybrid-apm-hfsplus
  -eltorito-alt-boot
  -e '/isolinux/macboot.img'
     -no-emul-boot -boot-load-size 40576
     -isohybrid-gpt-hfsplus -isohybrid-apm-hfsplus
  /mnt/iso

The original ISO is mounted at /mnt/iso.

The lengthy parameter
  
--interval:local_fs:0s-15s:zero_mbrpt,zero_gpt,zero_apm:'/dvdbuffer/Fedora-Live-Xfce-x86_64-rawhide-20150704.iso'
cuts out the System Area from the original ISO.
If you produce new ISOs from a local SYSLINUX installation, you will use its
MBR template file isohdpfx.bin . Try whether you have on your disk
  /usr/share/syslinux/isohdpfx.bin

Differences between original Fedora ISO and repacked ISO are minor:
- The number of GPT partition slots grew from 46 to 64.
- The repacked ISO marked its GPT partitions as "System Partition" and
  "read-only".
One has to keep in mind that the GPT of Matthew J. Garret's layout is
simply invalid, because it is not announced properly by the MBR partition
table with a single partition of type 0xee.
Any specs compliant EFI will use the MBR partition of type 0xef and ignore
the EFI partition entry in the GPT.

---------

Summary:

- I am quite optimistic about boot equipment for x86 and ARM.

- HFS without "+" for PowerPC will probably never happen unless somebody
  submits code with acceptable license (LGPL2 although releases will stay
  under GPLv2+ in foreseeable future).
  The code would have to already fit well into libisofs. If there is
  sincere interest, i could look for places where to plug in its ABI.

- UDF for DVD video might happen if:
  - i get example video DVDs
  - there are testers with consumer video players (or i get donated some)
  - we find a drug cocktail which gets some programmer motivated to read
    ECMA-167 and UDF specs.
    But as said, i recently had contact with Steve Kenton who has a share
    in udftools. So maybe the drugs can be kept harmless and legal.

  I do not see much reason for UDF iother than DVD video. Solaris and BSD
  should rather repair their ISO 9660 filesystem drivers. (I have a
  proposal for NetBSD. Fixing FreeBSD will be harder.)

  As for downstreamers: Let's discuss their perceived and real needs with
  them. Maybe it turns out that the desire for UDF is based on false rumors.
  

Have a nice day :)

Thomas