k3b failure [was Re: [debian-knoppix] Is knoppix getting behind?]
| From: mark everton <markeverton1@yahoo.com>
| I can't use k3b to burn cd's Every time it fails.
| This is the case with knoppix 3.7 and all 2.6 kernels
| I used after that. This is a know problem for some
| time now.
k3b on a 2.6 kernel burns .iso files correctly for me. A k3b check of
the result generally fails. I do a different kind of check and the
created CDs almost always pass.
I will explain my understanding of what is going on. Beware: I could
be wrong.
Summary: when treating the raw CD drive as a file, the wrong length is
provided by the ide-cd driver. This length includes runout sectors at
the end of the content and these sectors will generate I/O errors when
k3b's md5sum reads them for checking purposes. Even if there were no
I/O errors, the md5sum would be wrong since it includes extra
(non-content) sectors. Hence, k3b's tests fail.
Longer version:
The problem is that the SCSI/ATAPI Read Capacity command that queries
CDROMs for the length of their content is allowed to return a value
longer than the actual contents. According to
http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO/sr.html
the length can include "runout" sectors that are not really content.
The old LINUX ide-scsi driver (or something else in the stack) used to
correct this Content Length result but the new ide-cd driver does not
(because it is expensive).
k3b checks for correct burning by comparing the md5sum of the .iso and
the raw CD. The raw CD is taken to be the raw sectors up to the
length report by the driver -- one that is no longer accurate. No
wonder the md5sum of the raw CD does not have the expected value. In
fact, the md5sum calculation often reads runout sectors and this gets
I/O errors -- very scary.
What can be done? I feel nervous leaving newly burned CDs unchecked.
I have found a crude technique that works. If you do a cmp(1) command
comparing the .iso with the raw CD, you will find that the cmp will
fail with an EOF error, running out of .iso, but only if the write
succeeded (think about it: all the bytes in the .iso are present in
the CD). Any other error is bad. If the length happened to be right
(I think that it can happen, but I've not seen it) the cmp will
actually succeed, another good outcome.
In fact, I do the cmp using a different drive just to catch some drive
compatibility problems.
It sure would be handy if the md5sum command let you specify a file
length. You can do this by using dd as a front end, but passing a
half billion bytes through a pipe has unpleasant performance (at least
when I tried it a few years ago -- maybe the kernel has gotten
better).
I found the comment from Anonymous informative:
http://www.livejournal.com/community/debian/186598.html?thread=1182950#t1182950
Reply to: