Re: debian-hppa install notes with some CD trouble

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

i had a second look at the details and would now bet on blkid cautiously
trying to read the end of the medium for things like GPT backup block.
If this is true, then the kernel log message is harmless.


Meelis Roos wrote:
> So it seems something else in the boot process tries to read the very end of
> the CD and fails. But nothing depends on it in practice.

About 3 years ago, Archlinux shipped in its ISOs a version of blkid which
wanted to access the last two blocks of the medium. I discussed this with
Karel Zak in spring 2016. He changed blkid to do something like

  $ LIBBLKID_DEBUG=all ./blkid -p /dev/sr2
  ...
  17182: libblkid: LOWPROBE: CDROM: read sector 1436248 failed Input/output error
  17182: libblkid: LOWPROBE: CDROM: reduce size from 735363072 to 735358976.
  17182: libblkid: LOWPROBE: ready for low-probing, offset=0, size=735358976
  ...


> Sector numbers are strange though - 422072 sectors in tack but 422064 is
> causing problems - maybe because of Linux doing bigger requests.

The reported READ(10) command requested only two blocks:
  [   36.019042] sr 0:0:6:0: [sr0] tag#46 CDB: opcode=0x28 28 00 00 01 9c 2c 00 00 02 00
Starting Logical Block address is 0x019c2c = 105516. Transfer Length is 0x002.

So it is not the classical "Read-Ahead" situation but would well match
the behavior of blkid.
Assumed that your blkid is already fixed, this error report would be the
harmless trace of blkid's cautious read attempt.


> dd with bs=2048 reads
> 105516+0 records in
> 105516+0 records out
> and 105516 < 105518. Why 105516?

With older kernels you would get an I/O error. With newer kernels there
is an attempt to catch the Read-Ahead bug which sometimes works and sometimes
does not. In
  https://marc.info/?l=linux-scsi&m=145666692729714&w=2
i wrote
  "I do not find the promise for the "error_sector" information in SPC-3
   or MMC-5. [...]
   The correction in sr.c seems (empirically) to work with TAO CD tracks of
   which the number of blocks is divisible by 2. All valid blocks can be
   read by read(2) and mmap(2).
   Nevertheless ioctl(BLKGETSIZE) still returns the size as deduced from
   READ CAPACITY.
   So young blkid explicitly demands the two unreadble blocks and thus fails."


Have a nice day :)

Thomas