Bug#594753: brasero: Brasero burns corrupted data DVDs.

Paul Menzel pm.debian at googlemail.com
Sat Nov 17 21:16:12 UTC 2012

Dear Vincent,

thank you for following up on this report.

Am Samstag, den 17.11.2012, 00:56 +0100 schrieb Vincent Lefevre:
> On 2012-10-12 13:23:20 +0200, Paul Menzel wrote:
> > Am Dienstag, den 20.12.2011, 01:49 +0100 schrieb Vincent Lefevre:
> > > I've burnt a data DVD with brasero and got no errors (except that the
> > > DEBUG messages in the terminal were inconsistant with the dialog: when
> > > a DEBUG message said X %, it was actually X/2 % in the dialog... now,
> > > I don't know whether this is related to this bug). But when I want to
> > > mount it, I get:
> > > 
> > > mount: wrong fs type, bad option, bad superblock on /dev/sr0,
> > >        missing codepage or helper program, or other error
> > >        In some cases useful info is found in syslog - try
> > >        dmesg | tail  or so
> [...]
> > I am pretty sure this #688229 [2] which is fixed in Brasero 3.4.1-4.
> > Could you please test these packages?
> I still get the same mount error with a DVD burnt using brasero 3.4.1-4
> if I use the "-t udf" mount option. Without it, the DVD can be read
> normally. No such problem when I burn the DVD with growisofs -R -J -udf.

> The "-t udf" is necessary with some DVD's, otherwise I get corrupt data
> and also private directories readable by everyone. So, it should really
> be supported.

LStranger in #lxde told me the same some days ago. Unfortunately I have
no clue and do not understand that, as you wrote it works fine *without*
-udf. As this is a different issue than the one from the original
reporter, could you please submit a separate report for it also
describing exactly the steps you are doing to burn the DVD (including
what plugins) and attaching the log files created with the following

        $ brasero -g | tee `date +%Y%m%d-%H%M`--brasero.log

This is important as looking at Brasero’s source code I thought it is
also passing `-udf` to growisofs/genisoimage. We have to find out what
command is actually used to compose the image.

Unfortunately upstream is not maintained currently, but I hope somebody
will step up and provide a fix.


-------------- 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/20121117/b5c9080e/attachment-0001.pgp>

More information about the pkg-gnome-maintainers mailing list