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

[Neal Gompa]

On Sun, Mar 18, 2018 at 12:48 PM, Thomas Schmitt <address@hidden> wrote:
> 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.
>
>

Good to know, thanks. :)

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

If I could use hfsplus for ppc, what are the options I need? I'd like
to have _some_ compatibility with PowerPC systems in place...

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

CentOS and a few other downstream derivatives of Fedora produce huge
ISOs at ~8GB.

For example: 
http://ftp.osuosl.org/pub/centos/7/isos/x86_64/CentOS-7-x86_64-Everything-1708.iso

My understanding is that UDF support is required for these. There's
also some people producing very large live media for the purposes of
having a custom Linux system to carry around.

If UDF isn't necessary for either of those, then I could be okay with
dropping them...

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

This exists in Fedora in the syslinux-nonlinux package, so I do have it...

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

Would that mean that EFI systems would not prefer UEFI boot then?

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

Here's to hoping! :)

>   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 :)
>

You too!


-- 
真実はいつも一つ！/ Always, there's only one truth!