Version: 0.11.17 (using KDE KDE 3.3.0) Installed from: RedHat RPMs Compiler: gcc-3.4.2-5 i686 compile from k3b-0.11.17-1.xcyb.fc2 OS: Linux Testing has shown that in k3b-0.11.17 the "verify written data" option works properly using DAO writing mode but not TAO mode (RAW untested.) Auto write mode recently started choosing TAO over DAO. TAO always fails to verify. The resulting disks seems OK in that I can mount the disks and the md5sums of all the files on a disk make the md5sums of a loop back mounted iso. How to Reproduce: - Download an iso image ex. http://www.tlm-project.org/torrents/slax/4.2.x/slax-professional.iso.torrent - Burn the image to CDR using the defaults, making sure Burnproof and Verify written data are also selected. - Burn will finish fine however you will always get an error at 99% of the verify disk stage Expected Behaviour: - Verify written data should always work independent of Writing mode (or at very least it should force not using TAO if selected) It took me far longer than it should have to figure out why all of a sudden everything I tried to burn with k3b failed to verify. It didn't make any sense: The md5sums of files on a recently burnt CDR matched what I got when I loopback mounted the iso in question. To make a long story short the switchover to using TAO has broken the "verify written data" option. This option is very important to me so please don't remove it. I'm using Linux Kernel 2.6.9 with the latest patches. I was running as root. More details provided on request.
I can confirm this. The problem is with k3b as the same problem happens when using kernel 2.6.7, which worked fine with k3b 0.11.12-r1. There are no other changes on my system. The CD's boot normally. Running vanilla 2.6.9 or 2.6.7 as a normal user.
I think I have just hit the same bug burning an iso (which I guess uses a raw mode). I have downloaded the debian sarge iso disks and burnt them onto a cdrw disk. Every time I have done it, with verify switched on, it gives an error right at the end of verifying (99% is shown). There is no other mention in the debug output, just the error message. I have mounted the source iso file on loopback, and the burnt cd, and run cvf to create a checksum of the source iso and verify it against the cd, and this says the two are the same.
When burning CD-R/DVD-+Rs w/ k3b, after I experience a verify failed (which happens every time I burn), depending how bad the burn is, I will sometimes see NO file system corruption on a file by file CRC/MD5 check. Initially this suggested to me that perhaps k3b was wrong, it isn't. I still haven't found exact how k3b is verifying the disk (haven't had time to check source), however it IS CORRECT the verify failed disks are BAD. Given the disconnect in some instances between file verification and k3b's disk verification, I didn't trust it until I was able to perform detailed PI/PO testing using Plextor's QCheck Tools on a Windoze box. These tools came with my burner. Unfortunately, I haven't been able to find anything even close to QCheck tests under Linux. This makes testing more annoying. The QCheck tests show in gory detail how good or bad a burn is. Unfortunately on each disk which k3b "verify failed" those tests clearly a bad burn with many POF errors. I believe POF expands to Parity Outer Failures, which are unrecoverable errors which can result in data loss. I suspect there are more fundamental problems with CD/DVD burning under recent 2.6.x kernels. Several other users have reported similar problems. Another user is having similar problems with 2.6.x kernels however he seems to be able to burn properly under a 2.4.x kernel. Unfortunately my system requirements here do not allow for using a 2.4.x kernel. I have tried replacing my burner with a high end plextor burner. I also have tried various types of media. My system works well otherwise. Some suggestions which made no diff here: avoid cfq, try deadline scheduler. Please note the problem also exists for latest Rawhide RPM i.e. k3b-0.11.17-1 rebuilt using gcc-3.4.3-x now running on a bug fixed 2.6.10 kernel.
If a developer is willing to help with debugging please join Delemas and others on: irc.oftc.net #linuxhelp
Well, it still exists on Gentoo 2.6.10-r4 kernel and k3b-0.11.18-r1 as of 2005-01-15. I was able to verify the burned CD-RW with MD5SUM, but like a previous poster, I have no tools other than that to verify CDs. When I forced DAO, K3B burned and verified successfully. I also had some difficulties with CDs back around the time of the Gentoo 2004.3 release. I downloaded Gentoo isos and burned them with K3B. At the time, K3B was verifying them but they wouldn't always boot or read successfully on another machine. I figured this was coming from bad media or a bad reader on the second machine, but maybe K3B's verification was giving false positives back then. I don't remember the K3B version, but the kernel was 2.4.25 -- I just migrated to 2.6.10-r4 over New Years' weekend
I recently finished a lengthy debugging process with respect to the unsatisfactory burns I was getting with k3b. I was able to determine that there are four possible outcomes to burning DVD-+Rs with k3b verifying turned on: 1. "Successful" Flawless burn with a low error count i.e. average PI < 20, PO ~= 0, POF = 0. 2. "Successful" Acceptable burns with high PI count which may read at a reduced rate or have reading pauses. PI < 280, PO very low, POF = 0 3. "Successful" Horrible Burn which has high PI counts > 280, higher PO counts and POFs > 0, POF =~ 10. You may be able to read these but expect your drive to grind itself into the floor trying. 4. A total burn failure. Ideally, the verification process should fail outcomes 2, 3 and 4 but this is not always the case. I've seen instances where type 2 & 3 burns verify in k3b. Assuming you have a recent kernel which contains 2.6.10-ac8 or 9 or 2.6.10 w/ Fedora Rawhide's linux-2.6.9-ide-cd-early-EOF.patch, chances are if the verify fails you really do have media problems, even if an md5sum compare succeeds. Another major problem I found is with the burners themselves. Even with a good Plextor 712A, I had to perform many test burns with several types of media to find a media which burned well with no errors. In my case, I ended up finding 8X DVR-R Ritek/Ridata media worked flawlessly when burnt at 6X in Windoze using the Plextor Tools. Also SmartBuy 4X DVD+R media worked flawlessly at 4X in Windoze (Plextor burner wanted to burn these at 8X which results in a coaster.) If you don't have KProbe or Plextor Tools available to test your first burns with new media, perhaps you can simply look at the results of the tests in some of the reviews and find identical media. I found the tests for my burner quite handy: http://www.cdfreaks.com/article/144
Thanks!! I have yet to invest in a DVD burner. Since this is a hobby and not a professional venture, I don't much see the point in going to all that trouble and expense. Now if I could write it off ... :) I have Gentoo, and my burner is an ancient NEC NR 7500A. It does a reasonable job at 4X on most of the cheap CD-RWs, which is about all I need. I don't have enough intellectual property for sale to justify a DVD burner. Still, doesn't K3B just wrap itself around cdrdao and cdrecord? Are there other open-source tools at that level with better diagnostics?
DVD burners are dirt cheap these days. My local store has a reasonable BenQ model for CDN$69.95 or ~US$58.63. We use them for system backups so they pay for themselves the first time they are used in time savings alone. Almost all previous comments about DVD+-Rs apply to CDRs as well, however the testing tools for CDRs are slightly different. The CDRs test in PlexTools is called a Q-Check C1/C2 test. As I indicated in my 2004/12/29 comment: I haven't been able to find decent CDR/DVD+-R testing tools under Linux and I still haven't had a chance to figure out how k3b verifies its burns.
K3b has it's own routines for that. no external tools. I will fix the TAO issue. But I won't include more advanced verifying right now. No time and not much interest. sorry.
*** Bug has been marked as fixed ***.