[Debburn-devel] CD-Extra issues

Wed Dec 3 22:25:45 UTC 2014

On Wed, Dec 03, 2014 at 09:59:42PM +0100, Thomas Schmitt wrote:

> >  Knowing that the audio tracks are not readiable I was somehow assuming
> > the audio tracks to be ignored
> 
> Not knowing exactly what the driver does, i assume it
> issues an SCSI command READ(10) and gets an error like
>   5 64 00 ILLEGAL MODE FOR THIS TRACK
> 
> 
> > Mounting still doesn't work.  The mount man page documents the block size
> > to default to 1024 so I tried to add block=2048.
> 
> The default block size for sbsector= is supposed to be 2048,
> because it is an option of filesystem type "iso9660" and
> to be applied before the Primary Volume Descriptor of the
> filesystem can tell an non-standard block size.
> 
> 
> >   mount -t iso9660 -o session=17 /dev/sr0 /mnt
> > yields:
> > [238634.103799] ISOFS: Session 18 start 291114 type 4
> 
> We got the right block address here. "type" might refer to
> the control nibble of the track: 0=audio, 4=data.
> It seems that session= actually addresses tracks and not sessions.
> Further it seems to start counting by 0, which is unusual with
> MMC sessions (or tracks).
> 
> > [238413.898930] ISO 9660 Extensions: Microsoft Joliet Level 3
> 
> It sees the Volume Descriptor which indicates Joliet.
> We are at or very near to the right read position.
> 
> > [238413.898940] ISOFS: Interleaved files not (yet) supported.
> > [238413.898942] ISOFS: File unit size != 0 for ISO file (18642688).
> > [238413.898947] ISOFS: changing to secondary root
> 
> And tries to use it after inspection of the Primary Volume
> Descriptor and/or the ISO 9660 root directory yielded bad vaues.
> 
> 
> > http://ubuntuforums.org/archive/index.php/t-1088919.html
> >> Mar 6 13:28:25 ubuntu-desktop kernel: [51021.405047] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current] 
> 
> This is something different: A problem between drive and medium.
> 
> 
> > Time to dive into the kernel code?
> 
> Try the following to make sure it really is the fault of mount
> operating on a real CD drive:
> 
>   # Create a pedestal of 291114 blocks of 2048 bytes
>   dd if=/dev/zero bs=2048 count=291114 of=iso_mockup.iso
> 
>   # Append the ISO session from CD
>   dd if=/dev/sr0 bs=2048 skip=291114 count=$((89114624/2048)) >>iso_mockup.iso

# dd if=/dev/sr0 bs=2048 skip=291114 seek=291114 count=$((89114624/2048)) of=iso_mockup.iso
43513+0 records in
43513+0 records out
89114624 bytes (89 MB) copied, 60.4234 s, 1.5 MB/s
[root at h7 tmp]#

>   # (As superuser) mount the copied ISO session
>   mount -t iso9660 -o loop,sbsector=291114 iso_mockup.iso /mnt/iso

Fails.  Dmesg as before:

[251014.359714] ISO 9660 Extensions: Microsoft Joliet Level 3
[251014.359741] ISOFS: Interleaved files not (yet) supported.
[251014.359743] ISOFS: File unit size != 0 for ISO file (18642688).
[251014.359746] ISOFS: changing to secondary root
[251014.359757] ISOFS: Interleaved files not (yet) supported.
[251014.359759] ISOFS: File unit size != 0 for ISO file (18642816).
[251014.359760] isofs_fill_super: root inode is not a directory. Corrupted media?

> If this works properly, then the next step is to find out
> what might cause the two complaints with the CD.
> I see in my very old kernel source fs/isofs/inode.c 

2.6.22 or older :)

>         struct iso_directory_record * de;
>         ...
>         if (de->interleave[0]) {
>                 printk("Interleaved files not (yet) supported.\n");
>         ...
>         if (de->file_unit_size[0] != 0) {
>                 printk("File unit size != 0 for ISO file (%ld).\n",
>                        inode->i_ino);
> 
> File include/linux/iso_fs.h declares struct iso_directory_record
> as an analogon oc ECMA-119, 9.1 "Format of a Directory Record".
>   struct iso_directory_record {
>         ...
>         char file_unit_size             [ISODCL (27, 27)]; /* 711 */
>         char interleave                 [ISODCL (28, 28)]; /* 711 */
>         ...
> about which ECMA-119 says:
>   "9.1.7 File Unit Size (BP 27)
>    This field shall contain an 8-bit number. This number shall specify
>    the assigned File Unit size for the File Section if the File Section
>    is recorded in interleaved mode. Otherwise this number shall be zero.
>    This field shall be recorded according to 7.1.1.
>    9.1.8 Interleave Gap Size (BP 28)
>    This field shall contain an 8-bit number. This number shall specify
>    the assigned Interleave Gap size for the File Section if the File
>    Section is recorded in interleaved mode. Otherwise this number shall
>    be zero.
>    This field shall be recorded according to 7.1.1."
> 
> "File Section" essentially means file data content.
> "File Unit" is a chunk size with an obscure feature "Interleaved Mode"
> of ECMA-119, 6.4.3.
> Both unsigned 8-bit numbers are supposed to be 0.
> Your kernel sees non-zero values, obviously.
> 
> The number given in the complaint
> > [238413.898942] ISOFS: File unit size != 0 for ISO file (18642688).
> is supposed to be the inode number, which is supposed to be
> the byte address of the directory record divided by 32.
> This means the directory record is located in block 291292,
> probably at its very beginning. (The block address is plausible.
> So Linux did not give up this inode numbering scheme up to now.)
> 
> What do you get from this ?
> 
>   dd if=/dev/sr0 bs=2048 skip=291292 | dd bs=286 count=1 | od -x
>   
> The record cannot be larger than 255 bytes and starts at latest
> at byte 31 of block 291292. Thus it must be within the first 286
> bytes.
> (od -x shows little-endian 16-bit integers. Better would be a
>  display of 8-bit values in hex.)

-x is -t x2 that is 16 bit values.  -t x1 gives a bytewise hexdump:

0000000 37 76 9a 9e 71 34 3e 02 39 22 19 83 76 b9 2d 94
0000020 8c d7 86 36 ad f8 7f b6 e5 62 bf bd 94 82 94 fa
0000040 63 f8 f2 6d aa ce ed 52 59 3a fb 83 c4 18 e6 5f
0000060 5b dc 28 1f 6b cd 5d ca 6b b2 ab 94 82 be 77 4c
0000100 90 71 6f a6 46 6c 64 f6 1e ac a0 d9 14 9d f5 4e
0000120 bf 6e 93 5f 6f d3 73 56 6f 4f 98 d5 ae fd ac 25
0000140 bd 9c f5 ae ce a3 ae 69 fe ed 2e 3a 9b 9d ed 9e
0000160 2e ef 8d 6f ce 47 cd c7 2b b8 97 74 c8 95 08 1c
0000200 0e a2 e4 6d 43 50 96 8e c0 da 02 90 66 84 10 4f
0000220 04 68 b5 80 51 8a 51 3f 14 25 cb e4 f2 58 91 b2
0000240 ea a6 bf 87 b7 7c 22 87 a0 2f 6d 3c a2 74 5c 08
0000260 60 a4 b2 62 9b 16 48 05 12 d2 1c 54 49 e3 1d 04
0000300 07 40 e2 53 3a 05 83 a1 84 54 b4 8b f7 61 9a 3c
0000320 9a 0b a0 80 df 57 d6 aa d5 78 98 e7 b2 50 41 1a
0000340 45 88 a9 2e 4c 58 36 8c 6b b0 bd 92 55 53 25 2d
0000360 01 95 9d 8d 54 9e 94 69 2f 9c 47 76 ce 36 9a 39
0000400 1d 82 f9 0b ff 3a 63 af a7 0c d0 2c 94 41 47 24
0000420 93 40 52 8c 21 a3 28 32 8a 82 e0 bb 1b 81
0000436

Looks to me like random byte soup.

  Ralf