Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW

[Thomas Schmitt]

Hi,

Mauro Sacchetto wrote:
> samiel at darkstar:~$ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed
> $isoimage
> [...]
> xorriso : UPDATE :  378 of  378 MB written (fifo  0%) [buf 100%] 0.0x.
> xorriso : UPDATE : Thank you for being patient. Working since 728 seconds.
> Writing to '/dev/sr0' completed successfully.
> [...]
> Media current: CD-RW
> Media status : is written , is closed
> Media summary: 1 session, 193686 data blocks,  378m data,     0 free
> It's all ok!

Phew !
It would have been a hell of a job to debug a broken relationship of
libburn and the kernel of Debian Testing, as i'd need it on a real machine.
(I have a Sid in a virtual machine, but there the ioctl(SG_IO) takes
a different path through the device driver jungle.)


> I eject the CD-RW, inser it again and try to mount it:
> root at darkstar:~# mount /home/samiel/debian-11.1.0-amd64-netinst.iso
> /media/cdrom
> mount: /media/cdrom0: WARNING: source write-protected, mounted read-only.

So the drive itself is still operational after the mishap.


> In Nemo -- Devices now I see twice the CD-RW, the old one (not inspectable)
> and the new one (inspectable).

Looks like the drive was re-connected by the kernel without completely
dropping the old connection. Possibly udev adjusted the symbolic link
/dev/cdrom to the newer device file (/dev/sr1 ?).

The only plausible theory which i have is that Brasero now hits a new
problem in the kernel (5.14 ?) which may or may not involve the drive's
firmware but does not show up with older kernels. (I have a kernel 5.10
which works well with 3 drives.)

I will ask at debian-user mailing list whether there are users of Testing
who have burners and can test them with Brasero.


----------------------------------------------------------------------------
Maybe significant, maybe not:

While riddling what Brasero can do to the drive-kernel connection i see:

> Sense key: 0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x40 0xa0 0x03 0x21
> 0x04 0x00 0x00 0x00 0x00 0x00

That's an SCSI error reply:  Key 5, ASC 21, ASCQ 04.
Key 5 means "Illegal Request".
  https://www.t10.org/lists/asc-num.htm#ASC_21
shows a list of ASC 21 errors up to ASCQ 09. According to that it is

  21h/04h  DZ             UNALIGNED WRITE COMMAND

where a missing "R" between "DZ" and "UNALIGNED" indicates that this
is not supposed to happen with optical drives.

But i fail to imagine what other SCSI device would have been addressed
by Brasero directly. The Linux block device layer does not forward such
SCSI error codes to user space. A program gets to see them only if it
sends SCSI commands via the lower level sg driver.

The form of above "Sense key:" indicates that it does not stem from
libburn, which works via the sg driver.
Debian's code search
  https://codesearch.debian.net/search?q=package%3Abrasero+Sense+key
finds the origin of the message in brasero_sense_data_print()
  https://sources.debian.org/src/brasero/3.12.3-1/libbrasero-media/scsi-sense-data.c/?hl=93#L93
Another search finds the only caller in brasero_sense_data_unknown()
which has more customers. Among them is brasero_sense_data_illegal_request()
called by brasero_sense_data_process(), called by
brasero_scsi_command_issue_sync().
But then the trace becomes fuzzy.
  https://codesearch.debian.net/search?q=package%3Abrasero+brasero_scsi_command_issue_sync&literal=0
yields 35 matches. (Brasero surely does too much SCSI on its own.)
The source file names seem to tell what SCSI commands shall be performed.
No write command among them, and only one setter named
brasero_spc1_mode_select(), which is not a good suspect for the "unaligned
write command error".

It is not clear whether that error is involved in spoiling the relationship
between kernel and drive.

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

Have a nice day :)

Thomas