Bug 157186 - Verification fails despite md5sums being the same
Summary: Verification fails despite md5sums being the same
Status: RESOLVED UNMAINTAINED
Alias: None
Product: k3b
Classification: Applications
Component: Verfication (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Sebastian Trueg
URL:
Keywords:
: 157332 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-02-05 04:55 UTC by Francois Marier
Modified: 2010-03-16 16:06 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Log from K3b (47.30 KB, text/plain)
2008-02-05 04:59 UTC, Francois Marier
Details
Error messages printed to the terminal (34.22 KB, text/plain)
2008-02-05 05:00 UTC, Francois Marier
Details
output of strace (34.63 KB, text/plain)
2008-02-05 05:00 UTC, Francois Marier
Details
k3b-log (7.77 KB, text/plain)
2008-03-04 18:37 UTC, jochen zimmermann
Details
k3b-strace (30.00 KB, text/plain)
2008-03-04 18:37 UTC, jochen zimmermann
Details
Debug output of K3B 1.0.5 on debian (48.21 KB, text/plain)
2008-06-29 15:11 UTC, Hakan Bayindir
Details
K3B Debug output (37.15 KB, application/octet-stream)
2008-07-07 21:10 UTC, Hakan Bayindir
Details
Patch for k3b version 1.0.5 md5sum errors on iso files with late kernels (2.77 KB, patch)
2008-10-28 02:40 UTC, jim lab
Details
k3b 1.66.0 log (debugging output) (68.89 KB, text/plain)
2009-07-02 21:11 UTC, Andrei Borisochkin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Francois Marier 2008-02-05 04:55:48 UTC
Version:           1.0.4 (using KDE 3.5.8)
Installed from:    Debian testing/unstable Packages
OS:                Linux

mauro.sacchetto@tele2.it reported this on the Debian tracker (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463877):

  After burning an ISO of data CD or DVD with option "VerifY written data", at the end of this operation I receive the message:
    "Data written on track 1 differ from original".

  However, the md5sum of ISO is the same of that of the new CD. In effect, burning is correct, only the verification fails.

(I'll attach the logs he sent in...)
Comment 1 Francois Marier 2008-02-05 04:59:32 UTC
Created attachment 23423 [details]
Log from K3b
Comment 2 Francois Marier 2008-02-05 05:00:05 UTC
Created attachment 23424 [details]
Error messages printed to the terminal
Comment 3 Francois Marier 2008-02-05 05:00:37 UTC
Created attachment 23425 [details]
output of strace
Comment 4 jochen zimmermann 2008-03-04 18:36:24 UTC
having the same problem on 2 machines here, both debian testing/unstable and 2.6.24-kernel (tested with 2.6.24.2 and 2.6.24.3)

i'll attach the k3b log and strace output of one of the machines below.
Comment 5 jochen zimmermann 2008-03-04 18:37:24 UTC
Created attachment 23785 [details]
k3b-log
Comment 6 jochen zimmermann 2008-03-04 18:37:57 UTC
Created attachment 23786 [details]
k3b-strace
Comment 7 Philippe Cloutier 2008-03-17 20:35:56 UTC
I believe I reproduced this twice (on 2 burn attempts) with testing/unstable and Linux 2.6.24. The bug reporter reported using Linux 2.6.24 too. I'll try remembering to report whether this persists with 2.6.25.
Comment 8 Swistak 2008-03-27 02:04:15 UTC
I confirm the same behaviour on Ubuntu 8.04.
Here's the bug report I filed.
https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/207265
Comment 9 François Valenduc 2008-03-29 16:00:13 UTC
I encounter exactly the same bug under gentoo (see http://bugs.gentoo.org/show_bug.cgi?id=209578).
Comment 10 Michael Schwendt 2008-06-12 18:12:29 UTC
For Fedora 8 it is tracked as https://bugzilla.redhat.com/440343
(k3b fails to verify written data). I've found that with a kernel
downgrade to 2.6.23.15-137.fc8 k3b verifies fine. With newer kernel
versions it is broken in Fedora 8, 9 and newer.

With the presumably bad kernel, the only difference in k3b debug
output is this after reloading the tray for verification:

(K3bDevice::ScsiCommand) failed: 
                           command:    SET SPEED (bb)
                           errorcode:  70
                           sense key:  NOT READY (2)
                           asc:        3a
                           ascq:       0

Followed by a couple of:

(K3bDevice::ScsiCommand) failed: 
                           command:    READ (10) (28)
                           errorcode:  70
                           sense key:  NOT READY (2)
                           asc:        3a
                           ascq:       0
(K3bDevice::Device) /dev/sr0: READ 10 failed!

Those messages don't appear when running the good kernel.
Comment 11 Hakan Bayindir 2008-06-24 16:04:50 UTC
I'm having the same problem with my Debian lenny installation for ages. 
The interesting thing is problem is happening with my Optiarc AD-7173A drive only. My HP Pavilion DV6100 checksums just fine (which .

I have two AD7173As. One is on my home pc and one is on the office PC. The installation of the office PC is a disk clone of home. My home setup is installed as Lenny beta-1 and surviving since. This installation used 3 different burners and the fails started after I installed the AD-7173A.

In my case, these failures are independent of kernel and hardware that drives the burner (My home PC was upgraded recently and the bug didn't go away).

When I got home, I'll do a test burn and attach the logs here (Currently I don't have blank DVDs here)
Comment 12 Hakan Bayindir 2008-06-24 16:06:01 UTC
Also, this bug is persistent in K3B 1.0.5 testing package in debian
Comment 13 Hakan Bayindir 2008-06-29 15:11:28 UTC
Created attachment 25703 [details]
Debug output of K3B 1.0.5 on debian

I've burned ubuntu 8.04 to a CDRW and verified. As usual it failed. md5sum
command verifies iso is written correctly. Burner is a NEC-AD7173A
Comment 14 Hakan Bayindir 2008-07-07 21:10:15 UTC
Created attachment 25912 [details]
K3B Debug output

Weird. Since I was not happy with my optiarc's (NEC) write quality, swapped it
with a brand new Samsung SH-S203N and it exhibits this bug too. Debugging out
from K3B is attached.
Comment 15 Michael Schwendt 2008-09-13 19:50:13 UTC
This remains broken for many users.
Comment 16 jim lab 2008-10-26 20:05:01 UTC
(In reply to comment #15)
> This remains broken for many users.
> I have developed a patch that solved this problem for me. It does require that you recompile k3b. The patch is for version 1.05. If you are interested in trying the patch I would be glad to forward it to you. Basically I discovered that the failure to verify was coming from a incorrectly calculated checksum for the written data.  The md5sum on the copy was actually correct but it would indicate a failure because the written checksum did not match the one from the copy.  

Comment 17 Michael Schwendt 2008-10-26 22:28:53 UTC
Jim, why not attach your patch here?

Although, the same k3b works with old kernels (and old Linux distributions), and there are theories that the checksum is only miscalculated with newer kernels because after ejecting and reloading the tray [with problems for some users] k3b reads wrong data.
Comment 18 jim lab 2008-10-28 02:40:12 UTC
Created attachment 28197 [details]
Patch for k3b version 1.0.5 md5sum errors on iso files with late kernels
Comment 19 Michael Schwendt 2008-10-28 11:23:36 UTC
I'm sceptical for several reasons (and being a user where verification currently only fails for DVDs not CDs or CD-RWs):


1) You modify the K3bChecksumPipe class without updating

  libk3b/projects/datacd/k3bisoimager.cpp
  libk3b/jobs/k3bdvdcopyjob.cpp

which also use it. With your patch, the code in there would need to reset the MD5 digest manually now, too.


2) Your changes to k3biso9660imagewritingjob.cpp:

   d->checksumPipe.close();
+// added to reset checksum pipe before starting cksum accum
+  d->checksumPipe.extreset();
   d->checksumPipe.readFromIODevice( &d->imageFile );

You here added a public method to reset the MD5 digest manually. Is that necessary? Or does this only hide a different bug? A few lines below the original code would perform the reset after preparing the disc writer:

    d->checksumPipe.open( K3bChecksumPipe::MD5, true );

This method is supposed to reset the digst. Instead, you disabled it to not call reset() in favour of doing it manually via extreset(). Where's the difference? In side-effects elsewhere? What am I missing?


3) Your change to k3bverificationjob.cpp:

+   // display the two sums
+        emit infoMessage( i18n("Written source checksum = %1 ").arg(d->tracks[d->currentTrackIndex].checksum), INFO);
+        emit infoMessage( i18n("ReadBack of copy checksum = %1 ").arg(d->md5Job->hexDigest()), INFO);
+

This is only added debug output. Useful, however. What would be interesting to add is to also print the source checksum of the ISO file on hard-disk.

d->md5Job is a K3bMd5Job object which calculates the MD5 digest from the on-disc data. It isn't based on K3bChecksumPipe and is unrelated. Noticing how many users get "No tracks to verify found" with recent kernels instead of a verification error, I rather believe the unsuccessful verification is related to the trackindex (and preparing for disc read) instead of calculating a wrong checksum for the source data while burning.
Comment 20 Pétur Runólfsson 2009-04-15 22:38:00 UTC
*** This bug has been confirmed by popular vote. ***
Comment 21 Sebastian Trueg 2009-05-26 10:18:58 UTC
can someone please test with K3b 1.65.0?
Comment 22 Andrei Borisochkin 2009-07-02 21:09:41 UTC
I can confirm. Debugging output in attachment
Comment 23 Andrei Borisochkin 2009-07-02 21:11:30 UTC
Created attachment 35001 [details]
k3b 1.66.0 log (debugging output)
Comment 24 Tristan Hoffmann 2009-07-27 11:54:57 UTC
*** Bug 157332 has been marked as a duplicate of this bug. ***
Comment 25 markuss 2010-03-16 16:06:18 UTC
In an attempt to clean up old bugs that are not valid for K3b 2.0 (=KDE SC 4.x port) anymore, this is now being marked as UNMAINTAINED.
If this bug is still valid for 2.0, please reopen it.