Re: Unclear error message when using -append-partition

[Thomas Schmitt]

Hi,

Brian C. Lane wrote:
> I have a tool called
> mkksiso that takes an iso and adds a kickstart to it and adjusts the
> cmdline. It sounds like I need to take a deeper look at xorriso and see
> if can make this process easier.

I read
  https://weldr.io/lorax/mkksiso.html#how-it-works

Native xorriso command

  -boot_image any replay

should free you from the plight to tell xorriso all the boot options.
The description of mkksiso resembles the xorriso use case called "modifying".
I.e. an input ISO gets loaded, manipulated, and finally a new ISO is written.

-boot_image "any" "replay" analyzes the boot equipment in the -indev ISO
and generates a sequence of xorriso commands which is supposed to cause the
same boot lures as found in -indev. These commands are then applied to the
newly emerging -outdev ISO. (Hopefully this works at least for all ISOs
created by xorriso. YMMV.)
Modifying works without the need for mounting the input ISO.

I tried this:

  # In native mode, xorriso will not truncate the output file
  rm test.iso

  # Let xorriso load the input ISO, map in the 8 MB file /u/FERTIG/NBX as /NBX
  # and finally replay the boot equipment related programs with the found files
  # and non-file objects:
  xorriso -indev boot-grub2-f36.iso \
          -outdev test.iso \
          -map /u/FERTIG/NBX /NBX \
          -volid "Modified_Fedora-36-x86_64" \
          -boot_image any replay --

There can be multiple -map commands, -add commands, and also -rm, -rm_r,
-mv, -chown, -chmod. See man xorriso.
You are quite free to manipulate the loaded ISO before it gets written.

  # Inspect the newly created ISO for boot equipment and the existence
  # of a file named "/NBX"
  xorriso -indev test.iso \
          -report_el_torito plain \
          -report_system_area plain \
          -lsdl /NBX --

The inspection yields:

  Volume id    : 'Modified_Fedora-36-x86_64'
  El Torito catalog  : 145  1
  El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
  El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4         146
  El Torito boot img :   2  UEFI  y   none  0x0000  0x00  20288      332318
  El Torito img path :   1  /images/eltorito.img
  El Torito img opts :   1  boot-info-table grub2-boot-info
  El Torito img blks :   2  5072
  System area options: 0x00004201
  System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT
  ISO image size/512 : 1349624
  Partition offset   : 16
  MBR heads per cyl  : 64
  MBR secs per head  : 32
  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x00  0xee            1      1349623
  GPT                :   N  Info
  GPT disk GUID      :      6229327403ae9d41af6fee5c704c7ef0
  GPT entry array    :      2  248  separated
  GPT lba range      :      64  1349560  1349623
  GPT partition name :   1  490053004f003900360036003000
  GPT partname local :   1  ISO9660
  GPT partition GUID :   1  6229327403ae9d41af6eee5c704c7ef0
  GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
  GPT partition flags:   1  0x1000000000000001
  GPT start and size :   1  64  1329208
  GPT partition name :   2  41007000700065006e006400650064003200
  GPT partname local :   2  Appended2
  GPT partition GUID :   2  6229327403ae9d41af6dee5c704c7ef0
  GPT type GUID      :   2  28732ac11ff8d211ba4b00a0c93ec93b
  GPT partition flags:   2  0x0000000000000000
  GPT start and size :   2  1329272  20288
  Valid ISO nodes found: 1
  -rwxr-xr-x    1 1000     1000      8173872 Apr  9 17:37 '/NBX'

By the native xorriso default -padding "appended" the padding is outside
the ISO image range and behind the backup GPT.
Thus the padding does not get marked by GPT.

In order to put it inside the ISO filesystem and to get a third GPT partition
you could add xorriso command
  -padding included

But the backup GPT is misplaced anyways, as soon as the image gets copied
onto a USB stick. So it probably does not matter whether trailing bytes
follow.

To prevent the production of the third GPT partition during ISO production
by xorrisofs, you could append the three words
  -- -padding appended
to the xorrisofs options. They have to be the last arguments.
"--" will end mkisofs emulation so that the native xorriso command
-padding "appended" is recognized.

If you want to see the native xorriso commands which get caused by "replay":

  xorriso -indev boot-grub2-f36.iso -report_el_torito cmd

The same as xorrisofs options

  xorriso -indev boot-grub2-f36.iso -report_el_torito as_mkisofs

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

I wrote:
> > The padding is tradition because the ISO might be written to a CD by
> > write type Track-At-Once (TAO). By Linux tradition the kernel reads ahead
> > [...] ("Run-out blocks") [...] which lures Linux into an i/o error

Brian C. Lane wrote:
>  Do you know what the situation is with MacOS and Windows?

I guess they too will try to read ahead when their ISO 9660 reader driver
asks for one or more blocks. They don't have better means than Linux to
get the really readable size of the medium from the drive.

Decisive will be their behavior when they encounter an SCSI read error with
their overshooting read buffer. A good CD-ROM driver should then retry the
read for exactly the number of blocks which are demanded by the original
caller. Linux throws an i/o error instead.

(My patch would then issue own READ(10) SCSI commands to check the last two
blocks of the nominal capacity for readability. If unreadable it would
reduce the kernel's assessment of the medium size and repeat the request
for reading with readahead.
As reported in 2016 to linux-scsi, i have one drive which gives the correct
readable capacity and does not trigger the read-ahead bug.)


Have a nice day :)

Thomas