Bug#688229: Burning data DVD looks successful but mounting fails
Hi, I am also going to print out the sector size. (Or just use GDB.) The loop condition (read_bytes == sector_size) suggests that it must be 2048. Only this alignment is guaranteed for the output of libisofs. (Actually it would be a good reason for the 50 % bug if libisofs would not obey this alignment. But i am sure it does.) BraseroBurn: (at burn-libburn-common.c:218) BraseroLibburn Premature end of input encountered. Missing: 2048 bytes This is a message of libburn. Obviously the image size was pre-announced to libburn and it noticed a shortage when the input stream ended. Regrettably the number 2048 might not be an indication of the exact missing amount. It should be exact if libburn-1.2.4 is in use. Earlier versions always reported 2048. Fixed by http://libburnia-project.org/changeset/4762 Libburn version can be inquired by cdrskin -version libburn-1.2.4 should be installed as libburn.so.4.77.0 $ dd if=/tmp/my_emulated_drive bs=2048 skip=16 count=1 | od -c 000 377 330 377 340 \0 020 J F I F \0 001 001 001 \0 H This looks like the data start of a JPEG file. The data blocks of file content come after the trees. So this time the burn seems to have skipped even more blocks than with the original run. $ dd if=/tmp/my_emulated_drive bs=30720 count=1 | od -c 004 002 C D 0 0 1 001 \0 \0 \0 \0 \0 This is the Joliet Volume Descriptor. It should sit at block 17. So it looks like we lose 17 blocks at start. If the image does not contain only very few files, then we seem to lose further blocks inbetween. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688229: Burning data DVD looks successful but mounting fails
Hi, i have to correct myself: 004 002 C D 0 0 1 001 \0 \0 \0 \0 \0 i wrote: It should sit at block 17. So it looks like we lose 17 blocks at start. Well, it sits now at block 8. So we lost 9 blocks before it. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688229: Burning data DVD looks successful but mounting fails
Hi,
staring at lines 201, 202, and 216 of
http://git.gnome.org/browse/brasero/tree/plugins/libburnia/burn-libisofs.c
i realize that this loop drops every second block !
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) {
... process block that was read by while() statement ...
read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size);
}
This would well explain why block 17 ends up at block 8.
It is tempting to also claim victory over the 50 % bug, but i
cannot yet make up a plausible explanation. With the 50% bug
https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117
it is libisofs which reports 50 % progress, when loop or libburn
close the shop.
The many CD complaints in this Ubuntu bug could well be caused
by above killer loop, though.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688229: Burning data DVD looks successful but mounting fails
Dear Thomas,
Am Donnerstag, den 11.10.2012, 11:40 +0200 schrieb Thomas Schmitt:
staring at lines 201, 202, and 216 of
http://git.gnome.org/browse/brasero/tree/plugins/libburnia/burn-libisofs.c
i realize that this loop drops every second block !
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) {
... process block that was read by while() statement ...
read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size);
}
This would well explain why block 17 ends up at block 8.
It is tempting to also claim victory over the 50 % bug, but i
cannot yet make up a plausible explanation. With the 50% bug
https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117
it is libisofs which reports 50 % progress, when loop or libburn
close the shop.
The many CD complaints in this Ubuntu bug could well be caused
by above killer loop, though.
As already spoilered in my reply to #690207 [1], with the libburn output
patch attached it confirms that half of the bytes are missing.
BraseroBurn: (at burn-libburn-common.c:218) BraseroLibburn Premature
end of input encountered. Missing: 48709632 bytes
These are around 47 MB and indeed comparing the sizes yields the
following.
$ du -sh folder
94M /home/joey/folder
$ du -sh /tmp/my_emulated_drive
47M /tmp/my_emulated_drive
So all the bugs seem to be the same and Brasero just displays the error
differently or it is not noticeable with smaller amounts that the
progress bar stopped earlier.
I will try to cook up a patch for fixing the loop now.
Thanks,
Paul
[1] http://bugs.debian.org/690207
signature.asc
Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Dear Thomas,
Am Donnerstag, den 11.10.2012, 13:19 +0200 schrieb Paul Menzel:
Am Donnerstag, den 11.10.2012, 11:40 +0200 schrieb Thomas Schmitt:
staring at lines 201, 202, and 216 of
http://git.gnome.org/browse/brasero/tree/plugins/libburnia/burn-libisofs.c
i realize that this loop drops every second block !
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) {
... process block that was read by while() statement ...
read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size);
}
This would well explain why block 17 ends up at block 8.
It is tempting to also claim victory over the 50 % bug, but i
cannot yet make up a plausible explanation. With the 50% bug
https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117
it is libisofs which reports 50 % progress, when loop or libburn
close the shop.
The many CD complaints in this Ubuntu bug could well be caused
by above killer loop, though.
As already spoilered in my reply to #690207 [1], with the libburn output
patch attached it confirms that half of the bytes are missing.
BraseroBurn: (at burn-libburn-common.c:218) BraseroLibburn Premature
end of input encountered. Missing: 48709632 bytes
These are around 47 MB and indeed comparing the sizes yields the
following.
$ du -sh folder
94M /home/joey/folder
$ du -sh /tmp/my_emulated_drive
47M /tmp/my_emulated_drive
So all the bugs seem to be the same and Brasero just displays the error
differently or it is not noticeable with smaller amounts that the
progress bar stopped earlier.
I will try to cook up a patch for fixing the loop now.
It looks like it is as simple as the following.
diff --git a/plugins/libburnia/burn-libisofs.c
b/plugins/libburnia/burn-libisofs.c
index 3c25224..3919281 100644
--- a/plugins/libburnia/burn-libisofs.c
+++ b/plugins/libburnia/burn-libisofs.c
@@ -199,7 +199,7 @@ brasero_libisofs_write_image_to_fd_thread (BraseroLibisofs
*self)
BRASERO_JOB_LOG (self, Writing to pipe with sector size %i bytes,
sector_size);
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) {
+ while (read_bytes == sector_size) {
if (priv-cancel)
break;
I am building it right now.
Thanks,
Paul
[1] http://bugs.debian.org/690207
signature.asc
Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Hi,
- while (priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size) == sector_size) {
+ while (read_bytes == sector_size) {
I am building it right now.
Crossing fingers ...
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688229: Burning data DVD looks successful but mounting fails
Dear Thomas,
Am Donnerstag, den 11.10.2012, 15:06 +0200 schrieb Thomas Schmitt:
- while (priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size) == sector_size) {
+ while (read_bytes == sector_size) {
I am building it right now.
Crossing fingers ...
That helped. After taking some time to figure out that I had not
actually installed the build patched packages, it *worked* indeed!
Brasero even plays a sound on success.
Mounting the image works and just for completeness here is the ISO9660
header(?).
$ dd if=/tmp/my_emulated_drive bs=2048 skip=16 count=1 | od -c
1+0 Datensätze ein
1+0 Datensätze aus
2048 Bytes (2,0 kB) kopiert, 0,000105318 s, 19,4 MB/s
000 001 C D 0 0 1 001 \0
020
040 D a t e n - C D
060 / D V D ( 1 1 O k t 1 2 )
100 \0 \0 \0 \0 \0 \0 \0 \0
120 317 271 \0 \0 \0 \0 271 317 \0 \0 \0 \0 \0 \0 \0 \0
140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
160 \0 \0 \0 \0 \0 \0 \0 \0 001 \0 \0 001 001 \0 \0 001
200 \0 \b \b \0 030 \0 \0 \0 \0 \0 \0 030 030 \0 \0 \0
220 \0 \0 \0 \0 \0 \0 \0 031 \0 \0 \0 \0 \0 023 \0
240 \0 \0 \0 \0 \0 023 \0 \b \0 \0 \0 \0 \b \0 p \n
260 \v \r 032 / \0 002 \0 \0 001 \0 \0 001 001 \0 D a
300 t e n - C D / D V D ( 1 1 O
320 k t 1 2 )
340
*
460 B R
500 A S E R O - 3 . 4 . 1
520
*
660 P A
700 U L M E N Z E L
720
*
0001440 2 0 1
0001460 2 1 0 1 1 1 3 2 6 4 7 0 0 \0 2 0
0001500 1 2 1 0 1 1 1 3 2 6 4 7 0 0 \0 \0
0001520 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0001560 \0 001 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0001600 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0004000
Hmm, it encodes the name in there. To all whistle blowers out there: Do
not use Brasero without configuring beforehand. ;-)
Thomas, I am going to write the commit message now.
Thanks,
Paul
PS: Thomas, reading the libburnia start page [1], I see you take
donations. If some users, benefiting from this patch want to donate
something, I would like the libburnia project to have it. So it would be
great if you could give me the necessary instructions.
[1] http://libburnia-project.org/
signature.asc
Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Hi, 000 001 C D 0 0 1 001 \0 Yes. That is the start of a Primary Volume Descriptor block. Please mount the medium and use diff to compare the files in the image with their originals on hard disk. Just to be sure. (Mounting does not check all blocks in the image for sanity.) Hmm, it encodes the name in there. To all whistle blowers out there: Do not use Brasero without configuring beforehand. ;-) (Who told your computer your full name on the first hand ?) ECMA-119 says about that field in the PVD: 8.4.21 Data Preparer Identifier (BP 447 to 574) This field shall specify an identification of the person or other entity which controls the preparation of the data to be recorded on the Volume Group of which the volume is a member. I would rather use it to identify the image generating program. (I do so in xorriso. E.g.: XORRISO-1.2.5 2012.09.15.170346, LIBISOBURN-1.2.5, LIBISOFS-1.2.5, LIBBURN-1.2.5 ) Brasero mentions itself as: 8.4.20 Publisher Identifier (BP 319 to 446) This field shall specify an identification of the user who specified what shall be recorded on the Volume Group of which the volume is a member. I would deem this field more appropriate to rat out Paul Menzel. :)) mkisofs has a third opinion on that. It advertises itself in: 8.4.22 Application Identifier (BP 575 to 702) This field shall specify an identification of the specification of how the data are recorded on the Volume Group of which the volume is a member. PS: Thomas, reading the libburnia start page [1], I see you take donations. If some users, benefiting from this patch want to donate something, I would like the libburnia project to have it. So it would be great if you could give me the necessary instructions. If you would like to donate, please mail us: mario.danic [at] gmail [dot] com, Cc: scdbackup [at] gmx [dot] net. I personally can accept donations only by my german bank account. Possibly this is feasible within the EU even with smaller amounts. Our project founder Mario Danic has a paypal account, afaik. I understand he has to pay money for the web hoster. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688229: Burning data DVD looks successful but mounting fails
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=655601
Control: tags -1 patch
Control: found -1 2.91.93-1
Control: affects -1 brasero
Am Donnerstag, den 11.10.2012, 15:44 +0200 schrieb Paul Menzel:
Am Donnerstag, den 11.10.2012, 15:06 +0200 schrieb Thomas Schmitt:
- while (priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size) == sector_size) {
+ while (read_bytes == sector_size) {
I am building it right now.
Crossing fingers ...
[…]
Thomas, I am going to write the commit message now.
Please find the patch attached.
[…]
Thanks,
Paul
From 17ad074e2ad8e3881afae148594a770f3dd7f228 Mon Sep 17 00:00:00 2001
From: Paul Menzel paulepan...@users.sourceforge.net
Date: Thu, 11 Oct 2012 14:40:06 +0200
Subject: [PATCH] Libburnia plugin: Fix while loop in `brasero_libisofs_write_image_to_fd_thread()` (#655601)
In commit 1b8397ee [1]
commit 1b8397ee252df2d554682ca2d694d5937fbf6e39
Author: Philippe Rouquier bonfire-...@wanadoo.fr
Date: Tue Oct 5 10:10:17 2010 +0200
Fix for #630651 [2] - Basero creating incomplete image (.ISO) files
distributed since Brasero 2.91.1
$ git tag --contains 1b8397ee252df2d554682ca2d694d5937fbf6e39 | sort | head -n 1
BRASERO_2_91_1
a small bug was introduced by forgetting to substitude a command with a newly introduced variable in the loop condition. This broke the loop reading out the data to be written to the disc.
This small error had a huge impacted as writing images on the fly always failed, because only half of the image was written to the disc. Several bug reports exist for this problem and are most likely due to this problem [3][4][5].
Substituting this command with the variable fixes the problem reported in GNOME Bugzilla bug 655601.
Creating this patch would not have been possible without the invaluable and quick observations and explanations of Thomas Schmitt from the libburnia project [7]. In the end Michael Biebl from the Debian project stepped up to look into this problem and bisected this problem to the above commit. Thomas Schmitt pointed out the error afterward. A big thanks to both of them and everybody else reporting errors and providing logs!
[1] http://git.gnome.org/browse/brasero/commit/?id=1b8397ee252df2d554682ca2d694d5937fbf6e39
[2] https://bugzilla.gnome.org/show_bug.cgi?id=630651
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688229
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594753
[5] https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117
[6] https://bugzilla.gnome.org/show_bug.cgi?id=655601
[7] http://libburnia-project.org/
---
plugins/libburnia/burn-libisofs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/libburnia/burn-libisofs.c b/plugins/libburnia/burn-libisofs.c
index 22cb75e..841468a 100644
--- a/plugins/libburnia/burn-libisofs.c
+++ b/plugins/libburnia/burn-libisofs.c
@@ -199,7 +199,7 @@ brasero_libisofs_write_image_to_fd_thread (BraseroLibisofs *self)
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) {
+ while (read_bytes == sector_size) {
if (priv-cancel)
break;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Hi, Paul Menzel wrote in his patch: Substituting this command with the variable fixes the problem reported in GNOME Bugzilla bug 655601. I have to stress that the found bug does _not_ explain the original report of https://bugzilla.gnome.org/show_bug.cgi?id=655601 (which is what i call the 50 % bug). I would explain several of the follow-up comments in this bug report. Especially it would explain http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617409 Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688229: Burning data DVD looks successful but mounting fails
Dear Thomas, Am Donnerstag, den 11.10.2012, 17:08 +0200 schrieb Thomas Schmitt: Paul Menzel wrote in his patch: Substituting this command with the variable fixes the problem reported in GNOME Bugzilla bug 655601. I have to stress that the found bug does _not_ explain the original report of https://bugzilla.gnome.org/show_bug.cgi?id=655601 (which is what i call the 50 % bug). you seem right. The log shows some Growisofs message and not the one I have. Although, could it be that it is dependent on the libburn version? Since when does libburn return if all data was written or not? I would explain several of the follow-up comments in this bug report. Especially it would explain http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617409 I am not so sure on this one anymore as it is reported against 2.30.3-2 which does not have the offending patch. I can imaging that it is caused by the problem the faulty patch wanted to fix [1]. But thinking about this the original reporter wrote, that his medium could be mounted. Thanks, Paul [1] https://bugzilla.gnome.org/show_bug.cgi?id=655601 signature.asc Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=685983 Dear Thomas, Am Donnerstag, den 11.10.2012, 17:26 +0200 schrieb Paul Menzel: Am Donnerstag, den 11.10.2012, 17:08 +0200 schrieb Thomas Schmitt: Paul Menzel wrote in his patch: Substituting this command with the variable fixes the problem reported in GNOME Bugzilla bug 655601. I have to stress that the found bug does _not_ explain the original report of https://bugzilla.gnome.org/show_bug.cgi?id=655601 (which is what i call the 50 % bug). you seem right. The log shows some Growisofs message and not the one I have. Although, could it be that it is dependent on the libburn version? Since when does libburn return if all data was written or not? To be sure and keep a little sanity I created a new report upstream [2]. I would explain several of the follow-up comments in this bug report. Especially it would explain http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617409 I am not so sure on this one anymore as it is reported against 2.30.3-2 which does not have the offending patch. I can imaging that it is caused by the problem the faulty patch wanted to fix [1]. But thinking about this the original reporter wrote, that his medium could be mounted. Of course I meant GNOME BTS issue #630651. Thanks, Paul [1] https://bugzilla.gnome.org/show_bug.cgi?id=655601 [2] https://bugzilla.gnome.org/show_bug.cgi?id=685983 [3] https://bugzilla.gnome.org/show_bug.cgi?id=630651 signature.asc Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Dear Thomas, Am Donnerstag, den 11.10.2012, 16:59 +0200 schrieb Thomas Schmitt: 000 001 C D 0 0 1 001 \0 Yes. That is the start of a Primary Volume Descriptor block. Please mount the medium and use diff to compare the files in the image with their originals on hard disk. Just to be sure. (Mounting does not check all blocks in the image for sanity.) `diff folder/ /mnt/folder` does not return any error the burning worked. Hmm, it encodes the name in there. To all whistle blowers out there: Do not use Brasero without configuring beforehand. ;-) (Who told your computer your full name on the first hand ?) ECMA-119 says about that field in the PVD: 8.4.21 Data Preparer Identifier (BP 447 to 574) This field shall specify an identification of the person or other entity which controls the preparation of the data to be recorded on the Volume Group of which the volume is a member. I would rather use it to identify the image generating program. (I do so in xorriso. E.g.: XORRISO-1.2.5 2012.09.15.170346, LIBISOBURN-1.2.5, LIBISOFS-1.2.5, LIBBURN-1.2.5 ) Another bug found. :/ Brasero mentions itself as: 8.4.20 Publisher Identifier (BP 319 to 446) This field shall specify an identification of the user who specified what shall be recorded on the Volume Group of which the volume is a member. I would deem this field more appropriate to rat out Paul Menzel. :)) Very much more appropriate. ;-) Are you doing that in xorriso? mkisofs has a third opinion on that. It advertises itself in: 8.4.22 Application Identifier (BP 575 to 702) This field shall specify an identification of the specification of how the data are recorded on the Volume Group of which the volume is a member. Interesting. Though I know of no such specifications. PS: Thomas, reading the libburnia start page [1], I see you take donations. If some users, benefiting from this patch want to donate something, I would like the libburnia project to have it. So it would be great if you could give me the necessary instructions. If you would like to donate, please mail us: mario.danic [at] gmail [dot] com, Cc: scdbackup [at] gmx [dot] net. I personally can accept donations only by my german bank account. Possibly this is feasible within the EU even with smaller amounts. Our project founder Mario Danic has a paypal account, afaik. I understand he has to pay money for the web hoster. I see. Though I guess it should be made easy for people to donate. Entering an amount and clicking a button would be the best. Though I will tell them to mail you. (They could also sent you some stuff which they can pay easily in an online shop.) Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
Hi, The log shows some Growisofs message and not the one I have. Although, could it be that it is dependent on the libburn version? The libburn plugin was not used. Only the libisofs one. A run with growisofs as burn engine would also suffer from the bug we found in the libisofs plugin. But the found bug would not cause libisofs or growisofs to abort after libisofs generated about 50 percent of the image. GNOME bug 655061 is the same initial bug report as Ubuntu 780117. Both took a long tail of me-toos which mostly match our found bug. There we find the hints about direct burning (which fails) and burning of previously stored ISO images (which succeeds). Since when does libburn return if all data was written or not? Quite some while. But it depends on whether the size of the track was announced by the application. I understand Brasero creates its own struct burn_source implementation. So it depends on whether burn-libburn.c:brasero_libburn_src_get_size() returns non-zero. Whether this changed in the past is a matter of Brasero history. It might have been a libburn provided burn_source object in the past which would have been created by libburn call struct burn_source *burn_fd_source_new(int datafd, int subfd, off_t size); Here it would matter whether size is non-zero, resp. on the result of fstat(datafd, ...). I am not so sure on this one anymore as it is reported against 2.30.3-2 which does not have the offending patch. I can imaging that it is caused by the problem the faulty patch wanted to fix [1]. But thinking about this the original reporter wrote, that his medium could be mounted. I see. But the follow-up by Simon Wenner was with a higher Brasero version. I would deem this field more appropriate to rat out Paul Menzel. :)) Very much more appropriate. ;-) Are you doing that in xorriso? I do not even know how to get your full name from your computer. You would have to rat out yourself by xorriso command -publisher 'Paul Menzel' Interesting. Though I know of no such specifications. ECMA-119 is the freely available form of ISO 9660 specs. http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf The contract between image producers and image readers. It describes on byte level how an ISO image has to look like. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Dear Thomas, Am Sonntag, den 23.09.2012, 16:40 +0200 schrieb Paul Menzel: Am Sonntag, den 23.09.2012, 13:03 +0200 schrieb Thomas Schmitt: […] Another way to exercise DVD-R is to use DVD-RW. They need to get blanked before re-use. E.g. by xorriso -outdev /dev/sr1 -blank deformat -eject all This lasts as long as writing the full capacity of 4.7 GB. (Fast blanking is possible but the DVD-RW would afterwards refuse to perform the write type Incremental which is used by Brasero.) Some numbers from your reports are against my theory of a missing start piece: libisofs reported: brasero (libisofs)DEBUG : Processed 2119108 of 2119108 KB (100 %) dvd+rw-mediainfo and xorriso -toc report a track size of 1059568*2KB The overall sizeis of image and track would match. 2 * 1059568 - 2119108 = 28 The track size is aligned to a DVD ECC block of 32 KiB. The track was written by write type Incremental. I.e. it is supposed to bear only the bytes which were actually written, rounded up to the next multiple of 16 blocks (= 32 KiB). If a start piece of the image would be missing, then the track would have to be shorter. Gr. That really is strange. […] Everything worked fine with `xorriso`. $ xorriso -md5 on -outdev /dev/sr1 -map ~/test / Well ... Yay and G at the same time. Yay for xorriso and the drive, Grrr for my inability to explain what went wrong with the Brsaero DVD-R. Grrr³ from my side to not understanding anything. ;-) Thanks to Michael Biebl stepping up and looking into it, in #debian-gnome he wrote to have bisected this issue to commit upstream commit 5ff86b48 [1] which supposedly fixes GNOME bug 630651 [2]. Though, judging from this, it looks like the ISO image creation problem then. As this is done on the fly the created ISO image cannot be checked, right? He uploaded packages for testing with one more patch applied [3][4]. I am going to try those as soon as possible. Thanks, Paul [1] http://git.gnome.org/browse/brasero/commit/?id=5ff86b48 [2] https://bugzilla.gnome.org/show_bug.cgi?id=630651 [3] http://people.debian.org/~biebl/brasero/amd64/ [4] http://people.debian.org/~biebl/brasero/i386/ signature.asc Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails
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
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688229: Burning data DVD looks successful but mounting fails
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
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Dear Thomas, thank you again for your fast reply. Could you please CC me, since I am not subscribed and need to import your message from the BTS every time. Am Samstag, den 22.09.2012, 12:04 +0200 schrieb Thomas Schmitt: Paul Menzel wrote: $ dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c ... 000 \0 0 034 001 \0 \0 001 034 0 F 034 + \0 \0 + 020 034 F p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 040 034 \0 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 060 8 \0 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 100 224 ! 001 \0 \0 001 ! 224 @ 276 + \0 \0 + 276 @ 120 p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 140 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 9 \0 160 . \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.) Nice find! 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. Is there some way to simulate a burner to find out what happened? […] $ dvd+rw-mediainfo /dev/sr1 The output looks totally normal. Medium is ok. I think I forgot to add that the burner and the same DVD medium were used successfully with for example K3b and I also think xorriso. We have no special indication of any malfunction of burner or medium. There are just not the right bytes stored at the right block addresses. A further test with xorriso would be welcome. Just to be sure. Everything worked fine with `xorriso`. $ xorriso -md5 on -outdev /dev/sr1 -map ~/test / xorriso 1.2.2 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev '/dev/sr1' Media current: DVD-R sequential recording Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 4489m free xorriso : UPDATE : 123 files added in 1 seconds Added to ISO image: directory '/'='/home/joe/test' xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s0.0% fifo 100% buf 0% 0.0xD xorriso : UPDATE : Writing: 16s
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Hi, Could you please CC me I will try to remember. :) But maybe you better subscribe by a mail to 688229-subscr...@bugs.debian.org Is there some way to simulate a burner to find out what happened? libburn would accept burner addresses like stdio:/tmp/my_emulated_drive which would behave like DVD-RAM or DVD+RW. I.e. quite different from DVD-R or DVD+R. Nevertheless such an emulated drive would allow to exercise the communications between libisofs and libburn, as done by Brasero. I do not know how to make Brasero use such a drive address. Probably one would have to hack its source. Another way to exercise DVD-R is to use DVD-RW. They need to get blanked before re-use. E.g. by xorriso -outdev /dev/sr1 -blank deformat -eject all This lasts as long as writing the full capacity of 4.7 GB. (Fast blanking is possible but the DVD-RW would afterwards refuse to perform the write type Incremental which is used by Brasero.) Some numbers from your reports are against my theory of a missing start piece: libisofs reported: brasero (libisofs)DEBUG : Processed 2119108 of 2119108 KB (100 %) dvd+rw-mediainfo and xorriso -toc report a track size of 1059568*2KB The overall sizeis of image and track would match. 2 * 1059568 - 2119108 = 28 The track size is aligned to a DVD ECC block of 32 KiB. The track was written by write type Incremental. I.e. it is supposed to bear only the bytes which were actually written, rounded up to the next multiple of 16 blocks (= 32 KiB). If a start piece of the image would be missing, then the track would have to be shorter. Gr. I assume you too live in Germany. If so: Would the images on the DVD be non-private enough and would you want to invest 1.45 Euro into a mail stamp in order to send me that DVD-R for closer inspection ? Or do you have 2 GB of internet storage from where i could download a copy of the medium made by dd if=/dev/sr1 bs=2048 of=/tmp/copy_of_dev_sr1 ? Everything worked fine with `xorriso`. $ xorriso -md5 on -outdev /dev/sr1 -map ~/test / Well ... Yay and G at the same time. Yay for xorriso and the drive, Grrr for my inability to explain what went wrong with the Brsaero DVD-R. The only thing I noticed, that another DVD drive, the Toshiba DVD-ROM SD-M1712, needed more than 25 seconds to recognize the disc. This might be due to the fact that the medium is still appendable, unlike the one from Brasero. I.e. you could add more files by xorriso or growisofs. How is recognition time with the burner ? In order to get a closed DVD-R, you would have to use command -close on E.g. with the now appendable DVD-R medium $ mkdir ~/test2 $ cp ...a...few...files... ~/test2 $ xorriso -md5 on -dev /dev/sr1 -map ~/test2 /test2 -close on (Note that this run uses command -dev rather than -outdev in order to load the existing directory tree of the image and to merge it with the newly added file tree.) Maybe it will then be recognized faster by the DVD-ROM. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Dear Thomas, Am Sonntag, den 23.09.2012, 13:03 +0200 schrieb Thomas Schmitt: Could you please CC me I will try to remember. :) But maybe you better subscribe by a mail to 688229-subscr...@bugs.debian.org I would like to avoid that, because it also requires confirmation and I think »Reply to all« is easier. But I will do so next time, it happens. Is there some way to simulate a burner to find out what happened? libburn would accept burner addresses like stdio:/tmp/my_emulated_drive which would behave like DVD-RAM or DVD+RW. I.e. quite different from DVD-R or DVD+R. Nevertheless such an emulated drive would allow to exercise the communications between libisofs and libburn, as done by Brasero. I do not know how to make Brasero use such a drive address. Probably one would have to hack its source. I will take a look. Another way to exercise DVD-R is to use DVD-RW. They need to get blanked before re-use. E.g. by xorriso -outdev /dev/sr1 -blank deformat -eject all This lasts as long as writing the full capacity of 4.7 GB. (Fast blanking is possible but the DVD-RW would afterwards refuse to perform the write type Incremental which is used by Brasero.) Some numbers from your reports are against my theory of a missing start piece: libisofs reported: brasero (libisofs)DEBUG : Processed 2119108 of 2119108 KB (100 %) dvd+rw-mediainfo and xorriso -toc report a track size of 1059568*2KB The overall sizeis of image and track would match. 2 * 1059568 - 2119108 = 28 The track size is aligned to a DVD ECC block of 32 KiB. The track was written by write type Incremental. I.e. it is supposed to bear only the bytes which were actually written, rounded up to the next multiple of 16 blocks (= 32 KiB). If a start piece of the image would be missing, then the track would have to be shorter. Gr. That really is strange. I assume you too live in Germany. If so: Would the images on the DVD be non-private enough and would you want to invest 1.45 Euro into a mail stamp in order to send me that DVD-R for closer inspection ? Or do you have 2 GB of internet storage from where i could download a copy of the medium made by dd if=/dev/sr1 bs=2048 of=/tmp/copy_of_dev_sr1 ? I will try to and will contact you again next week. Everything worked fine with `xorriso`. $ xorriso -md5 on -outdev /dev/sr1 -map ~/test / Well ... Yay and G at the same time. Yay for xorriso and the drive, Grrr for my inability to explain what went wrong with the Brsaero DVD-R. Grrr³ from my side to not understanding anything. ;-) The only thing I noticed, that another DVD drive, the Toshiba DVD-ROM SD-M1712, needed more than 25 seconds to recognize the disc. This might be due to the fact that the medium is still appendable, unlike the one from Brasero. I.e. you could add more files by xorriso or growisofs. How is recognition time with the burner ? In order to get a closed DVD-R, you would have to use command -close on E.g. with the now appendable DVD-R medium $ mkdir ~/test2 $ cp ...a...few...files... ~/test2 $ xorriso -md5 on -dev /dev/sr1 -map ~/test2 /test2 -close on (Note that this run uses command -dev rather than -outdev in order to load the existing directory tree of the image and to merge it with the newly added file tree.) Maybe it will then be recognized faster by the DVD-ROM. Thank you for the detailed explanation. I already gave the DVD away. Maybe I have a chance to look into it again. Thanks, Paul signature.asc Description: This is a digitally signed message part
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Dear Thomas, I am sorry for my late reply. Also I am CCing just to be sure. If you get the message twice because you subscribed to the report, please tell me. Am Donnerstag, den 20.09.2012, 22:51 +0200 schrieb Thomas Schmitt: brasero (libisofs)DEBUG : Processed 2119108 of 2119108 KB (100 %) It went well, at least as far as libisofs was involved. So this is not the problem with premature end after 50 %. And it is not the riddling CD problem, where Brasero CDs are unreadable, whereas xorriso burned CDs are ok. Great! BraseroLibburn Async SYNCHRONIZE CACHE succeeded after 0.8 seconds ... BraseroLibburn Closing track 01 (absolute track number 1) BraseroLibburn Async CLOSE TRACK SESSION succeeded after 0.4 seconds BraseroLibburn Closing session BraseroLibburn Async CLOSE TRACK SESSION succeeded after 5.3 seconds These messages stem from libburn. They indicate that it saw no severe error message from the drive and that it finished the burn run. I cannot tell, though, how many data were passed through libburn. [ 9103.816252] ISOFS: Unable to identify CD-ROM format. What do you get from dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c With a valid ISO image, the output should begin by 000 001 C D 0 0 1 and consist of up to 128 lines of text. $ dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c 1+0 Datensätze ein 1+0 Datensätze aus 2048 Bytes (2,0 kB) kopiert, 0,00199071 s, 1,0 MB/s 000 \0 0 034 001 \0 \0 001 034 0 F 034 + \0 \0 + 020 034 F p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 040 034 \0 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 060 8 \0 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 100 224 ! 001 \0 \0 001 ! 224 @ 276 + \0 \0 + 276 @ 120 p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 140 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 9 \0 160 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 \f ' 200 001 \0 \0 001 ' \f u S - \0 \0 - S u p \t 220 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 I \0 240 M \0 G \0 _ \0 2 \0 4 \0 3 \0 0 \0 . \0 260 J \0 P \0 G \0 ; \0 1 \0 \0 267 , 001 \0 300 \0 001 , 267 016 y 037 \0 \0 037 y 016 p \t 023 022 320 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 I \0 M \0 340 G \0 _ \0 2 \0 4 \0 3 \0 2 \0 . \0 J \0 360 P \0 G \0 ; \0 1 \0 \0 247 0 001 \0 \0 001 400 0 247 340 I \0 \0 I 340 p \t 023 022 1 ! 420 \0 \0 \0 \0 001 \0 \0 001 034 \0 I \0 M \0 G \0 440 _ \0 2 \0 4 \0 3 \0 3 \0 . \0 J \0 P \0 460 G \0 ; \0 1 \0 \0 361 4 001 \0 \0 001 4 361 500 005 G \0 \0 G 005 p \t 023 022 1 ! \0 \0 520 \0 \0 001 \0 \0 001 034 \0 I \0 M \0 G \0 _ \0 540 2 \0 4 \0 3 \0 4 \0 . \0 J \0 P \0 G \0 560 ; \0 1 \0 \0 372 8 001 \0 \0 001 8 372 252 020 600 ! \0 \0 ! 020 252 p \t 023 022 1 ! \0 \0 \0 \0 620 001 \0 \0 001 034 \0 I \0 M \0 G \0 _ \0 2 \0 640 4 \0 3 \0 5 \0 . \0 J \0 P \0 G \0 ; \0 660 1 \0 \0 035 = 001 \0 \0 001 = 035 252 261 035 \0 700 \0 035 261 252 p \t 023 022 1 ! \0 \0 \0 \0 001 \0 720 \0 001 034 \0 I \0 M \0 G \0 _ \0 2 \0 4 \0 740 3 \0 7 \0 . \0 J \0 P \0 G \0 ; \0 1 \0 760 \0 324 @ 001 \0 \0 001 @ 324 ; 206 % \0 \0 % 0001000 206 ; p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 0001020 034 \0 I \0 M \0 G \0 _ \0 2 \0 4 \0 3 \0 0001040 8 \0 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 0001060 205 E 001 \0 \0 001 E 205 M 255 \0 \0255 M 0001100 p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 0001120 I \0 M \0 G \0 _ \0 2 \0 4 \0 3 \0 9 \0 0001140 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 [ J 0001160 001 \0 \0 001 J [ 250 P \0 \0 P 250 p \t 0001200 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 I \0 0001220 M \0 G \0 _ \0 2 \0 4 \0 4 \0 0 \0 . \0 0001240 J \0 P \0 G \0 ; \0 1 \0 \0 246 N 001 \0 0001260 \0 001 N 246 q K \0 \0 K q p \t 023 022 0001300 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 I \0 M \0 0001320 G \0 _ \0 2 \0 4 \0 4 \0 1 \0 . \0 J \0 0001340 P \0 G \0 ; \0 1 \0 \0 p S 001 \0 \0 001 0001360 S p 340 034 $ \0 \0 $ 034 340 p \t 023 022 1 ! 0001400 \0 \0 \0 \0 001 \0 \0 001 034 \0 I \0 M \0 G \0 0001420
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Hi, Paul Menzel wrote: $ dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c ... 000 \0 0 034 001 \0 \0 001 034 0 F 034 + \0 \0 + 020 034 F p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 040 034 \0 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 060 8 \0 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 100 224 ! 001 \0 \0 001 ! 224 @ 276 + \0 \0 + 276 @ 120 p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 140 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 9 \0 160 . \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. PS: Is there any way to rescue the broken media, that means to correctly finish the burning process? The medium is irreversibly closed. The problem seems to be in lost data blocks. (One could try to retrieve the JPEGs. If the loss is only about data at the image start, then it should be possible to guess names from the remaining part of the Joliet tree.) $ dvd+rw-mediainfo /dev/sr1 The output looks totally normal. Medium is ok. I think I forgot to add that the burner and the same DVD medium were used successfully with for example K3b and I also think xorriso. We have no special indication of any malfunction of burner or medium. There are just not the right bytes stored at the right block addresses. A further test with xorriso would be welcome. Just to be sure. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Hi, brasero (libisofs)DEBUG : Processed 2119108 of 2119108 KB (100 %) It went well, at least as far as libisofs was involved. So this is not the problem with premature end after 50 %. And it is not the riddling CD problem, where Brasero CDs are unreadable, whereas xorriso burned CDs are ok. BraseroLibburn Async SYNCHRONIZE CACHE succeeded after 0.8 seconds ... BraseroLibburn Closing track 01 (absolute track number 1) BraseroLibburn Async CLOSE TRACK SESSION succeeded after 0.4 seconds BraseroLibburn Closing session BraseroLibburn Async CLOSE TRACK SESSION succeeded after 5.3 seconds These messages stem from libburn. They indicate that it saw no severe error message from the drive and that it finished the burn run. I cannot tell, though, how many data were passed through libburn. [ 9103.816252] ISOFS: Unable to identify CD-ROM format. What do you get from dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c With a valid ISO image, the output should begin by 000 001 C D 0 0 1 and consist of up to 128 lines of text. What do you get from dvd+rw-mediainfo /dev/sr1 (Have medium and tray already loaded. It will not pull in the tray.) $ xorriso -outdev /dev/sr1 -check_media what=disc use=outdev ... Media current: DVD-ROM Media status : is written , is closed A Media summary: 1 session, 1059568 data blocks, 2069m data, 0 free ... xorriso : UPDATE : 1059568 of 1059568 blocks read in 265 s = 5.9xD Media checks :lba , size , quality Media region : 0 ,192 , + good Media region :192 , 16 , + slow Media region :208 ,1059360 , + good This xorriso command did not judge whether the medium bears an ISO 9660 filesystem. It only inspected the medium state. The medium is reported by the drive as DVD-ROM, which is permissible if it is closed. (Is it a DVD-R ?) Further the drive did not report any errors when reading the data blocks. The average reading speed of 5.9x is not overly high but does not yet indicate a large number of re-tries. No long pauses were perceived while reading, except the small speed glitch at block 192 which is quite normal. The following xorriso run would tell more about the recognizability of ISO 9660 content on the medium: xorriso -outdev /dev/sr1 -toc This run would try to load the directory tree of the ISO image and issue error messages if there is no proper ISO 9660 on the medium: xorriso -indev /dev/sr1 It has to be feared that it will bail out similarly to the mount attempts. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
