Re: Unclear error message when using -append-partition

[Brian C. Lane]

On Thu, Apr 14, 2022 at 09:50:10AM +0200, Thomas Schmitt wrote:
> 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.)

Great! Thanks for testing this. As an side note, 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.

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

Oh boy, thanks for the detailed analysis. It sounds like we're stuck
with the 300k then, I wouldn't want to make it harder for people to burn
an iso. Do you know what the situation is with MacOS and Windows? I
would guess there might be a couple users of those OSes who would want to
burn a CD.

Thanks very much for all your help!

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart