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 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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
