Burning an ISO image with brasero reports an error after creating the checksum of the new disk. Excerpt from the brasero-session.log: [[Creating initial checksum]] BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_flags BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_fd_in BraseroChecksumImage called brasero_job_set_output_size_for_current_track BraseroChecksumImage stopping BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_flags BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_session_output_size BraseroChecksumImage output set (IMAGE) image = /data2/brasero_tmp_A2LQZV.bin toc = none BraseroChecksumImage called brasero_job_get_session_output_size BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage called brasero_job_get_input_type BraseroChecksumImage called brasero_job_set_current_action BraseroChecksumImage called brasero_job_get_fd_in BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage Starting checksuming file /data2/six/LOST_S1D1.iso (size = 7695859712) BraseroChecksumImage called brasero_job_get_fd_out BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage Setting new checksum (type = 2) 2bd5e55746c1fd03a3143271626e49c5 ((null) before) BraseroChecksumImage Finished track successfully BraseroChecksumImage stopping [[Burning Disk]] BraseroReadom Launching command BraseroReadom called brasero_job_get_fd_in BraseroReadom called brasero_job_get_fd_out BraseroReadom stderr: Read speed: 11080 kB/s (CD 62x, DVD 8x). BraseroReadom stderr: Write speed: 11080 kB/s (CD 62x, DVD 8x). BraseroReadom stderr: Capacity: 3757744 Blocks = 7515488 kBytes = 7339 MBytes = 7695 prMB BraseroReadom called brasero_job_set_current_action BraseroReadom stderr: Sectorsize: 2048 Bytes BraseroReadom stderr: Copy from SCSI (4,0,0) disk to file '-' BraseroReadom stderr: end: 3757744 BraseroReadom stderr: addr: 0 cnt: 128 BraseroReadom called brasero_job_get_output_type BraseroReadom stderr: resid: 260178 BraseroReadom stderr: BraseroReadom stderr: Time total: 0.000sec BraseroReadom stderr: Read 0.00 kB at 0.0 kB/sec. BraseroReadom stderr: HUP BraseroReadom process finished with status 0 BraseroReadom Finished track successfully BraseroReadom called brasero_job_get_done_tracks BraseroReadom called brasero_job_get_fd_out BraseroReadom disconnecting BraseroReadom from BraseroChecksumImage BraseroReadom deactivating [[Creating checksum of burned disk]] BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage Setting new checksum (type = 2) d41d8cd98f00b204e9800998ecf8427e (2bd5e55746c1fd03a3143271626e49c5 before) BraseroChecksumImage called brasero_job_error BraseroChecksumImage finished with an error BraseroChecksumImage asked to stop because of an error error = 27 message = "Some files may be corrupted on the disc" BraseroChecksumImage stopping BraseroChecksumImage closing connection for BraseroChecksumImage Session error : Some files may be corrupted on the disc (brasero_burn_record brasero-burn.c:2856) However, the error appears bogus: [ftg@ftgme2 six]$ cmp -l LOST_S1D1.iso /dev/sr0 [ftg@ftgme2 six]$ Comparing the ISO image used as source with the raw data on the burned disk shows no differences. Likewise, a "dd" of the burned disk to /dev/null encounters no I/O errors. This doesn't happen every time, but it happens more than half the time.
Please report the issue upstream.
I piggybacked on a similar older bug. However, there are several open bugs for brasero checksums that have no resolution and have seen no activity for months, in spite of the developer posting that he would follow up. Also, see http://www.zyxware.com/articles/615/solution-to-checksum-error-and-md5-sum-error-in-brasero-k3b-and-other-burning-software
URL: (none) => https://bugzilla.gnome.org/show_bug.cgi?id=636658
Keywords: (none) => UPSTREAM
*** Bug 782 has been marked as a duplicate of this bug. ***
CC: (none) => lunruj
Assignee: bugsquad => eandry
Nothing changed in the bug report Frank linked to, I didn't look for the others he mentioned.
CC: (none) => marja11
Keywords: (none) => NO_PATCH
Assignee: eandry => bugsquad
This still happens, not every time, but most times. I burn a lot of DVDs for my backup system, and in almost a year now I think I had exactly one faulty burn. For every other one of the 75% that report a checksum failure, the subsequent cmp shows that the disk matches the ISO exactly.
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
@ Frank, Same question (yes, it isn't likely anything changed, but we need to be sure) Is this bug still valid for Mageia 2 or for *current* cauldron (so from after Mageia 2 was released). If so, please remove NEEDINFO from the Keywords and put MGA2TOO on the whiteboard. Thanks :)
Still happening.
Keywords: NEEDINFO => (none)Whiteboard: (none) => MGA2TOO
I'm going out on a limb and say this has been fixed. In the last couple of months, I've only seen one claimed burn failure, and it actually was a failure (cmp reported "EOF on /dev/sr1" when comparing to the ISO).
Status: NEW => RESOLVEDResolution: (none) => FIXED