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. Have a nice day :) Thomas
