GNOME Bugzilla – Bug 630651
Basero creating incomplete image (.ISO) files
Last modified: 2012-10-13 13:35:02 UTC
I was testing to see if Brasero 2.31.92 fixed Bug 614522, but when I made the test burn, Brasero only claimed to (successfully) burn 750MB of the ~5GB that should have been burnt, and the actual image size is shown below (smaller than even just the md5sum file should be), along with a good burn made using Fedora 11. $ ls -l *.iso -rw-r--r-- 1 noel noel 2097152 2010-09-26 12:30 brasero.iso -rw-rw-r-- 1 noel noel 5090373632 2010-03-18 12:17 piccolo.iso This problem is reproducible. I have not tried burning this project to a disc, but it totally fails to create the ISO image. I have reproduced this with Fedora 13 (2.30.2) and Ubuntu Maverick (2.31.92).
Thanks for the report. Could you try again to get a log for the failing image creation running "brasero -g > log 2>&1" and attach that file "log" to this bug please? Also when you mention fedora, do you mean that with the brasero version from fedora 11 you do not have the same results while doing the exact same thing?
Created attachment 171229 [details] gzip compressed log from failed burn Attached is a log. In this log, both this bug and bug 614522 are manifested. The latter is not consistent with this release. Sometimes the missing YACL directory does appear. Note: brasero (libisofs)DEBUG : Skipping excluded file /mnt/SHARE/userdir/noel/vmware/Piccolo-Recovery/converted-to-tar/DRIVE-I (WORK)/NJB/DEVTECH/2BPORTED/YACL and there are a total of 282 files so noted. I did not ask for any files to be skipped -- I choose to handle files with more than 7 parents, and to disable full MS-Windows compatibility.
And, yes, the version of brasero (2.26.3) in Fedora 11 works.
You seem to be using the libisofs plugin and I'd like to know if it would work with the mkisofs one. Could set the GConf key /apps/brasero/config/priority/libisofs-image to -1 and re-run brasero (preferably with the same files) to see if you still have the same problems please? Also what is your version of libisofs?
Note that could explain the fact that brasero works on one and not the other fedora and ubuntu having two different versions of libisofs.
Created attachment 171234 [details] gzip compressed log from failed burn (after trying to switch to mkisofs) Please note that brasero fails (this bug) in Fedora 13, Ubuntu 10.04 and Ubuntu 10.10. So BOTH Fedora and Ubuntu fail. Attached is a log from applying your comment #4 request. No change in observed behavior. But it doesn't appear to have worked as you expect. See the log and attached screen capture showing that I had, in fact, set the GConf key as requested.
Created attachment 171235 [details] screen cap of gconf-editor showing /apps/brasero/config/priority/
Ubuntu 10.10: libisofs6 0.6.32-2 genisoimage 9:1.1.10-1ubuntu3
I have the same problem with brasero 2.30.3-1 on Debian Squeeze. Libisofs returns an error: brasero (libisofs)MISHAP : Image write cancelled brasero seems to ignore it, continues the burn process and ends up creating an unusable disc (or a mostly empty ISO). See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598137 for more information, including brasero -g output.
FWIW, libburn, exercised on the same directory tree by: $ xorriso -outdev /home/noel/Desktop/xorriso.iso -add * works perfectly. genisoimage fails miserably, having major issues with deep paths, regardless of passing the necessary options.
Still broken in 2.32, which just hit Ubuntu tonight.
I pushed in all branches a patch (from 2.30 to master). Could you test it please? This should help. Thanks master: http://git.gnome.org/browse/brasero/commit/?id=1b8397ee252df2d554682ca2d694d5937fbf6e39 gnome-2-32: http://git.gnome.org/browse/brasero/commit/?h=gnome-2-32&id=5ff86b483a3443bafddfd1c77ac524548bfa7ff1 gnome-2-30: http://git.gnome.org/browse/brasero/commit/?h=gnome-2-30&id=d059a2d8d0b806941251996f0179bea8440ff4e8
Note it may also be fix #614522
Good news and bad news ... this patch, which I've applied to Ubuntu 10.10's 2.32.0 package, as per the typical instructions for doing a package update, does fix this bug. It does NOT fix bug 614522, which is caused by brasero failing to include the directory.
OK, thanks a lot for testing. At least I think we can close a bug. As soon as things settle down a bit on the GNOME3 porting front and I have more time, I'll see to close the other one. I'll close this bug then.
Michael Biebl’s bisecting shows, that this patch breaks burning data DVDs by not burning the first bytes of the ISO image and therefore the image is not recognized trying to mount them. Here are some excerpts from the Debian report 688229 [1]. --- begin quote --- $ sudo mount /dev/sr1 /mnt/ mount: block device /dev/sr1 is write-protected, mounting read-only mount: you must specify the filesystem type $ sudo mount -t iso9660 /dev/sr1 /mnt/ mount: block device /dev/sr1 is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/sr1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so $ dmesg | tail [ 9060.705009] REISERFS warning (device sr1): sh-2021 reiserfs_fill_super: can not find reiserfs on sr1 [ 9060.802444] EXT4-fs (sr1): VFS: Can't find ext4 filesystem [ 9094.689488] EXT3-fs (sr1): error: can't find ext3 filesystem on dev sr1. [ 9094.745374] XFS (sr1): bad magic number [ 9094.745385] XFS (sr1): SB validate failed [ 9094.781053] REISERFS warning (device sr1): sh-2021 reiserfs_fill_super: can not find reiserfs on sr1 [ 9094.891956] EXT4-fs (sr1): VFS: Can't find ext4 filesystem [ 9103.723566] calling init_iso9660_fs+0x0/0x67 [isofs] @ 12239 [ 9103.723679] initcall init_iso9660_fs+0x0/0x67 [isofs] returned 0 after 91 usecs [ 9103.816252] ISOFS: Unable to identify CD-ROM format. […] Paul Menzel wrote: > $ dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c > ... > 0000000 > \0 0 034 001 \0 \0 001 034 0 F 034 + \0 \0 + > 0000020 034 F p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 > 0000040 034 \0 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 > 0000060 8 \0 . \0 J \0 P \0 G \0 ; \0 1 \0 > \0 > 0000100 224 ! 001 \0 \0 001 ! 224 @ 276 + \0 \0 + 276 @ > 0000120 p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 > 0000140 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 9 \0 > 0000160 . \0 J \0 P \0 G \0 ; \0 1 \0 > \0 \f ' This does not look like an ISO 9660 Primary Volume Descriptor but rather like a snippet from a Joliet directory tree. Read as 16 bit characters one can recognize "IMG_2428.JPG" and "IMG_2429.JPG". They are announced to start at blocks 72752 (decimal) and 74132 (decimal). Sizes are 2825286 and 2866752 bytes. ... if i decoded these little endian 32-bit numbers correctly: 0 034 001 \0 IMG_2428.JPG, Location of Extent F 034 + \0 IMG_2428.JPG, Data Length 224 ! 001 \0 IMG_2429.JPG, Location of Extent @ 276 + \0 IMG_2429.JPG, Data Length (The layout of directory records is documented in ECMA-119, 9.1. Joliet deviates from this layout mainly by using 16-bit characters for File Identifier.) I really wonder how this could get to block 16 of the medium. Brasero did order libisofs to produce a Joliet tree. But it should be stored several blocks after block 16. Before Joliet there should be volume descriptors and the ISO 9660 + Rock Ridge tree. It is clear that no reader software wants to accept this as ISO 9660 filesystem. Guessing from this single block content, i would expect that a few hundred kilobytes of the image start have not been written onto the medium. Most simple explanation for this would be that they were not transmitted from libisofs to libburn. But i riddle how this could be possible. --- end quote --- [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688229
Thanks to Thomas Schmitt’s awesome unbeatable fast response time, we might already have some clue what went wrong [1]. I paste it here. Am Mittwoch, den 10.10.2012, 11:42 +0200 schrieb Thomas Schmitt: > Hi, > > 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; > --------------------------------------------------------------------- > > 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 will try to contact Philippe Rouquier directly on this issue. > > > 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. > > > 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. > > > Have a nice day :) > > Thomas [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688229#64
I created bug 685983 for the regression and attached the patch there. [1] [1] https://bugzilla.gnome.org/show_bug.cgi?id=685983
hed Bug 630651 - Basero creating incomplete image (.ISO) files - RESOLVED - FIXED