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

[Mauro Sacchetto]

Package: Brasero
Version: 3.12.3-1

I work on Debian Testing (Bookworm) with Cinnamon, always kept up to
date. The problem I point out is related to the burning of ISO to CD-RW
using Brasero. I state that from the console using wodim I can both
erase CD-RW and burn an ISO. Instead, if I proceed with Brasero with an
already burned CD-RW (containing an ISO):
a) if I try to erase the disk beforehand with the relative tool in the
Tools menu, the disk is found but the operation is not carried out with
the warning:

===========================
Unable to lock the drive
===========================

b) if I try to burn the ISO directly the disc is initially found, but
the operation is not carried out with the warning:

===============================================
Insert a writable CD or DVD.
The disk in Asus DRW-24D5MT is not supported
===============================================

After both types of attempts, the CD-RW (which has not been modified and
still contains the paretenza ISO) is no longer found even by Nemo, with
the warning:

===================================================================================
Unable to mount <name.iso>
Error mounting system-managed device / dev / sr0: no medium found on /
dev / sr0
===================================================================================

If I reboot the system, the CD-RW is found again, and I can mount it
from Nemo and inspect its contents.
It seems that Brasero does not identify the CD-RW as such, ie as rewritable.
The same operations succeed perfectly from a Stable with KDE, using K3b.
I have compared the logs.
Testing / Cinnamon gives me:

===================================================================================
samiel @ darkstar: ~ $ udevadm monitor --property --udev
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
UDEV [19048.365742] change
/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sr0
(block)
ACTION = change
DEVPATH = / devices / pci0000: 00/0000: 00: 1f.2 / ata6 / host5 /
target5: 0: 0/5: 0: 0: 0 / block / sr0
SUBSYSTEM = block
DISK_MEDIA_CHANGE = 1
DEVNAME = / dev / sr0
DEVTYPE = disk
SEQNUM = 3051
USEC_INITIALIZED = 1848541
ID_CDROM = 1
SYSTEMD_MOUNT_DEVICE_BOUND = 1
ID_CDROM_CD_R = 1
ID_CDROM_CD_RW = 1
ID_CDROM_DVD = 1
ID_CDROM_DVD_R = 1
ID_CDROM_DVD_RAM ​​= 1
ID_CDROM_DVD_R_DL_SEQ = 1
ID_CDROM_DVD_R_DL_JR = 1
ID_CDROM_DVD_PLUS_R_DL = 1
ID_CDROM_DVD_PLUS_R = 1
ID_CDROM_DVD_PLUS_RW = 1
ID_CDROM_DVD_RW_SEQ = 1
ID_CDROM_DVD_RW_RO = 1
ID_CDROM_CD = 1
ID_CDROM_RW_REMOVABLE = 1
ID_CDROM_DVD_RW = 1
ID_CDROM_DVD_R_DL = 1
ID_CDROM_MEDIA = 1
ID_CDROM_MEDIA_CD_RW = 1
ID_CDROM_MEDIA_STATE = complete
ID_CDROM_MEDIA_SESSION_COUNT = 1
ID_CDROM_MEDIA_TRACK_COUNT = 1
ID_CDROM_MEDIA_TRACK_COUNT_DATA = 1
ID_ATA = 1
ID_TYPE = cd
ID_BUS = ata
ID_MODEL = DRW-24D5MT
ID_MODEL_ENC = DRW-24D5MT \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \
x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \
x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20
ID_REVISION = 2.00
ID_SERIAL = DRW-24D5MT_KLJL1685744
ID_SERIAL_SHORT = KLJL1685744
ID_ATA_SATA = 1
ID_ATA_SATA_SIGNAL_RATE_GEN1 = 1
ID_WWN = 0x5001480000000000
ID_WWN_WITH_EXTENSION = 0x5001480000000000
ID_PATH = pci-0000: 00: 1f.2-ata-6.0
ID_PATH_TAG = pci-0000_00_1f_2-ata-6_0
ID_PATH_ATA_COMPAT = pci-0000: 00: 1f.2-ata-6
ID_FS_DATA_PREPARER_ID = XORRISO-1.5.0 \ x202018.09.15.133001 \ x2c \
x20LIBISOBURN-1.5.0 \ x2c \ x20LIBISOFS-1.5.0 \ x2c \ x20LIBBURN-1.5.0
ID_FS_UUID = 2021-11-03-15-04-45-00
ID_FS_UUID_ENC = 2021-11-03-15-04-45-00
ID_FS_BOOT_SYSTEM_ID = EL \ x20TORITO \ x20SPECIFICATION
ID_FS_VERSION = Joliet Extension
ID_FS_LABEL = Debian_testing_amd64_n
ID_FS_LABEL_ENC = Debian \ x20testing \ x20amd64 \ x20n
ID_FS_TYPE = iso9660
ID_FS_USAGE = filesystem
ID_PART_TABLE_UUID = 7ed8b2bd
ID_PART_TABLE_TYPE = dos
ID_FOR_SEAT = block-pci-0000_00_1f_2-ata-6_0
MAJOR = 11
MINOR = 0
DEVLINKS = / dev / disk / by-id / wwn-0x5001480000000000 / dev / disk /
by-id / ata-DRW-24D5MT_KLJL1685744
/dev/disk/by-path/pci-0000:00:1f.2-ata-6
/dev/disk/by-path/pci-0000:00:1f.2-ata-6.0 / dev / cdrom / dev / disk /
by-label / Debian \ x20testing \ x20amd64 \ x20n / dev / disk / by-uuid
/ 2021-11-03-15-04-45-00
TAGS =: systemd: uaccess: seat:
CURRENT_TAGS =: systemd: uaccess: seat:
===================================================================================

Stable / KDE gives to me:

===================================================================================
samiel@darkstar:~$ udevadm monitor --property --udev
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
UDEV  [184.968927] change
/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sr0
(block)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sr0
SUBSYSTEM=block
DISK_MEDIA_CHANGE=1
DEVNAME=/dev/sr0
DEVTYPE=disk
SEQNUM=2895
USEC_INITIALIZED=1752355
ID_CDROM=1
SYSTEMD_MOUNT_DEVICE_BOUND=1
ID_CDROM_CD=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_DVD=1
ID_CDROM_DVD_R=1
ID_CDROM_DVD_RW=1
ID_CDROM_DVD_RAM=1
ID_CDROM_DVD_PLUS_R=1
ID_CDROM_DVD_PLUS_RW=1
ID_CDROM_DVD_PLUS_R_DL=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_CD_RW=1
ID_CDROM_MEDIA_STATE=complete
ID_CDROM_MEDIA_SESSION_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
ID_ATA=1
ID_TYPE=cd
ID_BUS=ata
ID_MODEL=DRW-24D5MT
ID_MODEL_ENC=DRW-24D5MT\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
ID_REVISION=2.00
ID_SERIAL=DRW-24D5MT_KLJL1685744
ID_SERIAL_SHORT=KLJL1685744
ID_ATA_SATA=1
ID_ATA_SATA_SIGNAL_RATE_GEN1=1
ID_WWN=0x5001480000000000
ID_WWN_WITH_EXTENSION=0x5001480000000000
ID_PATH=pci-0000:00:1f.2-ata-6.0
ID_PATH_TAG=pci-0000_00_1f_2-ata-6_0
ID_PATH_ATA_COMPAT=pci-0000:00:1f.2-ata-6
ID_FS_UUID=2021-11-03-15-04-45-00
ID_FS_UUID_ENC=2021-11-03-15-04-45-00
ID_FS_BOOT_SYSTEM_ID=EL\x20TORITO\x20SPECIFICATION
ID_FS_VERSION=Joliet Extension
ID_FS_LABEL=Debian_testing_amd64_n
ID_FS_LABEL_ENC=Debian\x20testing\x20amd64\x20n
ID_FS_TYPE=iso9660
ID_FS_USAGE=filesystem
ID_PART_TABLE_UUID=7ed8b2bd
ID_PART_TABLE_TYPE=dos
ID_FOR_SEAT=block-pci-0000_00_1f_2-ata-6_0
MAJOR=11
MINOR=0
DEVLINKS=/dev/dvd /dev/dvdrw /dev/disk/by-path/pci-0000:00:1f.2-ata-6
/dev/disk/by-path/pci-0000:00:1f.2-ata-6.0
/dev/disk/by-id/ata-DRW-24D5MT_KLJL1685744
/dev/disk/by-id/wwn-0x5001480000000000
/dev/disk/by-label/Debian\x20testing\x20amd64\x20n /dev/cdrw
/dev/disk/by-uuid/2021-11-03-15-04-45-00 /dev/cdrom
TAGS=:systemd:uaccess:seat:
CURRENT_TAGS=:systemd:uaccess:seat:
===================================================================================

where you can see a difference (I don't know if relevant) at the voice
DEVLINKS:

Testing / Cinnamon
===================================================================================

DEVLINKS = / dev / disk / by-id / wwn-0x5001480000000000 / dev / disk /
by-id / ata-DRW-24D5MT_KLJL1685744
/dev/disk/by-path/pci-0000:00:1f.2-ata-6
/dev/disk/by-path/pci-0000:00:1f.2-ata-6.0 / dev / cdrom / dev / disk /
by-label / Debian \ x20testing \ x20amd64 \ x20n / dev / disk / by-uuid
/ 2021-11-03-15-04-45-00
===================================================================================

Stable / KDE

===================================================================================
DEVLINKS=/dev/dvd /dev/dvdrw /dev/disk/by-path/pci-0000:00:1f.2-ata-6
/dev/disk/by-path/pci-0000:00:1f.2-ata-6.0
/dev/disk/by-id/ata-DRW-24D5MT_KLJL1685744
/dev/disk/by-id/wwn-0x5001480000000000
/dev/disk/by-label/Debian\x20testing\x20amd64\x20n /dev/cdrw
/dev/disk/by-uuid/2021-11-03-15-04-45-00 /dev/cdrom
===================================================================================

Only in the second case (Stable) the burner seems to be recognized as
cdrw / dvdrw, while in the first case (Testing) it is not.
I'm not sure if the problem is actually attributable to Brasero.
Assuming that it could be caused by the kernel (5.14.0-4-amd64) instead,
I tried to install the Buster kernel (5.10.0-0) from Backports, but the
problem recurs. Or could it be due to udev?

[Mauro Sacchetto]

To better clarify the nature of the problem, I installed on Testing / Cinnamon K3b (despite its many dependencies). K3b perfectly burns ISOs to CD-RW, unlike Brasero

[Thomas Schmitt]

Hi,

i am upstream programmer of libburn, which might be in charge of
burning underneath Brasero. Regrettably i cannot interpret Brasero's
messages unless they come from libburn or libisofs. So i am not sure
whether i can help with fixing Brasero.

The statement by other software that no medium is found in /dev/sr0
surprises me. Such a status assessment is usually done by the drive
and i am not aware of any regular means to let a drive ignore or deny
its loaded medium.

Do you see anything in dmesg that occured when Brasero failed and looks
related to "sr" or "cdrom" ?

Can i talk you into inquring the drive by xorriso and logging its
SCSI transactions when the drive has gone mad from Brasero and a medium
is still inserted ?

xorriso -scsi_log on -outdev /dev/sr0 -toc 2>&1 | tee -i /tmp/xorriso.log

This would give insight into what the drive tells about its status
without the programs-in-the-middle. The log is quite verbose and will
have several hundred lines. Please post /tmp/xorriso.log as attachment
or send it to me by private mail.

(I wonder why udevadm monitor of Testing is so eager to insert blanks
everywhere. But that would be a different bug, if it is not a copy+paste
artefact.)


Have a nice day :)

Thomas

[Mauro Sacchetto]

thanx for your quick reply

dmesg tell me:

=====================================================

[23315.697087] sr 5:0:0:0: [sr0] tag#16 FAILED Result:
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
[23315.697092] sr 5:0:0:0: [sr0] tag#16 CDB: Prevent/Allow Medium
Removal 1e 00 00 00 01 00
[23315.697128] brasero[9154]: segfault at 2f400 ip 00007fb6350a5231 sp
00007fff0e805918 error 4 in libc-2.32.so[7fb634f6c000+149000]
[23315.697136] Code: 84 00 00 00 00 00 0f 1f 00 31 c0 c5 f8 77 c3 66 2e
0f 1f 84 00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0 83 e1 3f 83 f9 20 77
1f <c5> fd 74 0f c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 20 83 e1

=====================================================

xorriso tells me only

=====================================================

root@darkstar:~# xorriso -scsi_log on -outdev /dev/sr0 -toc 2>&1 | tee
-i /tmp/xorriso.log
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.


TEST UNIT READY
00 00 00 00 00 00
       19 us     [ 1091 ]

INQUIRY
12 00 00 00 24 00
From drive: 36b
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       10 us     [ 1207 ]
--- SG_IO: host_status= 0x4 SG_ERR_DID_BAD_TARGET (Bad target, device
not responding ?)
--- SG_IO: Gave up connection to drive
libburn : FAILURE : SCSI command 12h yielded host problem: 0x4
SG_ERR_DID_BAD_TARGET (Bad target, device not responding ?)
libburn : FAILURE : Command: INQUIRY : 12 00 00 00 24 00  : dxfer_len= 36
libburn : FATAL : Lost connection to drive
xorriso : FAILURE : Cannot acquire drive '/dev/sr0'
xorriso : aborting : -abort_on 'FAILURE' encountered 'FATAL'

=====================================================



Il 07/11/21 19:37, Thomas Schmitt ha scritto:

--
Prof. Mauro Sacchetto
Santa Croce 1332a
30135 Venezia
tel.: 041 722938
cell.: 348 9690575
e-mail:mauro.s...@gmail.com
Linux user no.: 353546
public key athttp://keyserver.linux.it

[Mauro Sacchetto]

Better than my previous report:

Putting the CD-RW into drivee:

v

root@darkstar:~# xorriso -scsi_log on -outdev /dev/sr0 -toc 2>&1 | tee
-i /tmp/xorriso.log
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.


TEST UNIT READY
00 00 00 00 00 00

     2915 us     [ 6174 ]

INQUIRY
12 00 00 00 24 00
From drive: 36b

05 80 05 32 5b 00 00 00 41 53 55 53 20 20 20 20 44 52 57 2d
32 34 44 35 4d 54 20 20 20 20 20 20 32 2e 30 30
     2729 us     [ 9018 ]

GET CONFIGURATION
46 00 00 00 00 00 00 00 08 00
From drive: 8b
00 00 01 7c 00 00 00 0a
     3910 us     [ 12968 ]

GET CONFIGURATION
46 00 00 00 00 00 00 01 80 00
From drive: 384b
00 00 01 7c 00 00 00 0a 00 00 03 38 00 15 00 00 00 16 00 00
00 2b 00 00 00 1b 00 00 00 1a 00 00 00 14 00 00 00 13 00 00
00 12 00 00 00 11 00 00 00 10 00 00 00 0a 01 00 00 09 00 00
00 08 01 00 00 02 00 00 00 01 0b 08 00 00 00 07 01 00 00 00
00 02 07 04 02 00 00 00 00 03 0b 04 3b 00 00 00 00 04 08 04
02 00 00 00 00 10 01 08 00 00 08 00 00 01 01 00 00 1d 01 00
00 1e 09 04 03 00 00 00 00 1f 08 04 01 00 01 00 00 20 04 0c
00 00 00 00 00 00 08 00 00 00 01 00 00 21 0c 08 3d 0f 03 01
07 00 00 00 00 23 09 08 00 00 00 00 00 00 00 00 00 24 04 04
80 00 00 00 00 26 00 00 00 2a 04 04 01 00 00 00 00 2b 00 04
01 00 00 00 00 2c 00 04 03 00 00 00 00 2d 08 04 5f 00 00 00
00 2e 04 04 7f 00 0d 00 00 2f 08 04 4e 00 00 00 00 33 00 08
00 00 00 01 10 00 00 00 00 37 01 04 00 07 00 00 00 3b 00 04
01 00 00 00 01 00 07 04 00 00 00 00 01 01 00 04 00 00 00 00
01 03 00 04 03 00 01 00 01 04 04 04 00 00 00 00 01 05 07 04
00 00 00 00 01 06 00 04 00 00 00 01 01 07 15 04 1f 00 00 00
01 08 03 10 4b 4c 4a 4c 31 36 38 35 37 34 34 20 20 20 20 20
01 0a 00 0c 46 44 43 00 53 44 43 00 54 4f 43 00 01 0b 00 04
00 00 00 01 01 0c 03 10 32 30 31 39 30 36 31 37 31 30 34 39
20 20 00 00
     3776 us     [ 17057 ]

MODE SENSE
5a 00 2a 00 00 00 00 00 1e 00
From drive: 30b
00 4a 21 00 00 00 00 00 2a 42 3f 37 f1 77 2b 23 1b 90 01 00
02 00 10 8a 00 10 02 c2 02 c2
     5111 us     [ 22223 ]

MODE SENSE
5a 00 2a 00 00 00 00 00 4c 00
From drive: 76b
00 4a 21 00 00 00 00 00 2a 42 3f 37 f1 77 2b 23 1b 90 01 00
02 00 10 8a 00 10 02 c2 02 c2 00 01 00 00 00 00 02 c2 00 01
00 00 02 c2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

     2926 us     [ 25256 ]

GET PERFORMANCE
ac 00 00 00 00 00 00 00 00 00 03 00
From drive: 8b
00 00 00 14 00 00 00 00
     2187 us     [ 27482 ]

GET PERFORMANCE
ac 00 00 00 00 00 00 00 00 01 03 00
From drive: 24b
00 00 00 14 00 00 00 00 00 00 00 00 00 05 7d a9 00 00 10 89
00 00 02 c1
     1616 us     [ 29158 ]

GET PERFORMANCE
ac 00 00 00 00 00 00 00 00 01 03 00
From drive: 24b
00 00 00 14 00 00 00 00 00 00 00 00 00 05 7d a9 00 00 10 89
00 00 02 c1
     1516 us     [ 30725 ]

GET PERFORMANCE
ac 10 00 00 00 00 00 00 00 00 00 00
From drive: 8b
00 00 00 14 00 00 00 00
     1012 us     [ 31764 ]

GET PERFORMANCE
ac 10 00 00 00 00 00 00 00 01 00 00
From drive: 24b
00 00 00 14 00 00 00 00 00 00 00 00 00 00 0b 7c 00 02 f3 ff
00 00 1b 90
     1053 us     [ 32855 ]

GET PERFORMANCE
ac 10 00 00 00 00 00 00 00 01 00 00
From drive: 24b
00 00 00 14 00 00 00 00 00 00 00 00 00 00 0b 7c 00 02 f3 ff
00 00 1b 90
      965 us     [ 33860 ]

MODE SENSE
5a 00 01 00 00 00 00 00 0c 00
From drive: 12b
00 12 21 00 00 00 00 00 01 0a 80 c0
      582 us     [ 34472 ]

PREVENT/ALLOW MEDIA REMOVAL
1e 00 00 00 00 00
      510 us     [ 34991 ]

START/STOP UNIT
1b 00 00 00 03 00
      374 us     [ 35390 ]

TEST UNIT READY
00 00 00 00 00 00

     1387 us     [ 536936 ]

PREVENT/ALLOW MEDIA REMOVAL

1e 00 00 00 01 00

     2893 us     [ 539878 ]

START/STOP UNIT
1b 01 00 00 01 00
     3156 us     [ 543076 ]

TEST UNIT READY
00 00 00 00 00 00

     5605 us     [ 1048864 ]

START/STOP UNIT
1b 00 00 00 01 00
  1562894 us     [ 2611828 ]

INQUIRY
12 00 00 00 24 00
From drive: 36b

05 80 05 32 5b 00 00 00 41 53 55 53 20 20 20 20 44 52 57 2d
32 34 44 35 4d 54 20 20 20 20 20 20 32 2e 30 30
      524 us     [ 2612573 ]

MODE SENSE
5a 00 2a 00 00 00 00 00 1e 00
From drive: 30b
00 4a 21 00 00 00 00 00 2a 42 3f 37 f1 77 2b 23 1b 90 01 00
02 00 10 8a 00 10 02 c2 02 c2
     3773 us     [ 2616506 ]

MODE SENSE
5a 00 2a 00 00 00 00 00 4c 00
From drive: 76b
00 4a 21 00 00 00 00 00 2a 42 3f 37 f1 77 2b 23 1b 90 01 00
02 00 10 8a 00 10 02 c2 02 c2 00 01 00 00 00 00 02 c2 00 01
00 00 02 c2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

     5770 us     [ 2622414 ]

GET PERFORMANCE
ac 00 00 00 00 00 00 00 00 00 03 00
From drive: 8b
00 00 00 14 00 00 00 00
     1529 us     [ 2623993 ]

GET PERFORMANCE
ac 00 00 00 00 00 00 00 00 01 03 00
From drive: 24b
00 00 00 14 00 00 00 00 00 00 00 00 00 05 7d a9 00 00 10 89
00 00 02 c1
     1491 us     [ 2625571 ]

GET PERFORMANCE
ac 00 00 00 00 00 00 00 00 01 03 00
From drive: 24b
00 00 00 14 00 00 00 00 00 00 00 00 00 05 7d a9 00 00 10 89
00 00 02 c1
     1500 us     [ 2627186 ]

GET PERFORMANCE
ac 10 00 00 00 00 00 00 00 00 00 00
From drive: 8b
00 00 00 14 00 00 00 00
      657 us     [ 2627929 ]

GET PERFORMANCE
ac 10 00 00 00 00 00 00 00 01 00 00
From drive: 24b
00 00 00 14 00 00 00 00 00 00 00 00 00 00 0b 7c 00 02 f3 ff
00 00 1b 90
      963 us     [ 2629008 ]

GET PERFORMANCE
ac 10 00 00 00 00 00 00 00 01 00 00
From drive: 24b
00 00 00 14 00 00 00 00 00 00 00 00 00 00 0b 7c 00 02 f3 ff
00 00 1b 90
      910 us     [ 2630033 ]

MODE SENSE
5a 00 01 00 00 00 00 00 0c 00
From drive: 12b
00 12 21 00 00 00 00 00 01 0a 80 c0
      496 us     [ 2630600 ]

MODE SENSE
5a 00 05 00 00 00 00 00 0a 00
From drive: 10b
00 3a 21 00 00 00 00 00 05 32
      514 us     [ 2631159 ]

READ DISC INFORMATION
51 00 00 00 00 00 00 00 22 00
From drive: 34b
00 20 1e 01 01 01 01 80 00 00 00 00 00 28 11 00 ff ff ff ff
ff ff ff ff 00 00 00 00 00 00 00 00 00 00
     2562 us     [ 2633833 ]

READ CAPACITY
25 00 00 00 00 00 00 00 00 00
From drive: 8b
00 02 f3 ff 00 00 08 00
     1012 us     [ 2634926 ]

READ TOC/PMA/ATIP
43 02 02 00 00 00 00 00 04 00
From drive: 4b
00 4f 01 01
     3027 us     [ 2637993 ]

READ TOC/PMA/ATIP
43 02 02 00 00 00 00 00 51 00
From drive: 81b
00 4f 01 01 01 14 00 a0 00 00 00 00 01 00 00 01 14 00 a1 00
00 00 00 01 00 00 01 14 00 a2 00 00 00 00 2b 02 24 01 14 00
01 00 00 00 00 00 02 00 01 54 00 b0 ff ff ff 03 4f 3b 4a 01
54 00 c0 a2 00 8c 00 61 1a 41 01 54 00 c1 04 98 60 00 00 00
00
     3404 us     [ 2641488 ]

READ TRACK INFORMATION
52 01 00 00 00 01 00 00 22 00
From drive: 34b
00 22 01 01 00 04 01 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 02 f3 fe 00 00 00 00 00 00
     4736 us     [ 2646337 ]

READ(10)
28 00 00 00 00 00 00 00 20 00
   103498 us     [ 2749945 ]

READ(10)
28 00 00 00 00 00 00 00 20 00
   112124 us     [ 2862147 ]

READ(10)
28 00 00 00 00 20 00 00 20 00
    60623 us     [ 2922962 ]
xorriso : NOTE : Disc status unsuitable for writing
Drive current: -outdev '/dev/sr0'
Media current: CD-RW
Media status : is written , is closed
Media summary: 1 session, 193536 data blocks,  378m data,     0 free

START/STOP UNIT
1b 01 00 00 00 00
      868 us     [ 2924274 ]

TEST UNIT READY
00 00 00 00 00 00

     5575 us     [ 3430047 ]
Drive current: -outdev '/dev/sr0'
Drive access : exclusive:unrestricted
Drive type   : vendor 'ASUS' product 'DRW-24D5MT' revision '2.00'
Drive id     : 'KLJL1685744     '
Media current: CD-RW

READ TOC/PMA/ATIP
43 02 04 00 00 00 00 00 1c 00
From drive: 28b
00 1a 00 00 d1 00 c6 00 61 1a 41 00 4f 3b 4a 00 02 4c b0 00
4a c8 36 00 00 80 80 00
     2309 us     [ 3432616 ]
Media product: 97m26s65f/79m59s74f , CMC Magnetics Corporation
Media status : is written , is closed

READ TOC/PMA/ATIP
43 02 04 00 00 00 00 00 1c 00
From drive: 28b
00 1a 00 00 d1 00 c6 00 61 1a 41 00 4f 3b 4a 00 02 4c b0 00
4a c8 36 00 00 80 80 00
     2088 us     [ 3434846 ]
Media blocks : 193536 readable , 0 writable , 359847 overall
TOC layout   : Idx ,  sbsector ,       Size , Volume Id

START/STOP UNIT
1b 01 00 00 01 00
     5723 us     [ 3440650 ]

TEST UNIT READY
00 00 00 00 00 00

     5316 us     [ 3946172 ]

START/STOP UNIT
1b 00 00 00 01 00
  2763718 us     [ 6709966 ]

READ(10)
28 00 00 00 00 00 00 00 20 00
   105111 us     [ 6815174 ]
ISO session  :   1 ,         0 ,    193536s , Debian 11.1.0 amd64 n
Media summary: 1 session, 193536 data blocks,  378m data,     0 free

PREVENT/ALLOW MEDIA REMOVAL
1e 00 00 00 00 00
     1071 us     [ 6816469 ]

START/STOP UNIT
1b 01 00 00 00 00
      395 us     [ 6816930 ]

TEST UNIT READY
00 00 00 00 00 00

     5580 us     [ 7322706 ]
================================================================================

Trying to burn an ISO, Brasero crash and:

================================================================================

root@darkstar:~# xorriso -scsi_log on -outdev /dev/sr0 -toc 2>&1 | tee
-i /tmp/xorriso.log
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.


TEST UNIT READY
00 00 00 00 00 00

       19 us     [ 289 ]

INQUIRY
12 00 00 00 24 00
From drive: 36b
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

        9 us     [ 397 ]

--- SG_IO: host_status= 0x4 SG_ERR_DID_BAD_TARGET (Bad target, device
not responding ?)
--- SG_IO: Gave up connection to drive
libburn : FAILURE : SCSI command 12h yielded host problem: 0x4
SG_ERR_DID_BAD_TARGET (Bad target, device not responding ?)
libburn : FAILURE : Command: INQUIRY : 12 00 00 00 24 00  : dxfer_len= 36
libburn : FATAL : Lost connection to drive
xorriso : FAILURE : Cannot acquire drive '/dev/sr0'
xorriso : aborting : -abort_on 'FAILURE' encountered 'FATAL'

================================================================================

[Thomas Schmitt]

Hi,

(No need to Cc: me, i am subscribed to the bug report 998718.
If you are subscribed too and don't want to be Cc:ed, then tell me.)

> thanx for your quick reply

That's because new udevadm said "XORRISO". I found the bug report by my
evening patrol with Google.

-----------------------------------------------------------------------
Diagnosis:

The unusable drive state looks like a bad relationship between drive
and kernel. Regrettably the dmesg log does not tell how Brasero brought
this relationship in its bad shape.

------------------------------------------------------------------------
What to do next:

Did you already try what happens if you eject the CD and insert it again
after spoiling the drive state with Brasero and before using the drive
for mounting or for xorriso -toc ?
If not yet, then please do.

> xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

I guess this means you are running Debian "testing".
("stable" has version 1.5.2.)

To outrule the possibility that libburn underneath Brasero is to blame,
please use xorriso to burn an image by this drive:

isoimage=...path.to.your.ISO.image.file...

xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed $isoimage

Then try whether the drive is still usable.
(Crossing fingers now.)

---------------------------------------------------------------------
Just in case somebody is interested in details of my diagnosis:

Mauro Sacchetto wrote:
> dmesg tell me:

> [23315.697087] sr 5:0:0:0: [sr0] tag#16 FAILED Result:
> hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s

> [23315.697092] sr 5:0:0:0: [sr0] tag#16 CDB: Prevent/Allow Medium Removal 1e

> 00 00 00 01 00

The drive did not respond to a SCSI command from the kernel's SCSI
driver. Brasero obviously tried to lock the drive tray so that pressing
the eject button would have no effect. (At least with motorized trays.)

> [23315.697128] brasero[9154]: segfault at 2f400 ip 00007fb6350a5231 sp
> 00007fff0e805918 error 4 in libc-2.32.so[7fb634f6c000+149000]

This might be due to a bug in Brasero, which would not react properly
on the failure of the tray locking attempt.


> xorriso tells me only

> TEST UNIT READY
> 00 00 00 00 00 00

>       19 us     [ 1091 ]

The drive obviously responded to this SCSI command (indicating that it
is ready for work).

> INQUIRY
> 12 00 00 00 24 00
> From drive: 36b
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

>        10 us     [ 1207 ]

> --- SG_IO: host_status= 0x4 SG_ERR_DID_BAD_TARGET (Bad target, device not
> responding ?)
> --- SG_IO: Gave up connection to drive

Here the drive did not respond to the kernel, which thus reported the
DID_BAD_TARGET to libburn. The Linux SG_IO adapter of libburn then gave
up the connection.

> libburn : FATAL : Lost connection to drive
> xorriso : FAILURE : Cannot acquire drive '/dev/sr0'
> xorriso : aborting : -abort_on 'FAILURE' encountered 'FATAL'

But xorriso at least found a way out without producing a segmentation
fault in libc or elsewhere.

> Better than my previous report:

> xorriso -scsi_log on -outdev /dev/sr0 -toc

> [... longer list of SCSI transactions ...]
> Media current: CD-RW
> [...]

> Media product: 97m26s65f/79m59s74f , CMC Magnetics Corporation
> Media status : is written , is closed

> [...]

> TOC layout   : Idx ,  sbsector ,       Size , Volume Id

> ISO session  :   1 ,         0 ,    193536s , Debian 11.1.0 amd64 n
> Media summary: 1 session, 193536 data blocks,  378m data,     0 free

All seems well. The drive responds to commands in reasonable time,
the medium is recognized as CD-RW, and the filesystem is recognized
as ISO 9660.

[Mauro Sacchetto]

======================================================
samiel@darkstar:~$ isoimage=/home/samiel/debian-11.1.0-amd64-netinst.iso
samiel@darkstar:~$ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed
$isoimage

xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

xorriso : NOTE : Disc status unsuitable for writing
Drive current: -outdev '/dev/sr0'
Media current: CD-RW

Media status : is written , is closed

Media summary: 1 session, 193536 data blocks,  378m data,     0 free

Beginning to blank medium in mode 'fast'.
xorriso : UPDATE : Blanking  ( 1.0% done in 1 seconds )
...
xorriso : UPDATE : Blanking  ( 97.8% done in 53 seconds )
Blanking done
xorriso : NOTE : Re-assessing -outdev '/dev/sr0'

Drive current: -outdev '/dev/sr0'
Media current: CD-RW

Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data,  703m free
Beginning to write data track.
xorriso : UPDATE : Thank you for being patient. Working since 0 seconds.
...
xorriso : UPDATE : Thank you for being patient. Working since 43 seconds.
xorriso : UPDATE :    0 of  378 MB written (fifo 99%) [buf 100%] 3.8x.
...
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.

xorriso : NOTE : Re-assessing -outdev '/dev/sr0'

xorriso : NOTE : Disc status unsuitable for writing
Drive current: -outdev '/dev/sr0'
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!
Than I try to burn the ISO woth Brasero launching it by console:
======================================================
samiel@darkstar:~$ brasero

** (brasero:2837): WARNING **: 01:07:35.934: Could not establish a
connection to Tracker:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.Tracker3.Miner.Files was not provided by any .service files

(brasero:2837): Gtk-WARNING **: 01:08:01.131: Failed to fetch network
locations: È stato raggiunto il timeout
Sense key: 0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x40 0xa0 0x03
0x21 0x04 0x00 0x00 0x00 0x00 0x00
Segmentazion fault
======================================================
and Brasero crashes
dmesg:
======================================================
[ 1657.332142] sr 5:0:0:0: [sr0] tag#10 FAILED Result:
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
[ 1657.332151] sr 5:0:0:0: [sr0] tag#10 CDB: Prevent/Allow Medium

Removal 1e 00 00 00 01 00

[ 1657.332231] brasero[2837]: segfault at 2f400 ip 00007fc57b9e0231 sp
00007ffecc8f6368 error 4 in libc-2.32.so[7fc57b8a7000+149000]
[ 1657.332268] Code: 84 00 00 00 00 00 0f 1f 00 31 c0 c5 f8 77 c3 66 2e

0f 1f 84 00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0 83 e1 3f 83 f9 20 77
1f <c5> fd 74 0f c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 20 83 e1

======================================================
I eject the CD-RW, inser it again and try to mount it:
======================================================
root@darkstar:~# mount /home/samiel/debian-11.1.0-amd64-netinst.iso
/media/cdrom
mount: /media/cdrom0: WARNING: source write-protected, mounted read-only.
======================================================
In Nemo -- Devices now I see twice the CD-RW, the old one (not
inspectable) and the new one (inspectable).
But If I try to mount it not by console, but from Nemo (when there is
only an occurence of the device) I receive:
======================================================
Impossible to mount debiam-11....iso
Error mounting /dev/sr0 at /media/samiel7Debian...: no medium found on
/dev/sro
After this:
======================================================
samiel@darkstar:~$ isoimage=/home/samiel/debian-11.1.0-amd64-netinst.iso
samiel@darkstar:~$ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed
$isoimage

xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

libburn : FAILURE : SCSI command 12h yielded host problem: 0x4

SG_ERR_DID_BAD_TARGET (Bad target, device not responding ?)

libburn : FAILURE : Command: INQUIRY : 12 00 00 00 24 00  : dxfer_len= 36

libburn : FATAL : Lost connection to drive
xorriso : FAILURE : Cannot acquire drive '/dev/sr0'

xorriso : FAILURE : -as cdrecord: Job could not be performed properly.

xorriso : aborting : -abort_on 'FAILURE' encountered 'FATAL'

======================================================


Il 07/11/21 22:34, Thomas Schmitt ha scritto:

[Thomas Schmitt]

Hi,

Mauro Sacchetto wrote:
> samiel@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@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.

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

[Mauro Sacchetto]

I eject the CD-RW, inser it again and try to mount it:
>> root@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.

Yes, but only as root, not as a simple user

>> 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 installed on testing (kernel 5.14...) the kernel 5.10 from stable

(backports), but I received the same error


Thank you for your job!:)

[Mauro Sacchetto]

Further experiment: I installed Brasero on a Stable (wih KDE)

but receive the same behavior: Brasero crashes and make /dev/sr0
unavailable.

On the contrary, K3b works fine

[Thomas Schmitt]

Hi,

Mauro Sacchetto wrote:
> I installed on testing (kernel 5.14...) the kernel 5.10 from stable
> (backports), but I received the same error

So i fired up my experimental machine which has Debian 10 but kernel
5.10.0-rc3 cloned from git branch "linux-block" and modified to fix
a few bugs in modules sr, cdrom and isofs. (linux-scsi is not
interested in my patches. Shrug.)

Three drives are attached:
0 -dev '/dev/sr0' rwrw-- : 'ASUS ' 'DRW-24D5MT'
1 -dev '/dev/sr1' rwrw-- : 'PIONEER ' 'BD-RW BDR-S09'
2 -dev '/dev/sr2' rwrw-- : 'TSSTcorp' 'CDDVDW SH-S223B'
sr0 and sr1 are connected via SATA. sr2 is in a USB box.
sr0 is the same model as yours. Best chances for reproducing the burn
disaster.

Brasero and udisks on XFCE seem to be much at odds. Windows pop up which
offer mounting and file managering. I decline.

-------------------------------------------------------------------------
Experiment reports about the ASUS:

First run with /dev/sr0, the ASUS:
Brasero burns but stalls with its "Success" stage. The SCSI error reply
is reported in Brasero's start terminal:

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

but no crash happens.
The drive is now unusable but the CD yields the correct MD5 for
debian-11.1.0-amd64-netinst.iso when read by /dev/sr2.

I power cycle the machine to get my drive back.

Next try, still with sr0 ASUS:
Brasero says that no supported disk is in the drive. I click "Cancel"
and again "Burn image". It finds the CD in sr0 but then immediately
crashes with "Segmentation fault".
Drive is unusable afterwards.

Power cycle and next try with sr0 ASUS:
I start Brasero and put the CD into sr0. Immediately the drive becomes
unusable. No further action is needed.

Power cycle and next try with sr0 ASUS:
I blank the CD-RW by xorriso to keep udisks as far away as possible.

I start Brasero and a window pops up which says it cannot mount the CD.
(How stupid can Brasero and udisks become ? Is there any limit ?)
I confirm that i noticed and let Brasero burn.
It burns up to "Finalizing" and "Success" but then stalls for about a
minute while the drive is blinking. Then comes the SCSI error message
and after another minute a window pops up:
"Error while burning. The drive is busy."
I click "Close" and get the big Brasero window.
I quit Brasero and the drive is unusable.

Whatever i do, i don't get a new /dev/sr3 with the ASUS drive.

-----------------------------------------------------------------------
Experiment reports about PIONEER and TSSTcorp (Samsung):

Power cycle and CD into /dev/sr2, the TSSTcorp in a USB box.
First i let md5sum compute the MD5 of the previously burnt CD. It matches
the ISO's MD5.

I blank the CD-RW by xorriso, eject, and start Brasero. CD back into sr2
Complaint about being not mountable.
Whatever, Brasero begins to burn, finalizes, says "success", waits a
minute while the drive is blinking, shows "Creating image checksum",
begins to read at high and noisy speed, and finally ejects the medium.
I insert again. Some software lets the drive blink and then complains
that it cannot mount. md5sum /dev/sr2 yields the correct MD5.

Blanked again by xorriso.

I insert the CD into /dev/sr1, the PIONEER at SATA. This run is the
smoothest of all:
"Burning image to CD", "Finalizing", "Success", SCSI error message in
start terminal, "Creating image checksum", "Ejecting medium", "Success".
No minute of inactivity to see.
Afterwards the drive is still functional with xorriso. md5sum yields
the correct checksum.

--------------------------------------------------------------------------
Summary:

Brasero (maybe by help of udisks) is absolutely ill with the ASUS drive.
With the other two drives it is still behaving confused but in the end
can burn and does _not_ spoil the connection between drive and kernel.

The obscure SCSI error 5,21,04 "Unaligned write" appears only with the ASUS.

So the ASUS firmware quite probably has a stake in the problem.
But it seems to need some abuse by Brasero (or udisks) to throw the
SCSI error and then to become unusable.

--------------------------------------------------------------------------
Outlook:

I will try later with kernel 4.19.0-17 which is currently the official
one for Debian 10 (upgraded in october due to the certificate blooper
around "DST Root CA X3").

For now i would bet that the problem with the ASUS drive persists.
I assume that it is a cooperation of buggy userland tools and buggy
drive firmware.

[Thomas Schmitt]

Hi

i have to correct my previous report:

> The obscure SCSI error 5,21,04 "Unaligned write" appears only with the ASUS.

It appears with the PIONEER too, but not with the TSSTcorp drive.
(And Brasero spoils the ASUS even if the message does not appear.)

Nevertheless, i riddle what SCSI command can cause this error.
WRITE commands tell block address and block count of their payload.
They have no means to address single bytes.
CDs can take single blocks as payload of a WRITE command.
So i fail to see how such a command can be unaligned.

[Thomas Schmitt]

Hi,

i booted kernel 4.19.0-17 which stems from a Debian 10 upgrade.

Same as with 5.10-rc3:

I started up brasero with empty tray of all drives. After inserting the
CD-RW into the ASUS, brasero does not see it. xorriso shows that the
drive is already in the bad state.

So i did a power cycle with empty ASUS tray.

Before starting Brasero i insert the CD-RW into the ASUS drive.
Brasero sees it when starting up. So i can start the burn run.
It gets to "Success", throws SCSI error 5,21,04, 1 minute of no action,
then "Creating image Checksum", 1 minute of no action, then a new window
pops up: "Error while burning. The drive is busy" and the drive is spoiled.

So it is quite surely not about the kernel version.

(But i meanwhile suspect that the SCSI error 5,21,04 is generated by
the kernel and not by the drive. It does not happen with USB, it is outruled
by the specs for optical drives, and i cannot imagine what command could
be considered unaligned by the drive.)

[Mauro Sacchetto]

I don't have the option of using more than one burner.

I had done a simple experiment by installing Brasero (obviously with all its dependencies) on the partition where I have Stable with KDE. So different kernel and different version of Brasero. The behavior is the same as that found in Testing with Cinnamon.

It is difficult to understand how we can get out of it.

In any case from the console, both with wodim and with xorriso, it is possible to burn correctly, or by installing K3b, even if on Cinnamon it requires 125 packag

[Mark Allums]

I just successfully burned a cd-rw with Debian netinst 11.1.0 .iso on
sid using Brasero 3.12.3 using an LG Blu-Ray: HL-DT-ST BD-RE WH14NS40.

negative results are still results. :)

Mark A.

[Thomas Schmitt]

Hi,

Mauro Sacchetto wrote:
> I don't have the option of using more than one burner.

I could try with more USB burners. But we already know that it is a
problem between Brasero or its helper software on one side and the
firmware of ASUS DRW-24D5MT on the other side.
There may be other burner firmwares with the same vulnerability.
But finding them would not bring more insight.

(Of course i will keep this possibility in mind for occasions when
other Brasero users report similar problems.)

> It is difficult to understand how we can get out of it.

I lack of a plausible theory how Brasero or its helpers can spoil
the drive when Brasero is up and waiting for a disk to appear in the
drive.

I meanwhile have ideas for more experiments:

- Does it happen only with CD but not with DVD+RW or DVD-RW ?
I will probably test this today.

- Does it work if i manage to permanently disable udisks ?
(I once did this on Debian 8. But memories are dim and udisks quite
surely evolved a lot since then.)
I will have to find out about udisks configuration.
Simply killing its two processes does not help. I tried and they
came back.
Any hints are welcome.

- Does it happen when the ASUS burner is in a USB box ?
If no: Does it depend on the maximum speed of the SATA port ?
(See below the quote from the Manjaro thread.)
This will mean that i have to break out my screw driver and the docs
about the mainboard. (Me and a screw driver is a dangerous combination.)
Update:
The docs say that my mainboard ASUS Pro WS C246-ACE has 4 SATA 6.0 Gb/s
ports and no slower SATA ports. So a port change looks not very
promising.

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

If Brasero had a maintainer and that maintainer has no better idea about
the particular cause of this quite catastrophic behavior, then i would
propose that Brasero shall try early to identify the drive model name,
and refrain from doing anything more with the drive if it is an ASUS
DRW-24D5MT (and maybe other types which might be found by users).

It should first try to learn the drive model name from udev, so that it
does not have to touch the drive by itself. If udev does not tell, then
it would have to issue an SCSI INQUIRY command, which will tell the drive
type.

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

The software side of the problem seems old enough to have left traces in
the web. But there are not so many found by Google:

I now learn that i participated in a german thread without noticing that
Brasero is at the core of the problem:
https://forum.ubuntuusers.de/topic/problem-mit-dvd-rw-laufwerk-sata/
The thread starter reports at some stage that he succeeded with Brasero
and CD. But we have to take such statements with a grain of salt. In the
end he bought another drive and got happy.

In
https://forum.manjaro.org/t/solved-asus-cd-writer-installation-issues/37659
i see an interesting but riddling success report:
"I moved the device on the MB from SATA 5 to SATA 6 and everything
run smoothly"
I assume the poster means the numbering of the SATA ports on the board.
It is fewly plausible that Mauro Sacchetto and i both have bad SATA ports
or cables.
But what about SATA generations ? Maybe that board has ports for 3 Gbps
and for 6 Gbps which makes a difference.

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

[Thomas Schmitt]

Hi,

the drive and Brasero work with DVD+RW, unformatted DVD-RW, and
formatted DVD-RW.
No bad symptoms to see, except that i get molested by the automounter
and that i often have to repeatedly double click the drive field and
the "Burn" button before burning begins.

These successes give me the idea that the culprit is some software which
wants to play the CD as audio CD. This needs a different SCSI command for
reading. It's name is READ CD and it can be told to require CD-DA sectors
of 2352 bytes rather than the 2048 bytes of data CD sectors.
This would somehow explain the SCSI error "unaligned write", which then
actually would rather mean "unaligned read".
(This imposes the riddle why the TSSTcorp drive in the USB box does not
cause such an SCSI error message.)

------------------------------------------------------------------------
Tests made:

First i put the DVD+RW into the ASUS and start Brasero. The DVD gets found
and after a few double clicks on the drive field, the Burn button finally
works and "Burning" begins. "Finalizing", "SUCCESS", "Checksum",
loud reading, "Ejecting medium".
No SCSI error.
xorriso -toc shows the written session.
dd if=/dev/sr0 bs=2048 count=193536 | md5sum
yields the correct MD5.
(That @#$%^ automounter mounted it without asking me. Some other software
pops up the window offering to start the file manager.)

Next try: Brasero starts up with empty tray. Then i put in the DVD+RW from
which i removed the ISO 9660 superblock by xorriso -blank.
All works fine. No SCSI error message.

Now with unformatted DVD-RW, fast blanked by
xorriso -outdev /dev/sr0 -blank deformat_quickest
This yields a medium state that is only suitable for write type DAO,
which can only take a single session. The DVD-RW is an old 2x speed type.
Full blanking would last about 40 minutes.
Starting Brasero while the DVD is in the ASUS drive.
All is well. Just half as fast as with the DVD+RW.

Now after formatting the DVD-RW by unmounting (grrrr) and this run:
xorriso -outdev /dev/sr0 -format as_needed
which lasts 40 minutes, i can burn and the drive stays usable.

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

[Mauro Sacchetto]

I actually managed to burn a blank CD-RW with brasero as well.
The problem arises when the CD-RW already has content.

Do you have any idea what software might be doing this anomalous attempt,
which is to try to read the data CD as if it were audio?

Given their modest cost, I can of course also buy a more reliable burner.
Have you encountered any models that offer greater guarantees than the ASUS in my possession?

Thank you

Il 09/11/21 14:41, Thomas Schmitt ha scritto:

[Thomas Schmitt]

Hi,

Mauro Sacchetto wrote:
> I actually managed to burn a blank CD-RW with brasero as well.
> The problem arises when the CD-RW already has content.

Not for me. Blank CDs behave better with the automounter (but not with
the prompt window which offers me to start the file manager).
But when they are written, Brasero gets stuck after the checkreading
stage and the drive is then unusable until power cycle.

I think we have different desktop systems:
You tested with GNOME or KDE, i tested with XFCE (which i plan to replace
by fvwm2 to get rid of the file manager prompt).
Normally this should make no difference. But if it is about unwanted
disc groping, the desktop is indeed a suspect.

> Do you have any idea what software might be doing this anomalous attempt,
> which is to try to read the data CD as if it were audio?

Not yet. I normally don't use desktops but rather a window manager
and i hate the kind of perky automats which i see on Debian 10 XFCE when
i insert a medium or Brasero is done with writing a medium.
Actually i use that machine mainly headless via ssh from an older machine
which fits me like an old shoe.

When i managed to get rid of XFCE i will try whether Brasero alone is
able to spoil the drive. (I'd expect so, because the desktop's automats
have enough opportunity to grope the medium after a xorriso run, but
don't spoil the ASUS DVD burner.)


> Given their modest cost,

... which might be part of the problem. What costs nothing is nothing.

My ASUS was the second attempt to get a new DVD burner after a
HL-DT-ST (LG) GH24NSC0 became unrealiable after only 2.5 years.
The first new one was a Lite-On which could not read what it had written.
I sent it back and got the ASUS as replacement.
It works well for me, as long as i don't let Brasero act on CD media.

All three burners were at sale for less than 20 dollars. (I pay in EUR.)

Half of my burners are from LG. But this is only due to what was offered
when i wanted a new drive. I have a very good ASUS BW-16D1HT, a noisy
Optiarc BD-5300S (company has vanished), 4 LGs, a Samsung SH-S223B,
and a Pioneer BDR-S09.
Most of them never had to suffer a Brasero burn run. :))

(The Pioneer grips so hard and rotates so fast that modern Verbatim BD-RE
media get cracks at the inner hole after having been read 20 times by it.
Old Verbatims and modern Primeon BD-RE survive undamaged. I blame it on
engraved letters on the modern Verbatim media which are very near to
the inner rim, i.e. the place where the drive grips the medium.
The Pioneer does not react on read speed settings but delivers data at
maximum speed as long as the reader consumes that fast. I had to enhance
libburn so that it can enforce a lower read speed by waiting between READ
commands. At 6x BD speed = 27 MB/s the Verbatim BD-RE survive without
cracks. This speed makes much fewer noise than the drive's favored 10x.)

> Have you encountered any models that offer greater guarantees than the ASUS
> in my possession?

Normally they are ill only individually. The fact that our two burners
of the same model fail in a very similar way is really unusual.

It seems that Blu-ray drives are of better quality than drives which can
only do CD and DVD. The BD drives cost about four times what DVD drives
cost, although BD differs from DVD only by the presence of the third (blue)
laser. The mechanics are mostly the same. DVD drives have only two lasers:
infrared for CD and red for DVD.

[Thomas Schmitt]

Hi,

the spoiled ASUS drive does not seem to be a direct result of an attempt
to read audio CD sectors from a data CD.
The drive is rather too tolerant in that aspect. The MMC-5 specs say
that it should throw error 5,64,00 "ILLEGAL MODE FOR THIS TRACK", but
the drive doesn't.

It does not go bad either.
So my nice theory about READ CD causing the SCSI error about unaligned
writing is officially dead.

And i have an unexpected casualty to bemoan ...

---------------------------------------------------------------------
Experiments made:

I removed the security barrier in cdrskin which prevents reading of
data CDs as audio CDs and told it to read a CD with data as audio:

mkdir audio_test

cdrskin -V -v dev=/dev/sr0 extract_audio_to=audio_test \
>audio_test/scsi_log 2>&1

Normally it says:

cdrskin: WARNING : Track 01 is not an audio track.
cdrskin: SORRY : Medium in drive is not an audio CD.

but now it reads to my big surprise the whole track into file
audio_test/01.wav .

The scsi_log shows READ CD commands which demand CD-DA sectors and get
data back without error indication:

READ CD
be 04 00 00 00 00 00 00 18 10 00 00
841123 us [ 4002657 ]

The resulting file is too large, because CD-ROM checksums and other
non-data parts of the CD sectors where read together with the CD-ROM
payload data. Divided by 2352 the number of read bytes gives the
number of sectors of the track as announced by the CD table-of-content.

To prove that the specs are normally obeyed, i insert the same CD into
the TSSTcorp drive at /dev/sr2 and execute the cdrskin command (without
option -V because i need no SCSI log). The drive takes duely offense:

cdrskin: Writing audio track file: audio_test/01.wav
cdrskin: SORRY : SCSI error on read_cd(0,0): [5 64 00] Illegal request. Illegal mode for this track.
cdrskin: SORRY : SCSI error on read_cd(0,0): [5 64 00] Illegal request. Illegal mode for this track.

but next the device file vanishes

cdrskin: FAILURE : Failure to read audio sectors
cdrskin: FATAL : Failed to transfer command to drive
cdrskin: ( Most recent system error: 19 'No such device' )
cdrskin: FATAL : --- SG_IO: return= -1 , errno= 19 , host_status= 0x0 , driver_status= 0x0
cdrskin: FATAL : Attempted command: TEST UNIT READY : 00 00 00 00 00 00
cdrskin: FATAL : Lost connection to drive

dmesg reports of repeated USB disconnect and connect going on.
No power cycle helps. It seems that the USB hub went mad. Unplugging and
replugging it into another mainboard USB port does not help.
A very unexpected victim of a drive and media experiment.

The drive comes back to life after i removed the hub and plugged the
drive's USB box cable directly into the mainboard USB port.

Violating SCSI specs brings bad luck. I won't ever repeat this test.
(I am not superstitious, because superstition brings even more bad luck.)

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

[Mauro Sacchetto]

I smoothly burned the same ISO with Brasero to a DVD + RW, and the media was recognized immediately. On the other hand, the identification of the CD-RW is much slower (apart from the fact that the burn then fails) and this suggests that something else "occupies" the disc already, which is why Brasero does not find it and considers it unsupported. And let's go back to your hypotheses: either there is a perverse interaction between a Brasero component and the ASUS burner, or there is something else that interferes as soon as the media is inserted and before Brasero takes possession of it, which at this point does not manages to do. If there is any other test I can do (difficult, after all the ones you have done), I am always available. And thanks for your work!

Il 09/11/21 16:44, Thomas Schmitt ha scritto:

[Thomas Schmitt]

Hi,

what i believe to have learned so far:

- The problem is a co-operation of ASUS DRW-24D5MT and Brasero or
some software which Brasero employs. This other software (if involved
at all) does not strike with K3B (tested by Mauro Sacchetto) or
non-GUI burn programs like wodim or xorriso.

- The problem happens only with CD media. This media family is the most
complicated among the optical media, because it not only can record
data blocks of 2048 bytes per sector but also other sector types
like CD-DA with 2352 bytes.

- Reading data CD by audio CD commands is supposed to fail on the first
read attempt, but the ASUS DRW-24D5MT tolerates this against the SCSI
specs. The drive announces the obsolete feature 103h "CD Audio External
Play Feature". (PIONEER BDR-S09 does not. TSSTcorp SH-S223B does, but
throws the specified error when reading data CD as audio CD.)
Weak theory:
This tolerance might lure Brasero or other software into sending SCSI
commands which are inappropriate with data CD, like the obsolete SCAN
command or the obsolete STOP PLAY/SCAN command. These commands were
obsoleted in 2006 by MMC-5 together with the PLAY AUDIO and other
commands which were specific to standalone playing of audio CD.
(All drives still support READ CD which can be used to read audio
CD into the computer and let its media players create sound.)

- There seems to be involved a difference between Cinnamon of Debian
Testing and XFCE of Debian 10. While Mauro Sacchetto does not get an
unusable drive with Brasero and a blank CD-RW on Cinnamon, i get to
that problem after writing succeeded but before the checksum gets
verified by Brasero. (The CD verifies good in another drive by
comparing the MD5s of ISO image and CD.)
With non-blank CD-RW i experienced sometimes the problem already
after inserting it into the ASUS drive while Brasero is running.
Mauro Sacchetto did not report such an early problem.

--------------------------------------------------------------------
Open questions:

- Would it happen without desktop ?
E.g. with fvwm2 as window manager.

- Is udisks involved ?
It seems to be very eager to automount as soon as the CD contains
data. When i kill its process, they come back quickly.

- Is the XFCE (?) window involved which offers a file manger even for
blank CDs when they get inserted ?

- Is the way of attachment of the drive to the computer involved ?
My TSSTcorp drive offers obsolete CD audio commands but is in a
USB box, whereas the ASUS is directly at SATA.

- Why does only Brasero invite the problem ?

[Mauro Sacchetto]

I again carried out a small experiment (as a simple user as I am) and
precise,
or rather I correct, what was stated in a previous email.
Burning an ISO to a blank CD-RW (after: wodim dev=/dev/sr0 -v
blank=fast) won't work either:
This is brasero-session.log:
================================================================================
Checking session consistency (brasero_burn_check_session_consistency
brasero-burn.c:1739)
BraseroBurnURI called brasero_job_get_action
BraseroBurnURI called brasero_job_get_action
BraseroBurnURI called brasero_job_set_output_size_for_current_track
BraseroBurnURI stopping
BraseroBurnURI called brasero_job_get_action
BraseroBurnURI called brasero_job_get_session_output_size
BraseroBurnURI output set (IMAGE) image = /tmp/brasero_tmp_OFOIC1.bin
toc = none
BraseroBurnURI called brasero_job_get_session_output_size
BraseroBurnURI called brasero_job_get_action
BraseroBurnURI called brasero_job_get_current_track
BraseroBurnURI no burn:// URI found
BraseroBurnURI stopping
BraseroLocalTrack called brasero_job_get_action
BraseroLocalTrack called brasero_job_get_action
BraseroLocalTrack called brasero_job_set_output_size_for_current_track
BraseroLocalTrack stopping
BraseroLocalTrack called brasero_job_get_action
BraseroLocalTrack called brasero_job_get_session_output_size
BraseroLocalTrack output set (IMAGE) image = /tmp/brasero_tmp_JEOIC1.bin
toc = none
BraseroLocalTrack called brasero_job_get_session_output_size
BraseroLocalTrack called brasero_job_get_action
BraseroLocalTrack called brasero_job_get_current_track
BraseroLocalTrack no remote URIs
BraseroLocalTrack stopping
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_flags
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_fd_in
BraseroChecksumImage called brasero_job_set_output_size_for_current_track
BraseroChecksumImage stopping
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_flags
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_session_output_size
BraseroChecksumImage output set (IMAGE) image =
/tmp/brasero_tmp_VVNIC1.bin toc = none
BraseroChecksumImage called brasero_job_get_session_output_size
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage called brasero_job_get_input_type
BraseroChecksumImage called brasero_job_set_current_action
BraseroChecksumImage called brasero_job_get_fd_in
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage Starting checksuming file
/home/samiel/debian-11.1.0-amd64-netinst.iso (size = 396361728)
BraseroChecksumImage called brasero_job_get_fd_out
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage Setting new checksum (type = 2)
b710c178eb434d79ce40ce703d30a5f0 ((null) before)
BraseroChecksumImage Finished track successfully
BraseroChecksumImage stopping
BraseroLibburn called brasero_job_get_action
BraseroLibburn called brasero_job_get_action
BraseroLibburn unsupported operation
BraseroLibburn deactivating
BraseroLibburn called brasero_job_get_action
BraseroLibburn called brasero_job_get_action
BraseroLibburn called brasero_job_get_device
BraseroLibburn Drive (/dev/sr0) init result = 1
BraseroLibburn called brasero_job_get_flags
BraseroLibburn called brasero_job_get_media
BraseroLibburn called brasero_job_get_fd_in
BraseroLibburn called brasero_job_get_tracks
BraseroLibburn Setting multi 0
BraseroLibburn Setting burnproof 1
BraseroLibburn Setting dummy 0
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn burn_drive_convert_fs_adr( /dev/sr0 )
BraseroLibburn Writing
BraseroLibburn called brasero_job_set_dangerous
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn burn_drive_is_enumerable_adr( /dev/sr0 ) is true
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn Async START UNIT succeeded after 0.1 seconds
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn Allocating buffer via mmap()
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn cd Profile= 0Ah , obs= 32768 , obs_pad= 0
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn TAO pre-track 01 : get_nwa(0)=1, d=0 , demand=396361728 ,
cap=736966656

BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
...BraseroLibburn syncing cache
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn called brasero_job_get_session_output_size
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn Async SYNCHRONIZE CACHE  succeeded after 0.3 seconds
BraseroLibburn Closing
BraseroLibburn called brasero_job_set_dangerous
BraseroLibburn called brasero_job_set_current_action
BraseroLibburn Closing session
BraseroLibburn Async CLOSE TRACK/SESSION  succeeded after 6.0 seconds
BraseroLibburn Writing
BraseroLibburn Writing
BraseroLibburn Write thread on drive 0 ended
BraseroLibburn called brasero_job_set_dangerous
BraseroLibburn Finished successfully session
BraseroLibburn stopping
Preparing to checksum (type 2 b710c178eb434d79ce40ce703d30a5f0)
(brasero_burn_record_session brasero-burn.c:2483)
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_flags
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage creating input
BraseroChecksumImage called brasero_job_get_action
BraseroReadom called brasero_job_get_action
BraseroReadom linked to BraseroChecksumImage
BraseroReadom getting varg
BraseroReadom called brasero_job_get_action
BraseroReadom called brasero_job_get_current_track
BraseroReadom called brasero_job_get_output_typeBraseroChecksumImage
called brasero_job_get_action

BraseroReadom called brasero_job_get_current_trackBraseroChecksumImage
called brasero_job_get_current_track

BraseroReadom called brasero_job_get_output_type
BraseroChecksumImage called brasero_job_set_current_action
BraseroReadom reading from sector 0 to 193536
BraseroChecksumImage called brasero_job_get_current_trackBraseroReadom
called brasero_job_get_fd_out

BraseroChecksumImage called brasero_job_get_fd_inBraseroReadom called
brasero_job_set_use_average_rate

BraseroReadom got varg:BraseroChecksumImage Starting checksum generation
live (size = 396361728)

    readomBraseroChecksumImage called brasero_job_set_nonblocking

    dev=/dev/sr0BraseroChecksumImage called brasero_job_get_fd_in

    -nocorr
BraseroChecksumImage called brasero_job_get_fd_out    -noerror

BraseroChecksumImage called brasero_job_get_fd_in -sectors=0-193536

BraseroChecksumImage called brasero_job_get_fd_out    -f=-

BraseroReadom Launching command
BraseroReadom called brasero_job_get_fd_in
BraseroReadom called brasero_job_get_fd_out
BraseroReadom stderr: readom: Device not ready.
BraseroReadom called brasero_job_error
BraseroReadom finished with an error
BraseroReadom asked to stop because of an error
    error        = 5
    message    = "L'unità è occupata"
BraseroReadom stopping
BraseroReadom got killed
BraseroReadom disconnecting BraseroReadom from BraseroChecksumImage
BraseroChecksumImage stopping
BraseroChecksumImage closing connection for BraseroChecksumImage
Session error : L'unità è occupata (brasero_burn_record brasero-burn.c:2854)
================================================================================
And in fact:
================================================================================
samiel@darkstar:~$ md5sum /dev/sr0
md5sum: /dev/sr0: Input/output error
================================================================================





Il 10/11/21 13:09, Thomas Schmitt ha scritto:

[Thomas Schmitt]

Hi,

i managed to start fvwm2 (by Ctrl+Alt+F2 in the XFCE login window and
startx /usr/bin/fvwm2) and tried whether Brasero and ASUS drive have a
better relationship then.
They don't. It's as bad as with XFCE.

The Brasero run was started with a blank CD-RW in the drive and came,
with two pauses of a minute, up the "Checkreading" stage. Then it
complained that the drive was in use and the ASUS drive went unusable
as with the XFCE tests.

After a power cycle i verified that the CD was burned completely and
tried whether readom is to blame:

readom dev=/dev/sr0 f=cdimage.raw

It isn't. The drive stays usable after aborting readom with Ctrl+C because
it was stuck with futile retries to read the two TAO Run-out sectors at
the end of the track. The MD5 of cdimage.raw then matches the ISO image.

The CD does not get automounted with fvwm2. So this aspect of XFCE is
not a suspect any more.

[Mauro Sacchetto]

On Testing / Cinnamon it's impossible too "copy a disk"

(another voice of Brasero menu)

The CD-RW seems to be recognized and the burning begins,

but fails with:

Session error : Impossibile bloccare l'unità ((null))
(brasero_burn_record brasero-burn.c:2854)

that is (more or less): "Impossible to block unity".


The same on Stable / KDE with Brasero further installed

(obviously with all its dependencies).

After Brasero fails, it's impossible to erase the CD with K3,

and it's necessary to reboot ("No disk on /dev/sr0")

After reboot, K3B recognize the presence of the CD and blank it.

So, in Xfce, Cinnamon or KDE, the trouble is present



Il 11/11/21 15:12, Thomas Schmitt ha scritto:

[Simon McVittie]

On Mon, 08 Nov 2021 at 17:15:26 +0100, Thomas Schmitt wrote:
> I start Brasero and a window pops up which says it cannot mount the CD.
> (How stupid can Brasero and udisks become ? Is there any limit ?)

My understanding is that udisks does not automatically mount anything on
its own (it's designed to be mechanism, not policy), but your desktop
environment might contain a component that provides the policy part
and asks udisks to mount media.

I would expect a desktop environment that does that to have configuration
for whether that component is active or not. In GNOME, it's the
Removable Media panel in the Settings app (gnome-control-center).

If you're using a purely XFCE system, thunar-volman is probably the
component responsible for mounting removable media. I don't know how
or whether that can be configured.

smcv

[Thomas Schmitt]

Hi,

Mauro Sacchetto wrote:
> that is (more or less): "Impossible to block unity".

"unit", maybe ? The device.

> After Brasero fails, it's impossible to erase the CD with K3,

Either Brasero did its evil deed before trying to lock the unità or the
failure to do so did not prevent further access to the drive.

Do i get it right that you ordered Brasero to copy the CD to an
image file, not a second CD/DVD/BD drive ?

Something in Brasero's own activities for drive and medium inspection
must be to blame. I will try the "Copy" task with fvwm tomorrow,
just to be sure that it's not about the desktops.

I wrote:
> > (How stupid can Brasero and udisks become ? Is there any limit ?)

Simon McVittie wrote:
> My understanding is that udisks does not automatically mount anything on
> its own

Indeed it looks like that. With fvwm instead of XFCE the pop-up windows
and the automounting don't happen. My apologies towards udisks.

> If you're using a purely XFCE system, thunar-volman is probably the
> component responsible for mounting removable media.

So curses towards thunar-volman ... and an apology because this is
off-topic now that i have seen the problem with fvwm, too.


Two of my questions in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998718#110
are answered:
- Would it happen without desktop ? = Yes.

- Is the XFCE (?) window involved which offers a file manger even for

blank CDs when they get inserted ? = No

There are no indications that automats outside of Brasero have a stake
in the problem.

[Mauro Sacchetto]

Il 11/11/21 22:49, Thomas Schmitt ha scritto:

> Hi,
>
> Mauro Sacchetto wrote:
>> that is (more or less): "Impossible to block unity".
> "unit", maybe ? The device.

Yes, sorry for my bad English.

>> After Brasero fails, it's impossible to erase the CD with K3,
> Either Brasero did its evil deed before trying to lock the unità or the
> failure to do so did not prevent further access to the drive.
>
> Do i get it right that you ordered Brasero to copy the CD to an
> image file, not a second CD/DVD/BD drive ?
>
> Something in Brasero's own activities for drive and medium inspection
> must be to blame. I will try the "Copy" task with fvwm tomorrow,
> just to be sure that it's not about the desktops.

Yes: for I have only a drive, fist the Cd is copied in an image on HD,

and then the image burned in a new support in the same drive

> Simon McVittie wrote:
>> My understanding is that udisks does not automatically mount anything on
>> its own

If I'm not wrong, the CD is not automaticalli mounted.

I see its name in Nemo -- Devices, but it needs a double click

to mount it and to inspect its content

[Thomas Schmitt]

Hi,

the "Copy" task yields very interesting results:

A closed CD-R and a closed CD-RW which were written by write type SAO
don't spoil the drive.
Inserting a closed TAO CD-RW (burnt by Brasero) spoils the drive.
This spoiling is in effect already when the dialog window of Brasero asks
me to submit a medium or to choose a drive for copying.

dmesg shows:

[ 715.623542] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 715.623564] ata3.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 13
Volume set (in), Read cd be 00 ff ff ff ff 00 00 01 10 00 00res 40/00:02:00:00:02/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 715.623570] ata3.00: status: { DRDY }
[ 715.623577] ata3: hard resetting link
[ 715.938617] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 715.944589] ata3.00: failed to IDENTIFY (device reports invalid type, err_mask=0x0)
[ 715.944594] ata3.00: revalidation failed (errno=-22)
[ 720.963384] ata3: hard resetting link
[ 721.278510] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 726.339201] ata3.00: qc timeout (cmd 0xa1)
[ 726.339213] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 726.339217] ata3.00: revalidation failed (errno=-5)
[ 726.339223] ata3.00: disabled
[ 726.654802] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 726.654833] ata3: EH complete
[ 726.660786] sr 2:0:0:0: [sr0] tag#16 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
[ 726.660788] sr 2:0:0:0: [sr0] tag#16 CDB: Test Unit Ready 00 00 00 00 00 00

(As one can see, the kernel's hard resetting the link does not help.)

The line [715.623564] tells that the bad command was BEh READ CD for
sector -1.
This only looks wrong, but isn't by itself, because CDs have a Lead-in
which usually starts at sector -150.

Before that experiment i already learned something new about CDs
from reading brasero source code about media inspection:

The function brasero_medium_track_written_SAO() looks for an indication
that the CD was written with TAO or Packet
https://sources.debian.org/src/brasero/3.12.3-1/libbrasero-media/brasero-medium.c/#L1576

MMC-5 4.2.3.12 "The Track Descriptor Block" specifies this indication
for non-SAO CD to be in each block of the "pre-gap", which preceeds the
payload of the track. I.e. sector -1 is such a Track Descriptor Block.
This is a valuable information for possibly avoiding the readahead bug
with TAO CDs.

I was tempted to explore this trick myself for libburn. But now i think
that it could be the gesture which does not play well with the ASUS
DRW-24D5MT.

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

Now i will probably need some help by the GNOME community:
How to build Brasero from source ?

ldd /usr/bin/brasero | wc -l
yields a library count of 115. Ewww.

Although i know how to prepare the .deb packages of libburn on salsa and
to test-build them on a virtual Sid, i expect that Brasero is more effort.
In genral i am not trustworthy as operator beyond apt-get "update",
"dist-upgrade", and "install".

My plan for an experiment would be to let function
brasero_medium_track_written_SAO()
immediately and unconditionally return FALSE without any read experiment.

(This might confuse Brasero at the end checkreading. But i know that
the errors from reading the Run-out blocks on the ASUS do not yield a
spoiled drive.)

Some instructions how to achieve such a change in Brasero would be highly
welcome.

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

Next problem of me unskilled Brasero user:

I was not able to talk Brasero into showing me its session log for the
failed "Copy" run. If my new theory is right there should be a log line
"Checking for TDBs in track pregap."
before nothing works any more.
It would be interesting to see the log of a successful medium inspection
on one of the two other drives whether the "TDBs" got really checked.
But i don't know how to get the log of a successful run.
Best would be to let Brasero log into its start terminal from the
very beginning.

Does somebody have instructions for me how to achieve such a visible log ?

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

[Thomas Schmitt]

Hi,

am i too stupid or is there really no user option to set write type SAO ?

Neither clicking around in Brasero's GUI nor searching for
BRASERO_BURN_FLAG_DAO in the source brings any insight.

I want to burn a blank CD with SAO in order to check whether this avoids
the problem with the ASUS drive at the end of burning.

(SAO would be set by libburn API call burn_write_opts_auto_write_type()
if the struct burn_disc, which will be used for burning, already has
its burn_track objects attached and all track sources have a predictable
size.
The libburn plugin of Brasero would call burn_write_opts_set_write_type()
with BURN_WRITE_SAO if flags from brasero_job_get_flags() would have the
BRASERO_BURN_FLAG_DAO bit set.
https://sources.debian.org/src/brasero/3.12.3-1/plugins/libburnia/burn-libburn.c/?hl=526#L526
)

It looks like the wodim plugin uses SAO by default.
But i fail to activate this plugin.

[Mauro Sacchetto]

I'm not sure it is what are you searching for,

but Brasero produces a log launching from console it by :

brasero -g --brasero-media-debug > log 2>&1

Then , I choose "Disk copy" and find ~/log




Il 12/11/21 13:25, Thomas Schmitt ha scritto:

[Thomas Schmitt]

Hi,

Mauro Sacchetto wrote:
> brasero -g --brasero-media-debug > log 2>&1

(After knowing the magic words i find man pages in the web which have it.)

In the log from a successful Copy job with the Pioneer drive (sr1) i do
not see the message about "TDB".

But in the log of an immediate failure with the TAO CD in the ASUS
drive, i see:

BraseroMedia: (at brasero-drive.c:983) No medium inserted
BraseroMedia: (at brasero-medium.c:1738) Following two sectors are readable.
BraseroMedia: (at brasero-medium.c:1573) Checking for TDBs in track pregap.

A problem with this log seems to be that the messages for both drives
are intermixed without an indication which drive is meant.
I assume that the "No medium inserted" is for empty sr1.

So i cannot really tell from comparing both logs what triggers the TDB
check on the ASUS or what prevents it on the Pioneer.
But the Debian code search for "Following two sectors are readable"
yields a suspect:

https://sources.debian.org/src/brasero/3.12.3-1/libbrasero-media/brasero-medium.c/?hl=1738#L1738

The call brasero_medium_track_written_SAO() is made only if

/* Test the last block, the before last and the one before before last */
result = brasero_mmc1_read_block (handle,
...
yields
result == BRASERO_SCSI_OK

This seems to be true with the ASUS but not with the Pioneer.
The log message immediately before "Following two sectors ..." is to see in
both logs and seems to be falsely issued:

BraseroMedia: (at brasero-medium.c:1715) Data track belongs to first session of multisession CD. Checking for real size (193536 sectors currently).

Both logs have

BraseroMedia: (at brasero-medium.c:2062) 2 track(s) found

but the CD-RW is closed and has only one session with one track.
If not the parameter "multisession" was set with the call of
brasero_medium_track_get_info() then we possibly would not have this
lengthy bug discussion.

Well, i will know for sure only after i hacked libburn to issue such
a READ CD command for sector number -1 with exactly the same CDB bytes
as reported by dmesg:

[20205.014237] ata3.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 5

Volume set (in),
Read cd be 00 ff ff ff ff 00 00 01 10 00 00

res 40/00:03:00:00:00/00:00:00:00:00/a0
Emask 0x4 (timeout)

If this experiment makes the drive stuck, then we have the culprit.

Hmm ... i dimly remember a project to send SCSI commands from the shell.
Google brings me to sg_raw of sg3-utils. Looks like we have it.
https://manpages.debian.org/testing/sg3-utils/sg_raw.8.en.html

Probably:

sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 \
--outfile=tdb_data.bin

I will explore this later this weekend.

[Thomas Schmitt]

Hi,

i now have clear evidence from a run of

sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin

that the read attempt for sector 0xffffffff (= -1) brings the
ASUS DRW-24D5MT into the unusable state.

@ Mauro Sacchetto:
Could you please try to reproduce this finding after installing sg3-utils.


The main suspect for emitting SCSI this command is Brasero function
brasero_medium_track_written_SAO()
in libbrasero-media/brasero-medium.c .

Code study of that function and the logs of Brasero "Copy" runs with
the Pioneer and the TSSTcorp show that bad things happen if the function
is called:

- The Pioneer drive does not trigger the log message from
brasero_medium_track_written_SAO()
and leaves no problem report lines in dmesg.
So i conclude that the function was not called.

- The TSSTcorp drive triggers this message:

BraseroMedia: (at brasero-medium.c:1573) Checking for TDBs in track pregap.

and dmesg reports a (successful / harmless ?) USB reset.

-------------------------------------------------------------------------
Possible remedies:

We would need a Brasero developer to find a workaround, because not
only the bad READ CD command needs to be avoided, but also a replacement
for the code gesture to distinguish TAO CDs from SAO CDs would have to
be developed.

Maybe this distinction is not really necessary. It seems not to work
properly on the TSSTcorp drive by making a false correction of the
track size. But that would be up to a Brasero developer to decide.

A cheaper workaround would be to identify the drive model from the
function parameter
BraseroDeviceHandle *handle
and to return before any read attempt if it is an ASUS DRW-24D5MT
and maybe others, which still need to have been found.
Again it would be up to a Brasero developer to decide whether TRUE or
FALSE would be the best reply in this case.

Maybe it would be possible to read that sector by SCSI command
READ CD MSF with address 00:01:74.
(The track begins at 00:02:00. Brasero wants one sector before that
start which to my computation would be 00:01:74.)

-------------------------------------------------------------------------
Experiments made:

I tried the "Copy" task of Brasero with the TSSTcorp drive in its USB box
at /dev/sr2.

Other than with the Pioneer at /dev/sr1, this run reports

BraseroMedia: (at brasero-medium.c:2062) 2 track(s) found

BraseroMedia: (at brasero-medium.c:1645) Retrieving track information for 1
BraseroMedia: (at brasero-medium.c:1715) Data track belongs to first session of multisession CD. Checking for real size (193686 sectors currently).

BraseroMedia: (at brasero-medium.c:1573) Checking for TDBs in track pregap.

BraseroMedia: (at brasero-medium.c:1742) Correcting track size (now 193688)

which indicates that Brasero thinks this CD was written with write
type SAO.
But i burnt it with xorriso -as cdrecord -tao. libburn's demo program
telltoc reports that blocks 193687 and 193688 are not readable and thus
supposes the CD to be burnt by TAO.
Later the log confrims telltoc's findings:

BraseroBurn: (at burn-process.c:417) BraseroCdrdao stderr: Found L-EC error at sector 193686 - ignored.
BraseroBurn: (at burn-job.c:1430) BraseroCdrdao called brasero_job_get_action
BraseroBurn: (at burn-process.c:417) BraseroCdrdao stderr: Found L-EC error at sector 193687 - ignore

("L-EC error" would mean a medium problem. So the drive maybe contributes
to the confusion of Brasero. dmesg reports the same errors, probably from
blkid inspecting the medium for an UDF anchor.)

dmesg reports around the time when Brasero was inspecting the drive:

usb 1-13: reset high-speed USB device number 5 using xhci_hcd

and with another "Copy" task again:

usb 1-13: reset high-speed USB device number 5 using xhci_hcd

Whatever, the drive stays usable and no error of READ CD for sector
0xffffffff is reported in dmesg.

--------------------------------
Poking manually into that drive:

# apt-get install sg3-utils

$ sg_raw /dev/sr2 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin
>>> transport error: Host_status=0x03 [DID_TIME_OUT]
Driver_status=0x00 [DRIVER_OK]
SCSI Status: Good

and another USB device reset is reported in dmesg

usb 1-13: reset high-speed USB device number 5 using xhci_hcd

Still the drive is usable afterwards.

----------------------------------------------------
Now the decisive test with /dev/sr0, the ASUS drive:

No Brasero is running.
After inserting the CD into /dev/sr0, i see in dmesg complaints about
i/o errors with the last two blocks. This time not "L-EC error" but
rather "Illegal Request", as i would expect from the specs.

The drive is usable for xorriso.

So:

$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin
SCSI Status: Check Condition
Sense Information:
Fixed format, current; Sense key: Illegal Request
Additional sense: Unaligned write command

dmesg reports

ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

ata3.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 11
Volume set (in), Read cd be 00 ff ff ff ff 00 00 01 10 00 00res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: hard resetting link

The drive is now unusable for xorriso:

libburn : FAILURE : SCSI command 12h yielded host problem: 0x4 SG_ERR_DID_BAD_TARGET (Bad target, device not responding ?)
libburn : FAILURE : Command: INQUIRY : 12 00 00 00 24 00 : dxfer_len= 36

dmesg reports about this xorriso attempt:

sr 2:0:0:0: [sr0] tag#15 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
sr 2:0:0:0: [sr0] tag#15 CDB: Test Unit Ready 00 00 00 00 00 00

So i can now trigger the drive problem without Brasero.

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

I think my skills as burn programmer are exhausted now.

[Mauro Sacchetto]

Il 14/11/21 12:02, Thomas Schmitt ha scritto:

Hi,

i now have clear evidence from a run of

  sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin

that the read attempt for sector 0xffffffff (= -1) brings the
ASUS DRW-24D5MT into the unusable state.

@ Mauro Sacchetto:
Could you please try to reproduce this finding after installing sg3-utils.

I obtain

=======================================================

samiel@darkstar:~$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin

SCSI Status: Check Condition

Sense Information:
Fixed format, current; Sense key: Illegal Request
Additional sense: Unaligned write command

=======================================================

Is it my test right and enough?

-------------------------------------------------------------------------
Possible remedies:

We would need a Brasero developer to find a workaround, because not
only the bad READ CD command needs to be avoided, but also a replacement
for the code gesture to distinguish TAO CDs from SAO CDs would have to
be developed.

Maybe this distinction is not really necessary. It seems not to work
properly on the TSSTcorp drive by making a false correction of the
track size. But that would be up to a Brasero developer to decide.

In fact I am a little surprised (although I don't know how these things are handled by the Debin team)

that so far there has been no intervention by the packagers of Brasero

[Thomas Schmitt]

Hi,

Mauro Sacchetto wrote:
> samiel@darkstar:~$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00
> --outfile=tdb_data.bin
> SCSI Status: Check Condition
>
> Sense Information:
> Fixed format, current; Sense key: Illegal Request
> Additional sense: Unaligned write command

Now we know from where that error came, which is inappropriate for
optical drives. (Maybe that the kernel created it, and not the drive.)

> Is it my test right and enough?

The main question is:

Is the drive unusable afterwards ?

(I.e. do i have identified the culprit for your drive problem ?)

> In fact I am a little surprised (although I don't know how these things are
> handled by the Debin team)
> that so far there has been no intervention by the packagers of Brasero

I understand that there is no upstream developer any more and no community
which would continue the GUI part and build it with patch proposals.
It looks like i was involved in the second youngest thread on the mailing
list, back in 2019:
https://mail.gnome.org/archives/brasero-list/2019-January/thread.html
The youngest thread is a request for help with building Brasero. It got
no answer.

Possibly i will post a report about the problem there. Just in case some
new developer shows up.


Said that, and contrary to my statement in the previous mail, i have not
yet used up my ideas for experiments:

- Will the Pioneer drive go bad if i send the READ CD 0xffffffff command ?
It looks like Brasero doesn't do this.

- Will READ CD MSF 00:01:74 work better ?
Maybe with all three drives without incident and dmesg complaint ?
(I have to study the specs, because i never used that command before.)

If the Pioneer drive goes bad too, then it might even be a kernel
problem with that obviously disliked sector address, and not a problem
only with the ASUS drive.

This could become obvious if the

Additional sense: Unaligned write command

from your above experiment changes to my result

>>> transport error: Host_status=0x03 [DID_TIME_OUT]

if you use kernel 5.10.

[Thomas Schmitt]

Hi,

i made the experiments which i mentioned in the previous mail:

- The Pioneer drive does not go mad from READ CD for LBA -1 or from
READ CD MSF for sector 00:01:74.

- The ASUS drive does not go mad from READ CD MSF for sector 00:01:74.

- The TSSTcorp drive tolerates READ CD MSF for sector 00:01:74 without
a message in dmesg about USB reset. (It did that reset with READ CD for
LBA -1 but showed no lasting problem.)

None of the drives reports success with the READ CD MSF command. So with
this command the Brasero function brasero_medium_track_written_SAO()
would return TRUE, which is wrong with the given CD.

The desire to read the Lead-in sector before the start of the payload
data simply seems not fulfillable here for the first track of a CD.

Brasero will have to abandon this idea or come up with a better read
command - which i currently fail to imagine.

-------------------------------------------------------------------------
The SCSI specs say that LBA -1 is bad:

While exploring how to encode the READ CD MFS command for 00:01:74, i found
this statement in the MMC-5 specs:
"3.2.21 Method 1 Addressing
[...] Method 1 logical sector numbering is not defined for
sectors outside of the program area."
This sector numbering is in effect with command READ CD. The "program area"
is the payload part of the CD with a single track.
So READ CD with logical block address -1 is not defined.

-------------------------------------------------------------------------
Experiments with the ASUS drive:

(Anybody remembers BCD number encoding ? I can be glad that they did not
choose to use Gray codes. BCD is easy to write in hex. :))

The READ CD MSF expects an inclusive start address (here 00:01:74) and
an exclusive end address (here 00:02:00). Except the address fields it
has the same byte layout as READ CD. So the command as replacement for

the bad READ CD command

be 00 ff ff ff ff 00 00 01 10 00 00

is

b9 00 00 00 01 74 00 02 00 10 00 00

This does not yield a good result in form a of data, but also no bad
consequences for the drive or complaints from the transport layer in dmesg.

$ sg_raw /dev/sr0 b9 00 00 00 01 74 00 02 00 10 00 00 --request=2352 --outfile=tdb_data.bin

SCSI Status: Check Condition

Sense Information:
Fixed format, current; Sense key: Illegal Request

Additional sense: Invalid field in cdb

Error 5 occurred, no data received

(I meanwhile learned that i need to tell sg_raw to expect a certain number
of bytes as reply. My choice 2352 is the size of CD-DA payload. The data
CD is supposed to deliver only 2048 bytes of payload. I tried a request
size of 2048, but the behavior of sg_raw did not change.)

In order to prove that my SCSI command is correctly encoded, i asked for
the first valid payload block at 00:02:00 = LBA 0 :

$ sg_raw /dev/sr0 b9 00 00 00 02 00 00 02 01 10 00 00 --request=2352 --outfile=tdb_data.bin
SCSI Status: Good

Writing 2352 bytes of data to tdb_data.bin

The file tdb_data.bin shows the MBR data of the Debian netinst ISO.
The same result i get with a valid READ CD command for LBA 0:

$ sg_raw /dev/sr0 be 00 00 00 00 00 00 00 01 10 00 00 --request=2352 --outfile=tdb_data.bin

None of these experiments caused problems like with Brasero.

-------------------------------------------------------------------------
What does PIONEER BD-RW BDR-S09 say to such commands:

$ sg_raw /dev/sr1 b9 00 00 00 01 74 00 02 00 10 00 00 --request=2352 --outfile=tdb_data.bin

SCSI Status: Check Condition

Sense Information:
Fixed format, current; Sense key: Illegal Request

Additional sense: Invalid field in cdb

Error 5 occurred, no data received

The drive is still usable and dmesg shows no new complaints.
(Except blkid's graceful failures to read the Run-out blocks.)

With CDB b9 00 00 00 02 00 00 02 01 10 00 00 i get the first data block
from the CD: the isohybrid MBR, which xorriso inserted when it created
the ISO for the debian-cd project.

Now for the ugly test:

$ sg_raw /dev/sr1 be 00 ff ff ff ff 00 00 01 10 00 00 --request=2352 --outfile=tdb_data.bin

SCSI Status: Check Condition

Sense Information:
Fixed format, current; Sense key: Illegal Request

Additional sense: Logical block address out of range

Error 22 occurred, no data received

It turns out that this drive and its transport layers in the kernel can
stand the bad READ CD command.
No dmesg complaints to see from this experiment. xorriso still works with
the drive.

This quite kills the theory that the kernel transport layer gets a hickup
without the help of the drive's SATA interface.

So the ASUS drive indeed has a stake in the problem.

-------------------------------------------------------------------------
And the TSSTcorp CDDVDW SH-S223B :

$ sg_raw /dev/sr2 b9 00 00 00 01 74 00 02 00 10 00 00 --request=2352 --outfile=tdb_data.bin

SCSI Status: Check Condition

Sense Information:
Fixed format, current; Sense key: Illegal Request

Additional sense: Invalid field in cdb

Error 5 occurred, no data received
$ sg_raw /dev/sr2 b9 00 00 00 02 00 00 02 01 10 00 00 --request=2352 --outfile=tdb_data.bin
SCSI Status: Good

Writing 2048 bytes of data to tdb_data.bin
$

No dmesg messages to see. xorriso still works with the drive.

[Mauro Sacchetto]

Il 14/11/21 14:25, Thomas Schmitt ha scritto:

>
> The main question is:
>
> Is the drive unusable afterwards ?
>
> (I.e. do i have identified the culprit for your drive problem ?)

I put the CD into the drive, mount and umount it: all goes.

I lauch che command and obtain:

==================================================================

samiel@darkstar:~$ samiel@darkstar:~$ sg_raw /dev/sr0 be 00 ff ff ff ff

00 00 01 10 00 00 --outfile=tdb_data.bin

bash: samiel@darkstar:~$: comando non trovato

samiel@darkstar:~$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00
--outfile=tdb_data.bin
SCSI Status: Check Condition

Sense Information:
Fixed format, current; Sense key: Illegal Request
Additional sense: Unaligned write command

==================================================================

After this, the drive is unavailable:

==================================================================

Impossible to mount debian...iso

Error mounting the system-managed device /dev/sr0: no medium fount o
/dev/sr0

==================================================================


m

[Thomas Schmitt]

Hi,

Mauro Sacchetto wrote:
> sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin

> After this, the drive is unavailable

Well, then we have found:

- The immediate cause of the problem: READ CD with LBA -1.

- A good suspect in Brasero: Function brasero_medium_track_written_SAO()
https://sources.debian.org/src/brasero/3.12.3-1/libbrasero-media/brasero-medium.c/?hl=1565#L1565

- The generally problematic expectation of Brasero that it can determine
whether a CD track was written by write type SAO (and not by TAO).

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

We have not explored yet:

- Why does Brasero believe to see 2 tracks on a closed CD-RW with a
single TAO track ?

BraseroMedia: (at brasero-medium.c:2062) 2 track(s) found

This misperception triggers the call to brasero_medium_track_written_SAO().

- Why does brasero_medium_track_get_info() want to distinguish SAO from
TAO only if its parameter multisession is set to "true". Its only caller
has a strange comment before setting multisession:
https://sources.debian.org/src/brasero/3.12.3-1/libbrasero-media/brasero-medium.c/?#L2052

num = (size - sizeof (BraseroScsiFormattedTocData)) /
sizeof (BraseroScsiTocDesc);

/* remove 1 for leadout */
multisession = !(priv->info & BRASERO_MEDIUM_BLANK) && num > 0;

If the leadout is counted as surplus track, then why not "num > 1" ?

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

So the Brasero "Copy" task of TAO CDs is not possible with the ASUS drive.
The code of Brasero would have to be changed for that.

We have no workaround yet for the case of burning the netinst ISO by
Brasero.
I found no way to tell Brasero that its libburn plugin shall ask libburn
for SAO. libburn would of course be able to avoid SAO if it is told to do
so. It would propose SAO if being asked to find a suitable write type for
track input of which the size is known in advance.

My only idea which does not need a code change is to employ the wodim
plugin of Brasero and to hope that it burns by write type SAO.
If so, then the drive would not get lost after a successful burn run.

Of course you would have to carefully avoid to show Brasero a TAO CD in
the ASUS drive.
Best would be to blank any CD-RW before giving it to Brasero.

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

[Mauro Sacchetto]

Il 15/11/21 14:58, Thomas Schmitt ha scritto:

> My only idea which does not need a code change is to employ the wodim
> plugin of Brasero and to hope that it burns by write type SAO.
> If so, then the drive would not get lost after a successful burn run.

Which way?
Thanx!
m

[Thomas Schmitt]

Hi,

i wrote:
> > My only idea which does not need a code change is to employ the wodim
> > plugin of Brasero and to hope that it burns by write type SAO.

Mauro Sacchetto wrote:
> Which way?

Good question.
I have wodim installed. But last time when i tried, the wodim item was
greyed out in the plugin list window which i somehow managed to pop up.

Google brings me to
https://github.com/lmedinas/brasero
which in "Notes on plugins for advanced users" proposes to remove
libburn (bleh !) or to use something named Gconf for changing plugin
priorities.
Wikipedia says: "GConf was a system used by the GNOME desktop".

The riddle remains, i fear.

[Mauro Sacchetto]

I still fail to burn ISO even to blank CDs. The same for SAO or DAO

to blank and than burn.

I tried to "play" a bit with the few customizable fields in the Brasero plugins, basically two:

cdrdao (enable the "--driver generic-mmc-raw" flag)

and

growisofs (allow the use of DAO),

but the problems persist.

Gconf is obsolete and now replaced by Dconf,

but in fact I don't know where to put my hands. I try to deepen ...

m

Il 15/11/21 17:11, Thomas Schmitt ha scritto: