Re: Unclear error message when using -append-partition

[Thomas Schmitt]

Hi,

i wrote:
> Please give me a note when such an ISO is ready for downloading.

This request was unneeded (and only explainable with the fact that i
had not yet breakfast when i wrote it).

After looking again at your mail to devel@lists.fedoraproject.org,
i now downloaded the mentioned
  https://bcl.fedorapeople.org/boot-grub2-f36.iso

The report of its boot lures looks good. (I should re-assemble my old
BIOS machine and try it out. But a test of mine would end when the
boot process shows indications that GRUB was started successfully.)

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

One thing remains to consider:

The traditional end padding of 300 KiB shows up as GPT partition:

  $ /sbin/fdisk -l boot-grub2-f36.iso
  ...
  boot-grub2-f36.iso3 1333556 1334155     600   300K Microsoft basic data

That's not a bug, because GRUB developer Vladimir Serbinenko wanted no
blocks which are unclaimed by GPT, but maybe it's an unwanted feature.
Option
  -no-pad
would avoid the padding and the small useless end partition.

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
up to the perceived end of the CD capacity when blocks near the end of
the CD are requested.
That would be fine if not SCSI MMC specs had an ambiguity in the
definition of command READ CAPACITY in respect to the last two blocks
of a TAO CD track ("Run-out blocks").
The drive firmwares take this opportunity to implement contradicting
habits. The majority counts the non-data Run-out blocks as part of the
readable cpacity, which lures Linux into an i/o error when trying to
read them ahead.

My detailed assessment of the problem is at
  https://lore.kernel.org/linux-scsi/6531578277915568387@scdbackup.webframe.org/
(I have a patch for single session TAO CDs. But linux-scsi ignores me
even if i report a kernel Oops on powerpc64 with zisofs.)

The problem can be avoided if the burn program uses write type SAO (default
with xorriso and cdrskin) or if it adds add own traditional padding.
It does not occur on DVD or BD media.
Regrettably, TAO is the default for CD burning with cdrecord and wodim.
They need option -sao or option padsize=300k to keep the ahead reading of
Linux inside the area of readable data. (I guess 128k would be enough. But
traditions are traditions. Especially those with faulty reasoning.)


Have a nice day :)

Thomas