[Top][All Lists]

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

Re: [Bug-xorriso] xorriso.x86_64 1.5.0 - 'No Joliet present'

From: Thomas Schmitt
Subject: Re: [Bug-xorriso] xorriso.x86_64 1.5.0 - 'No Joliet present'
Date: Thu, 21 Mar 2019 19:34:05 +0100


> Fedora-Workstation-netinst-x86_64-29-1.2.iso
> [...]
> $ xorriso --hfsplus on -indev /var/ISO/l.iso -report_system_area as_mkisofs
> [...]
> -c '/isolinux/boot.cat [boot.cat]'

This looks strange. I don't get " [boot.cat]", but just:

  -c '/isolinux/boot.cat'

Further the last option is missing as companion of the third boot image


So the Apple image file will not marked in the Apple Partition Map,
which exists only to mark that image.

I have no idea what could cause such a deviation. The MD5 of the ISO which
i inspected is
  4dede19308be652726c77f6af1d65d59  Fedora-Workstation-netinst-x86_64-29-1.2.iso

Does yours differ ?

> # xorriso -as mkisofs -o "m.iso" -isohybrid-mbr
> --interval:local_fs:0s-15s:zero_mbrpt,zero_gpt,zero_apm:'../../ISO/l.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 [boot.cat]' -b '/isolinux/isolinux.bin' -no-emul-boot
> -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e
> '/images/efiboot.img' -no-emul-boot -boot-load-size 19960
> -isohybrid-gpt-basdat -isohybrid-apm-hfsplus -eltorito-alt-boot -e
> '/images/macboot.img' -no-emul-boot -boot-load-size 42016
> -isohybrid-gpt-hfsplus iso-t

If you ever change the size of '/images/efiboot.img' or '/images/macboot.img'
then omit their options -boot-load-size 19960 or -boot-load-size 42016.
xorriso will then register the actual image file sizes in the El Torito

> Observations: unexpectedly as a result of the execution at step two of
> command beginning by 'xorriso -as mkisofs' changes operated are:
> System id: LINUX ==> (empty)

That would be xorrisofs (i.e. xorriso -as mkisofs) option

  -sysid LINUX

This PVD field is not supposed to tell what's in the ISO but rather
"may identify the system which can recognize and act upon the content
of the System Area in image blocks 0 to 15".
In this case that would be PC-BIOS, UEFI, and some unknown Apple firmware

> Volume id: Fedora-WS-dvd-x86_64-29 ==> ISOIMAGE

To set the Volume Id (filesystem label) add option

  -V 'Fedora-WS-dvd-x86_64-29'

> Data preparer id: (empty) ==> XORRISO-1.5.0 2018.09.15.133001,

genisoimage puts its hallmark into field Application Id which "may identify
the specification of how the data are recorded".
xorriso rather puts it into Preparer Id which "may identify the person or
other entity which controls the preparation of the data which shall be
You can join the genisoimage habit by

  -A "@xorriso@" -p ""

> Joliet with UCS level 3 found ==> NO Joliet present

You'd have to add option


> Status "NO Joliet present" is probably a bug as it was present at step one,
> as a result of execution of 'mkisofs'.
> [...]
> # mkisofs -Jrlvo "m.iso" -V "Fedora-WS-dvd-x86_64-29" iso-t

This run of mkisofs has no influence on the result of the xorriso run.
Actually by xorrisofs option
  -o "m.iso"
you overwrite the ISO image that was created by mkisofs. No info is taken
from there.

From where did you get the inspiration for your commands ? I recently
saw a similar duplicate use of genisoimage and xorriso from a user who
wants to replay an Arch Linux ISO.

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]