Hi, i wrote: > > They saw a CD and tried UDF. Cluelessly and in vain.
Jonathan Dowland wrote: > They did that because of the fstab line which specified udf, and the > presence of a data track on the CD. The "problem CD" is pure audio. No indication on Table-Of-Content level that there would be sectors readable by READ(10). Whatever software tries to mount a filesystem there does not take into account the sector format of the tracks. > I've never seen the use of "iso9660,udf" in that column of fstab before. > (would "auto" do the same thing?) You learn something new every day! My Debian 8 fstab has such entries for sr0 and sr1, none for sr2 to sr4. Like: /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0 I have disabled automounting on my system. What i cannot stop is udev groping a newly inserted medium. Workaround is to wait until all drive blinking stops before using the medium for mounting or burning. I tried manual mounting as superuser with a commercial audio CD: # mount -t udf,iso9660 /dev/sr4 /mnt/iso mount: /dev/sr4 is write-protected, mounting read-only mount: /dev/sr4: can't read superblock dmesg reports afterwards [X.698578] sr 44:0:0:0: [sr4] [X.698580] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [X.698581] sr 44:0:0:0: [sr4] [X.698582] Sense Key : Illegal Request [current] [X.698584] sr 44:0:0:0: [sr4] [X.698586] Add. Sense: Illegal mode for this track [X.698587] sr 44:0:0:0: [sr4] CDB: [X.698588] Read(10): 28 00 00 00 00 10 00 00 01 00 [X.698591] end_request: I/O error, dev sr4, sector 64 This is a READ(10) attempt, which a system with a clue should not try on tracks with CONTROL value 0. I get a more standards compliant Sense Code from my ASUS BW-16D1HT burner than Martin McCormick got from his SONY CRX140E, which seems to be quite aged (CD only, IDE, reviews from year 2000, ...). Linux has clue of CD media by its ioctl() family CDROM_*, but obviously this does not fully shine through with filesystems, and probably even less with userland automounters. The mount attempts are not done with this first failure: ... [X.703472] UDF-fs: error (device sr4): udf_read_tagged: read failed, block=256, location=256 ... many more failed READ(10) and messages about UDF ... [X.771416] UDF-fs: warning (device sr4): udf_fill_super: No partition found (1) ... [X.783391] isofs_fill_super: bread failed, dev=sr4, iso_blknum=16, block=16 ... [X.807885] EXT4-fs (sr4): unable to read superblock ... 2 retries on same address ... [X.853593] FAT-fs (sr4): unable to read boot sector ... repeating the attempts for EXT4-fs and FAT-fs ... So it does not look like mount would take the -t list as a restriction for trying other filesystem formats. deloptes wrote: > > in any case no one can take the power of dd away :D Jonathan Dowland wrote: > Good luck reading audio track data from CD-ROMs with dd. Or subcode > information. Tip: you can't. Yep. dd uses POSIX functions like read(2), which in the end emit READ(10) commands to the drive. But as said, this generic SCSI read command works only with pure data storage devices or with data tracks on CD. DVD and BD offer no non-data tracks. So CD are the only media i know, which can offer non-data data. Reading the subchannel info of CDs is normally only of interest for cloning identical media or for circumventing weird read protection methods. Their normal job is to tell an audio player roughly the current read position, the Media Catalog Number, ISRC, CD-TEXT, ... For all drives it provides the track's CONTROL value, which tells parts of the sector format. Have a nice day :) Thomas