If you burn an iso image with k3b, the verification process always said that the burned data's are not the same as the original ones. However, if you make an iso image of the burned CD and compile it's md5sum, it gives the same sum as the one of the original image. So k3b wrongly reports that verification has failed, even if the burned CD is 100% correct. Should I file a bug report upstream ? Reproducible: Always Steps to Reproduce: 1.Burn an ISO image and ask k3b to verify the CD 2.Notice that verification has failed 3.Make an iso image of the burned CD and compute it's md5sum 4.Notice that the md5sums of the original and of the iso image of the burned CD are exactly the same. Expected Results: a correct verification by k3b
FYI, when reproducing the bug, you can skip making an iso image of the burned CD and just type: md5sum /dev/cdrom
Thanks for the info. But do you also notice the bug ?
Yes, I get the same bug, and I voted for it. I wonder though, if this is gentoo-specific, or if this bug should be filed up-stream. Unfortunately, I don't use any other distro's. Have you tried this with earlier versions of k3b?
I got the same thing yesterday when I burned an Ubuntu cd image for my daughters computer. After 3 failed discs I burned it with nero. Its not the verification, its the burn itself that doesnt go right.
(In reply to comment #4) > Its not the verification, its the burn itself that doesnt go right. This is distinctly different from the problem described in this bug. If you are the first to report this problem, you should start a new bug so it will get the proper attention.
In reply to comment #4, the burn obviously go right. If not, the md5sums of the burned and of the original would be different. However, there are exactly the same. In reply to comment #3, the problem didn't occur with the version 0.12.17, if I recall correctly.
(In reply to comment #3) > Yes, I get the same bug, and I voted for it. I wonder though, if this is > gentoo-specific, or if this bug should be filed up-stream. Unfortunately, I > don't use any other distro's. Have you tried this with earlier versions of > k3b? > I'm having similar problems with k3b 1.0.4. I'm not sure it's k3b that's at fault, however ... I think it's something lower level that's broken. I'm trying a DVD at the moment. If it fails, I'll try the verify outside of k3b to see if it's the burn or the verify that's broken.
(In reply to comment #7) > (In reply to comment #3) > > Yes, I get the same bug, and I voted for it. I wonder though, if this is > > gentoo-specific, or if this bug should be filed up-stream. Unfortunately, I > > don't use any other distro's. Have you tried this with earlier versions of > > k3b? > > > > I'm having similar problems with k3b 1.0.4. I'm not sure it's k3b that's at > fault, however ... I think it's something lower level that's broken. I'm trying > a DVD at the moment. If it fails, I'll try the verify outside of k3b to see if > it's the burn or the verify that's broken. > Well ... that was fast! It croaked reading back the DVD at 26%!! Here's the debug output: System ----------------------- K3b Version: 1.0.4 KDE Version: 3.5.9 QT Version: 3.3.8 Kernel: 2.6.24-gentoo-r3 Devices ----------------------- ATAPI DVD LS 8X16X8X16 GCAB (/dev/hdb, ) [CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R DL, DVD+R, DVD+RW, DVD+R DL] [DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW] [SAO, TAO, RAW, SAO/R96R, RAW/R16, RAW/R96R, Restricted Overwrite, Layer Jump] Burned media ----------------------- DVD-R Sequential K3bDataTrackReader ----------------------- reading sectors 0 to 1776150 with sector size 2048. Length: 1776151 sectors, 3637557248 bytes. using buffer size of 64 blocks. Problem while reading. Retrying from sector 466880. Read error in sector 466928. Read a total of 466880 sectors (956170240 bytes) Used versions ----------------------- growisofs: 7.0 growisofs ----------------------- Executing 'builtin_dd if=/dev/fd/0 of=/dev/hdb obs=32k seek=0' /dev/hdb: "Current Write Speed" is 16.4x1352KBps. 17858560/3637557248 ( 0.5%) @1.1x, remaining 16:53 RBU 100.0% UBU 4.8% 43024384/3637557248 ( 1.2%) @5.5x, remaining 12:31 RBU 100.0% UBU 85.7% 74481664/3637557248 ( 2.0%) @6.8x, remaining 9:34 RBU 100.0% UBU 85.7% 100827136/3637557248 ( 2.8%) @5.7x, remaining 8:46 RBU 100.0% UBU 85.7% 133136384/3637557248 ( 3.7%) @7.0x, remaining 8:20 RBU 100.0% UBU 85.7% 160301056/3637557248 ( 4.4%) @5.9x, remaining 7:57 RBU 100.0% UBU 81.0% 193495040/3637557248 ( 5.3%) @7.2x, remaining 7:24 RBU 100.0% UBU 85.7% 225640448/3637557248 ( 6.2%) @7.0x, remaining 7:18 RBU 100.0% UBU 85.7% 255328256/3637557248 ( 7.0%) @6.4x, remaining 7:03 RBU 100.0% UBU 85.7% 289931264/3637557248 ( 8.0%) @7.5x, remaining 6:44 RBU 99.6% UBU 85.7% 324927488/3637557248 ( 8.9%) @7.6x, remaining 6:37 RBU 100.0% UBU 85.7% 360415232/3637557248 ( 9.9%) @7.7x, remaining 6:21 RBU 77.7% UBU 85.7% 367689728/3637557248 (10.1%) @1.6x, remaining 6:40 RBU 94.5% UBU 85.7% 387252224/3637557248 (10.6%) @4.2x, remaining 6:51 RBU 7.8% UBU 19.0% 412909568/3637557248 (11.4%) @5.6x, remaining 6:46 RBU 22.3% UBU 23.8% 444858368/3637557248 (12.2%) @6.9x, remaining 6:34 RBU 71.9% UBU 85.7% 482017280/3637557248 (13.3%) @8.0x, remaining 6:26 RBU 84.8% UBU 85.7% 519602176/3637557248 (14.3%) @8.1x, remaining 6:12 RBU 100.0% UBU 85.7% 557678592/3637557248 (15.3%) @8.3x, remaining 5:58 RBU 95.3% UBU 85.7% 590446592/3637557248 (16.2%) @7.1x, remaining 5:56 RBU 100.0% UBU 85.7% 629473280/3637557248 (17.3%) @8.5x, remaining 5:44 RBU 87.9% UBU 85.7% 668893184/3637557248 (18.4%) @8.5x, remaining 5:32 RBU 93.8% UBU 85.7% 708804608/3637557248 (19.5%) @8.6x, remaining 5:26 RBU 97.3% UBU 85.7% 743702528/3637557248 (20.4%) @7.6x, remaining 5:19 RBU 85.5% UBU 42.9% 784498688/3637557248 (21.6%) @8.8x, remaining 5:09 RBU 94.5% UBU 81.0% 825819136/3637557248 (22.7%) @9.0x, remaining 5:03 RBU 30.5% UBU 85.7% 867631104/3637557248 (23.9%) @9.1x, remaining 4:53 RBU 16.4% UBU 85.7% 874938368/3637557248 (24.1%) @1.6x, remaining 4:59 RBU 100.0% UBU 38.1% 908492800/3637557248 (25.0%) @7.3x, remaining 4:57 RBU 87.1% UBU 85.7% 951222272/3637557248 (26.2%) @9.3x, remaining 4:48 RBU 7.4% UBU 85.7% 988217344/3637557248 (27.2%) @8.0x, remaining 4:41 RBU 0.0% UBU 19.0% 1022885888/3637557248 (28.1%) @7.5x, remaining 4:38 RBU 5.9% UBU 14.3% 1058439168/3637557248 (29.1%) @7.7x, remaining 4:32 RBU 47.7% UBU 33.3% 1099268096/3637557248 (30.2%) @8.8x, remaining 4:25 RBU 20.7% UBU 14.3% 1139277824/3637557248 (31.3%) @8.7x, remaining 4:20 RBU 9.4% UBU 14.3% 1177911296/3637557248 (32.4%) @8.4x, remaining 4:14 RBU 10.5% UBU 38.1% 1208680448/3637557248 (33.2%) @6.7x, remaining 4:11 RBU 87.5% UBU 14.3% 1247805440/3637557248 (34.3%) @8.5x, remaining 4:07 RBU 43.4% UBU 85.7% 1288601600/3637557248 (35.4%) @8.8x, remaining 4:00 RBU 34.8% UBU 81.0% 1329201152/3637557248 (36.5%) @8.8x, remaining 3:54 RBU 5.9% UBU 38.1% 1366065152/3637557248 (37.6%) @8.0x, remaining 3:51 RBU 12.1% UBU 81.0% 1406074880/3637557248 (38.7%) @8.7x, remaining 3:45 RBU 15.6% UBU 19.0% 1425637376/3637557248 (39.2%) @4.2x, remaining 3:44 RBU 100.0% UBU 85.7% 1457160192/3637557248 (40.1%) @6.8x, remaining 3:42 RBU 41.4% UBU 85.7% 1500282880/3637557248 (41.2%) @9.3x, remaining 3:36 RBU 46.9% UBU 42.9% 1549271040/3637557248 (42.6%) @10.6x, remaining 3:28 RBU 68.4% UBU 85.7% 1596882944/3637557248 (43.9%) @10.3x, remaining 3:23 RBU 11.3% UBU 52.4% 1636827136/3637557248 (45.0%) @8.7x, remaining 3:18 RBU 68.8% UBU 47.6% 1687158784/3637557248 (46.4%) @10.9x, remaining 3:10 RBU 52.7% UBU 81.0% 1735655424/3637557248 (47.7%) @10.5x, remaining 3:05 RBU 4.3% UBU 85.7% 1776254976/3637557248 (48.8%) @8.8x, remaining 3:00 RBU 6.6% UBU 28.6% 1817968640/3637557248 (50.0%) @9.0x, remaining 2:55 RBU 43.4% UBU 23.8% 1866006528/3637557248 (51.3%) @10.4x, remaining 2:49 RBU 10.5% UBU 81.0% 1914667008/3637557248 (52.6%) @10.5x, remaining 2:43 RBU 20.3% UBU 23.8% 1961721856/3637557248 (53.9%) @10.2x, remaining 2:38 RBU 1.2% UBU 81.0% 1984561152/3637557248 (54.6%) @4.9x, remaining 2:37 RBU 100.0% UBU 33.3% 2022211584/3637557248 (55.6%) @8.2x, remaining 2:33 RBU 14.5% UBU 19.0% 2070937600/3637557248 (56.9%) @10.6x, remaining 2:27 RBU 3.9% UBU 81.0% 2113536000/3637557248 (58.1%) @9.2x, remaining 2:23 RBU 13.7% UBU 19.0% 2158362624/3637557248 (59.3%) @9.7x, remaining 2:18 RBU 7.8% UBU 14.3% 2196832256/3637557248 (60.4%) @8.3x, remaining 2:14 RBU 39.5% UBU 23.8% 2242478080/3637557248 (61.6%) @9.9x, remaining 2:10 RBU 2.0% UBU 28.6% 2286551040/3637557248 (62.9%) @9.6x, remaining 2:05 RBU 10.5% UBU 14.3% 2339831808/3637557248 (64.3%) @11.5x, remaining 1:59 RBU 100.0% UBU 71.4% 2396520448/3637557248 (65.9%) @12.3x, remaining 1:53 RBU 96.5% UBU 71.4% 2447179776/3637557248 (67.3%) @11.0x, remaining 1:47 RBU 100.0% UBU 42.9% 2504753152/3637557248 (68.9%) @12.5x, remaining 1:41 RBU 100.0% UBU 47.6% 2562818048/3637557248 (70.5%) @12.6x, remaining 1:36 RBU 100.0% UBU 76.2% 2605940736/3637557248 (71.6%) @9.3x, remaining 1:31 RBU 100.0% UBU 52.4% 2623963136/3637557248 (72.1%) @3.9x, remaining 1:30 RBU 100.0% UBU 81.0% 2674098176/3637557248 (73.5%) @10.9x, remaining 1:26 RBU 100.0% UBU 52.4% 2733572096/3637557248 (75.1%) @12.9x, remaining 1:20 RBU 97.3% UBU 81.0% 2793472000/3637557248 (76.8%) @13.0x, remaining 1:14 RBU 100.0% UBU 71.4% 2853928960/3637557248 (78.5%) @13.1x, remaining 1:08 RBU 64.8% UBU 66.7% 2907537408/3637557248 (79.9%) @11.6x, remaining 1:03 RBU 99.2% UBU 38.1% 2967076864/3637557248 (81.6%) @12.9x, remaining 0:57 RBU 91.0% UBU 28.6% 3024748544/3637557248 (83.2%) @12.5x, remaining 0:52 RBU 100.0% UBU 33.3% 3084615680/3637557248 (84.8%) @13.0x, remaining 0:46 RBU 96.9% UBU 33.3% 3123675136/3637557248 (85.9%) @8.5x, remaining 0:43 RBU 100.0% UBU 28.6% 3158540288/3637557248 (86.8%) @7.6x, remaining 0:40 RBU 100.0% UBU 47.6% 3213754368/3637557248 (88.3%) @12.0x, remaining 0:35 RBU 99.6% UBU 23.8% 3272769536/3637557248 (90.0%) @12.8x, remaining 0:30 RBU 100.0% UBU 28.6% 3330539520/3637557248 (91.6%) @12.5x, remaining 0:25 RBU 100.0% UBU 23.8% 3390603264/3637557248 (93.2%) @13.0x, remaining 0:20 RBU 58.6% UBU 23.8% 3417735168/3637557248 (94.0%) @5.9x, remaining 0:18 RBU 0.8% UBU 23.8% 3438477312/3637557248 (94.5%) @4.5x, remaining 0:16 RBU 0.0% UBU 33.3% 3460464640/3637557248 (95.1%) @4.8x, remaining 0:14 RBU 0.0% UBU 23.8% 3477766144/3637557248 (95.6%) @3.7x, remaining 0:13 RBU 0.0% UBU 23.8% 3496116224/3637557248 (96.1%) @4.0x, remaining 0:12 RBU 0.0% UBU 23.8% 3515940864/3637557248 (96.7%) @4.3x, remaining 0:10 RBU 7.0% UBU 9.5% 3535536128/3637557248 (97.2%) @4.2x, remaining 0:08 RBU 2.0% UBU 33.3% 3552903168/3637557248 (97.7%) @3.8x, remaining 0:07 RBU 33.2% UBU 19.0% 3573022720/3637557248 (98.2%) @4.4x, remaining 0:05 RBU 0.0% UBU 19.0% 3592814592/3637557248 (98.8%) @4.3x, remaining 0:03 RBU 3.5% UBU 28.6% 3612934144/3637557248 (99.3%) @4.4x, remaining 0:02 RBU 1.2% UBU 28.6% 3634331648/3637557248 (99.9%) @4.6x, remaining 0:00 RBU 0.0% UBU 14.3% /dev/hdb: flushing cache /dev/hdb: updating RMA /dev/hdb: closing disc growisofs command: ----------------------- /usr/bin/growisofs -Z /dev/hdb=/dev/fd/0 -use-the-force-luke=notray -use-the-force-luke=tty -use-the-force-luke=tracksize:1776151 -dvd-compat -speed=16 -use-the-force-luke=bufsize:32m
OK ... moved to another machine and burned a small CD.K3B there is also 1.0.4. It wrote successfully and failed verify. The resulting CD has the same SHA1SUM as the .iso it came from. So ... final test. It's a Fedora boot image, so I'm going to boot it and see if it passes its internal test.
1.0.5 should fix this (please try): "Always wait for the drive to become ready before starting verification (this should fix some of the problems with failed verification where K3b claims that no medium is in the drive.)"
The problem is not solved with the 1.0.5 version of k3B. It still occurs in the same way. There an even more stupid error. When a CD is erased prior to the burn, k3b doesn't wait that the CD is reloaded and fails directly because it can't find the CD !
It seems this problem is finally solved in k3b 1.0.5-r3.
