Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#35858 - [k3b] CD looks blank after successful burning of an ISO image

Attached to Project: Arch Linux
Opened by Andrej Podzimek (andrej) - Wednesday, 19 June 2013, 23:55 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Thursday, 11 July 2013, 15:02 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Eric Belanger (Snowman)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

After burning an ISO image (such as the Arch ISO), the CD looks blank. k3b successfully completes the burning process *and* the checksumming, but after re-inserting, the CD is reported as blank (and can be even overwritten once more, which destroys it completely, of course). The CD is definitely not readable, even though k3b somehow succeeds to read it once and compute the checksum.

This might be related to an Ubuntu issue https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/978621 There are also some other similar reports on the web.

I tried whether wodim works correctly, but it doesn't even report the list of devices; this is because a symlink /dev/scd0 -> /dev/sr0 is missing. Adding the symlink manually fixes wodim's capabilities related to listing of available drives, but the k3b problem persists. :-(

k3b 2.0.2-8
cdrdao 1.2.3-6
cdrkit 1.1.11-3

As noted in some of the discussions, I tried to manually modprobe sg and to check whether all the (reportedly) required *_mod modules are present. All the required modules seem to be there.

Tested (and failed) with: 3.9.6 Arch stock kernel and also a 3.9.6 custom vanilla kernel
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Thursday, 11 July 2013, 15:02 GMT
Reason for closing:  Not a bug
Comment by Eric Belanger (Snowman) - Thursday, 04 July 2013, 02:25 GMT
I can't reproduce it here.
Comment by Andrej Podzimek (andrej) - Thursday, 11 July 2013, 10:35 GMT
It might have something to do with the weird group called 'burn'. For some reason K3B has a dialog that can (among other things) change the group ownership of the optical drive's device file. Well, I'll have to spoil a few CDs and try this with and without the group change.
Comment by Andrej Podzimek (andrej) - Thursday, 11 July 2013, 11:51 GMT
OK, so the problem persists. The log from k3b looks OK, checksumming in k3b succeeds, but the CD is unreadable and looks empty. The surface looks as if it was recorded just fine. An attempt to read the CD also yields this in dmesg:

[ 1270.951447] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 1270.951455] sr 1:0:0:0: CDB:
[ 1270.951456] cdb[0]=0x52: 52 01 00 00 00 01 00 00 08 00
[ 1270.951472] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio 16392 in
res 40/00:03:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[ 1270.951478] ata2: hard resetting link
[ 1271.437818] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1271.440366] ata2.00: ACPI cmd e3/00:79:00:00:00:a0 (unknown) succeeded
[ 1271.440562] ata2.00: ACPI cmd e3/00:01:00:00:00:a0 (unknown) succeeded
[ 1271.444562] ata2.00: ACPI cmd e3/00:79:00:00:00:a0 (unknown) succeeded
[ 1271.444796] ata2.00: ACPI cmd e3/00:01:00:00:00:a0 (unknown) succeeded
[ 1271.446271] ata2.00: configured for UDMA/66
[ 1271.457814] ata2: EH complete
[ 1271.457886] sr0: CDROM (ioctl) error, command: cdb[0]=0x52 52 01 00 00 00 01 00 00 08 00
[ 1271.457899] sr: Sense Key : 0xb [current] [descriptor]
[ 1271.457903] sr: ASC=0x0 ASCQ=0x0

Will retry with the 'burn' group in k3b and report back...
   failedburn.log (37 KiB)
Comment by Andrej Podzimek (andrej) - Thursday, 11 July 2013, 12:13 GMT
So the failure is still there, even after K3b's changes to permissions.

Edit1: But this time there are no error messages in dmesg, just the CD is blank. So the error messages above are weird. What if this entire problem is a hardware failure? Unfortunately I don't have another (external) optical drive to check this.
Edit2: Running cdrecord manually also fails. The write operation succeeds and completes, but the CD is blank.
Edit3: https://bbs.archlinux.org/viewtopic.php?pid=1298967 Someone was already facing this quite a long time ago.
Comment by Andrej Podzimek (andrej) - Thursday, 11 July 2013, 14:31 GMT
Unfortunately, I have just reproduced exactly the same issue with Fedora 18 on the same hardware. :-(

This probably means that my optical drive is dead, unless Fedora has the same problem. :-( There were no obvious symptoms and the Ubuntu bug linked above gave a false impression that it could be just a software failure.

Loading...