Bug#688229: Burning data DVD looks successful but mounting fails
Paul Menzel
pm.debian at googlemail.com
Wed Oct 10 22:31:30 UTC 2012
Dear Thomas,
Am Mittwoch, den 10.10.2012, 11:42 +0200 schrieb Thomas Schmitt:
> i think i can spot a byte eating problem in
> http://git.gnome.org/browse/brasero/commit/?id=5ff86b48
> resp. the master-branch commit
> http://git.gnome.org/browse/brasero/commit/?id=1b8397ee252df2d554682ca2d694d5937fbf6e39
>
> ---------------------------------------------------------------------
> @@ -200,6 +198,7 @@ brasero_libisofs_write_image_to_fd_thread (BraseroLibisofs *self)
> brasero_job_get_fd_out (BRASERO_JOB (self), &fd);
> BRASERO_JOB_LOG (self, "Writing to pipe");
> + read_bytes = priv->libburn_src->read_xt (priv->libburn_src, buf, sector_size);
> while (priv->libburn_src->read_xt (priv->libburn_src, buf, sector_size) == sector_size) {
> if (priv->cancel)
> break;
> ---------------------------------------------------------------------
>
> Variable read_bytes is set by a call of libisofs' resp. libburn's
> burn_source.read_xt() which consumes data (one sector ?) into buf.
> The call in the while() statement consumes another sector and thus
> overwrites the previously read buffer without having done anything else
> with that first buffer content.
>
> Further down i see a similar change that looks more plausible
> to me:
> ---------------------------------------------------------------------
> @@ -254,7 +261,8 @@ brasero_libisofs_write_image_to_file_thread (BraseroLibisofs *self)
> priv = BRASERO_LIBISOFS_PRIVATE (self);
> brasero_job_start_progress (BRASERO_JOB (self), FALSE);
> - while (priv->libburn_src->read_xt (priv->libburn_src, buf, sector_size) == sector_size) {
> + read_bytes = priv->libburn_src->read_xt (priv->libburn_src, buf, sector_size);
> + while (read_bytes == sector_size) {
> if (priv->cancel)
> break;
> ---------------------------------------------------------------------
I will try to make that adaptation tomorrow.
> It appears to me that this information is not yet known in
> https://bugzilla.gnome.org/show_bug.cgi?id=630651
> Feel free to add my technical opinion to that bug report.
I did so right after reading your reply in the morning.
> I will try to contact Philippe Rouquier directly on this issue.
We can just CC him and I am doing so now. Sorry Philippe.
> Swallowing the first sector is enough to make the image not mountable.
>
> But regrettably a single lost sector does not yet explain the fact
> that we find Joliet data at block 16.
> The normal layout of an ISO 9660 image with Joliet (and no
> El Torito boot equipment) would be
> Block 16: ISO (660/ECMA-119 Primary Volume Descriptor
> Block 17: Joliet Volume Descriptor (which would not contain
> names of payload files like IMG_2428.JPG)
> Block 18: Volume Descriptor Set Terminator
> libisofs will then pad up to 64 KB and first write the
> ISO 9660 + Rock Ridge tree. Several blocks to be expected.
>
> Only then comes the Joliet directory tree with those entries
> which we found at block 16.
>
> So we look for a byte eater that swallows at least a few dozen
> sectors and not only the first one.
I am also going to print out the sector size. (Or just use GDB.)
> Nevertheless, the code pieces, where above change was made,
> look much like the place where the emerging damage of an
> ISO 9660 image can be watched ... if it is not caused there.
> A very good starting point for debugging, i'd say.
>
> Telling from the function names, i would say the change which
> i deem bad is in charge for writing to optical media, whereas
> the good one is in charge for writing image to a file in hard
> disk.
> An according difference in success can be found in several
> Brasero bug reports of the last years.
Thanks for the terrific analysis. I think we can be optimistic for
tomorrow. I know also got a case where even an error is reported and the
image (with the burner hack) is not mountable.
BraseroBurn: (at burn-job.c:1858) BraseroLibburn called brasero_job_set_current_action
BraseroBurn: (at burn-libisofs.c:312) BraseroLibisofs Getting out thread
BraseroBurn: (at burn-job.c:1309) BraseroLibisofs called brasero_job_get_fd_out
BraseroBurn: (at burn-job.c:1071) BraseroLibisofs Finished track successfully
BraseroBurn: (at burn-task-ctx.c:354) No next track to process
BraseroBurn: (at burn-job.c:862) BraseroLibisofs disconnecting BraseroLibisofs from BraseroChecksumImage
BraseroBurn: (at burn-job.c:258) BraseroLibisofs deactivating
BraseroBurn: (at burn-job.c:1267) BraseroChecksumImage called brasero_job_get_current_track
BraseroBurn: (at burn-checksum-image.c:531) BraseroChecksumImage Setting new checksum (type = 2) 75f26d2175cb8d2a6d3370a2b7aa0164 (file:///tmp/brasero_tmp_JL20LW.md5 before)
BraseroBurn: (at burn-job.c:1071) BraseroChecksumImage Finished track successfully
BraseroBurn: (at burn-task-ctx.c:354) No next track to process
BraseroBurn: (at burn-job.c:862) BraseroChecksumImage disconnecting BraseroChecksumImage from BraseroLibburn
BraseroBurn: (at burn-job.c:881) BraseroChecksumImage closing connection for BraseroChecksumImage
BraseroBurn: (at burn-job.c:258) BraseroChecksumImage deactivating
BraseroBurn: (at burn-libburn-common.c:218) BraseroLibburn Premature end of input encountered. Missing: 2048 bytes
BraseroBurn: (at burn-job.c:1787) BraseroLibburn called brasero_job_get_session_output_size
BraseroBurn: (at burn-job.c:1858) BraseroLibburn called brasero_job_set_current_action
BraseroBurn: (at burn-libburn-common.c:218) BraseroLibburn syncing cache (stdio fsync)
BraseroBurn: (at burn-libburn.c:852) BraseroLibburn Something went wrong
BraseroBurn: (at burn-job.c:1138) BraseroLibburn called brasero_job_error
BraseroBurn: (at burn-job.c:1140) BraseroLibburn finished with an error
BraseroBurn: (at burn-job.c:1174) BraseroLibburn asked to stop because of an error
error = 15
message
** (brasero:6925): WARNING **: Failed to restore the system power manager: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
(brasero:6925): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion `width >= -1' failed
= "Ein Fehler trat beim Beschreiben der CD/DVD auf"
BraseroBurn: (at burn-task.c:177) BraseroLibisofs already stopped
BraseroBurn: (at burn-task.c:177) BraseroChecksumImage already stopped
BraseroBurn: (at burn-task.c:182) stopping BraseroLibburn
BraseroBurn: (at burn-job.c:906) BraseroLibburn stopping
BraseroBurn: (at burn-libburn-common.c:116) Stopping Drive
BraseroBurn: (at burn-libburn-common.c:51) Drive stopped
BraseroBurn: (at burn-job.c:881) BraseroLibburn closing connection for BraseroLibburn
BraseroBurn: (at burn-task.c:190) stopped BraseroLibburn
BraseroBurn: (at burn-task.c:445) got out of loop
BraseroBurn: (at burn-task.c:177) BraseroLibisofs already stopped
BraseroBurn: (at burn-task.c:177) BraseroChecksumImage already stopped
BraseroBurn: (at burn-task.c:177) BraseroLibburn already stopped
BraseroBurn: (at brasero-burn.c:392) Ejecting drive/medium
BraseroBurn: (at brasero-burn.c:443) Retrying ejection
BraseroBurn: (at brasero-burn.c:2856) Session error : Ein Fehler trat beim Beschreiben der CD/DVD auf
BraseroBurn: (at brasero-session.c:2388) Cleaning session
BraseroBurn: (at brasero-session.c:2366) Cleaning /tmp/brasero_tmp_JL20LW.md5
Maybe that one was lost in my original report due to missing debug
options. Since I was asked about saving the session log.
$ dd if=/tmp/my_emulated_drive bs=2048 skip=16 count=1 | od -c
[…]
0000000 377 330 377 340 \0 020 J F I F \0 001 001 001 \0 H
0000020 \0 H \0 \0 377 341 6 245 E x i f \0 \0 I I
0000040 * \0 \b \0 \0 \0 \v \0 017 001 002 \0 \n \0 \0 \0
0000060 222 \0 \0 \0 020 001 002 \0 \b \0 \0 \0 234 \0 \0 \0
0000100 022 001 003 \0 001 \0 \0 \0 001 \0 \0 \0 032 001 005 \0
0000120 001 \0 \0 \0 244 \0 \0 \0 033 001 005 \0 001 \0 \0 \0
0000140 254 \0 \0 \0 ( 001 003 \0 001 \0 \0 \0 002 \0 \0 \0
0000160 1 001 002 \0 \v \0 \0 \0 264 \0 \0 \0 2 001 002 \0
0000200 024 \0 \0 \0 300 \0 \0 \0 023 002 003 \0 001 \0 \0 \0
0000220 002 \0 \0 \0 i 207 004 \0 001 \0 \0 \0 244 001 \0 \0
0000240 245 304 \a \0 320 \0 \0 \0 324 \0 \0 \0 B 036 \0 \0
0000260 P a n a s o n i c \0 D M C - F Z
0000300 8 \0 H \0 \0 \0 001 \0 \0 \0 H \0 \0 \0 001 \0
0000320 \0 \0 G I M P 2 . 6 . 7 \0 \0 2 0
0000340 1 0 : 0 1 : 0 3 1 5 : 5 3 : 0
0000360 7 \0 P r i n t I M \0 0 2 5 0 \0 \0
0000400 016 \0 001 \0 026 \0 026 \0 002 \0 \0 \0 \0 \0 003 \0
0000420 d \0 \0 \0 \a \0 \0 \0 \0 \0 \b \0 \0 \0 \0 \0
0000440 \t \0 \0 \0 \0 \0 \n \0 \0 \0 \0 \0 \v \0 254 \0
0000460 \0 \0 \f \0 \0 \0 \0 \0 \r \0 \0 \0 \0 \0 016 \0
0000500 304 \0 \0 \0 \0 001 005 \0 \0 \0 001 001 001 \0 \0 \0
0000520 020 001 200 \0 \0 \0 \t 021 \0 \0 020 ' \0 \0 \v 017
0000540 \0 \0 020 ' \0 \0 227 005 \0 \0 020 ' \0 \0 260 \b
0000560 \0 \0 020 ' \0 \0 001 034 \0 \0 020 ' \0 \0 ^ 002
0000600 \0 \0 020 ' \0 \0 213 \0 \0 \0 020 ' \0 \0 313 003
0000620 \0 \0 020 ' \0 \0 345 033 \0 \0 020 ' \0 \0 \0 \0
0000640 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000700 \0 \0 " \0 232 202 005 \0 001 \0 \0 \0 B 003 \0 \0
0000720 235 202 005 \0 001 \0 \0 \0 J 003 \0 \0 " 210 003 \0
[…]
The `dd` with the `skip` is correct, I guess? I just want to be sure.
$ dd if=/tmp/my_emulated_drive bs=30720 count=1 | od -c
[…]
0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0040000 002 C D 0 0 1 001 \0 \0 \0 \0 \0
0040020 \0 \0 \0 \0 \0 \0 \0 \0
0040040 \0 \0 \0 \0 \0 D \0 a \0 t \0 e
0040060 \0 n \0 - \0 C \0 D \0 / \0 D \0 V \0 D
0040100 \0 \0 ( \0 1 \0 0 \0 \0 \0 \0 \0 \0 \0 \0
0040120 317 271 \0 \0 \0 \0 271 317 % / E \0 \0 \0 \0 \0
0040140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0040160 \0 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 001 001 \0 \0 001
0040200 \0 \b \b \0 036 \0 \0 \0 \0 \0 \0 036 035 \0 \0 \0
0040220 \0 \0 \0 \0 \0 \0 \0 036 \0 \0 \0 \0 " \0 032 \0
0040240 \0 \0 \0 \0 \0 032 \0 \b \0 \0 \0 \0 \b \0 p \n
0040260 \n 025 032 016 \0 002 \0 \0 001 \0 \0 001 001 \0 \0 D
0040300 \0 a \0 t \0 e \0 n \0 - \0 C \0 D \0 /
0040320 \0 D \0 V \0 D \0 \0 ( \0 1 \0 0 \0
0040340 \0 O \0 k \0 t \0 \0 1 \0 2 \0 ) \0
0040360 \0 \0 \0 \0 \0 \0 \0 \0
*
0040460 \0 \0 \0 \0 \0 \0 \0 \0 B
0040500 \0 r \0 a \0 s \0 e \0 r \0 o \0 - \0 3
0040520 \0 . \0 4 \0 . \0 1 \0 \0 \0 \0
0040540 \0 \0 \0 \0 \0 \0 \0 \0
[…]
So some data seems to be there written beforehand.
Thanks,
Paul
PS: Summary for tomorrow. Adapt the patch, print out sector size and
test this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20121011/ce06e360/attachment.pgp>
More information about the pkg-gnome-maintainers
mailing list