Hide Forgot
This bug is against util-linux-2.28-1.fc23.x86_64 . I have several hybrid data/audio CDROMs. blkid is unable to detect a filesystem on any of them, even though they all have a valid ISO9660 filesystem in track 1. If I restrict blkid to iso9660 only, it works fine: # blkid -n iso9660 -p /dev/sr0; echo $? /dev/sr0: SYSTEM_ID="AL-MPS3" PUBLISHER_ID="MicroProse" APPLICATION_ID="1.0" UUID="1999-05-11-22-24-18-00" VERSION="Joliet Extension" LABEL="MW3" TYPE="iso9660" USAGE="filesystem" 0 If I don't add that restriction, however, it fails: # blkid -p /dev/sr0; echo $? 2 udev doesn't end up getting a value for ID_FS_TYPE, so my desktop environment doesn't think the disk contains any usable filesystem. With debugging enabled, I can see libblkid hitting an EIO error in the zfs_member superblock probe function: 15717: libblkid: LOWPROBE: ready for low-probing, offset=0, size=651919360 ... 15717: libblkid: LOWPROBE: [37] zfs_member: 15717: libblkid: LOWPROBE: call probefunc() 15717: libblkid: LOWPROBE: read 0x7fac0da26038: off=0 len=262144 15717: libblkid: LOWPROBE: read 0x7fac0d9e5038: off=262144 len=262144 15717: libblkid: LOWPROBE: read 0x7fac0d9a4038: off=651165696 len=262144 15717: libblkid: LOWPROBE: read failed: Input/output error 15717: libblkid: LOWPROBE: <-- leaving probing loop (failed=-5) [SUBLKS idx=37] This seems to be because that libblkid is trusting the size returned by the BLKGETSIZE64 ioctl: # blockdev --getsize64 /dev/sr0 651919360 even though the filesystem size is somewhat shorter: # isosize /dev/sr0 545060864 (The data track is likely to be a few sectors longer than this -- I'm not entirely sure how to get its size.) BLKGETSIZE64 appears to report the size of the the entire disk including all of the audio tracks. I'm not sure what the most robust way of working around this might be -- perhaps libblkid could read the CD table of contents and ensure that it only does reads within the data track?
Yes, this is well known problem. It seems that the right way is to try read the end of the device (before probing) and on I/O errors reduce size of the device. I'll try to fix it in the next upstream update.
Hi Karel, I just saw your commit at: https://github.com/karelzak/util-linux/commit/bfebe74e3babe8c188a51269acc2673f1aea283f I don't think this will be sufficient in all cases. That might work for a data-only CDROM, but with a data+audio hybrid CD the data size can be *a lot* less than the physical size reported by BLKGETSIZE64. With the CD I used in my example earlier: # blockdev --getsize64 /dev/sr0 603740160 # isosize /dev/sr0 545060864 # dd if=/dev/sr0 of=/dev/null bs=512 count=1 skip=545369600 iflag=skip_bytes status=none # dd if=/dev/sr0 of=/dev/null bs=512 count=1 skip=$((545369600 + 512)) iflag=skip_bytes status=none dd: error reading ‘/dev/sr0’: Input/output error So the usable size here is some 114004 512-byte sectors less than the size reported by BLKGETSIZE64.
Hmm.. I thought that unreadable sectors are only about CD devices than about medium format. From your example (thanks!) it seems that we need to make all I/O errors on CDROMs non-fatal -- it means continue with probing although I/O error detected in the probing area.
Now I re-read your comment #0... ... udev uses /usr/lib/udev/cdrom_id to get details about the CD medium. It also returns ID_CDROM_MEDIA_SESSION_LAST_OFFSET and this offset is used for blkid (if data tracks are detected). For more details see: /usr/lib/udev/rules.d/60-persistent-storage.rules It means udev should be smart enough to bypass the problem you described in comment #2. Anyway, you're probably still affected by the problem with unreadable the end of CD-ROM (as I have talked about in comment #1). Please, try git clone https://github.com/karelzak/util-linux cd util-linux ./autogen.sh ./configure make blkid # ./blkid -p -O $(/usr/lib/udev/cdrom_id /dev/sr0 | awk -F '=' '/ID_CDROM_MEDIA_SESSION_LAST_OFFSET/ { print $2 }') /dev/sr0 Note that I'll probably also improve blkid to get last CD session offset to be usable on command line without -O <offset>.
The particular CDROM I'm testing with has one session, so cdrom_id isn't returning a value for ID_CDROM_MEDIA_SESSION_LAST_OFFSET: # SYSTEMD_LOG_LEVEL=debug /usr/lib/udev/cdrom_id /dev/sr0 ... READ TOC: len: 36, start track: 1, end track: 3 track=1 info=0x4(data) start_block=0 track=2 info=0x0(audio) start_block=266445 track=3 info=0x0(audio) start_block=280839 last track 1 starts at block 0 disk type 00 hardware reported media status: complete ID_CDROM=1 ID_CDROM_CD=1 ID_CDROM_CD_R=1 ID_CDROM_CD_RW=1 ID_CDROM_DVD=1 ID_CDROM_DVD_R=1 ID_CDROM_DVD_RW=1 ID_CDROM_DVD_RAM=1 ID_CDROM_DVD_PLUS_R=1 ID_CDROM_DVD_PLUS_RW=1 ID_CDROM_DVD_PLUS_R_DL=1 ID_CDROM_MRW=1 ID_CDROM_MRW_W=1 ID_CDROM_MEDIA=1 ID_CDROM_MEDIA_CD=1 ID_CDROM_MEDIA_SESSION_COUNT=1 ID_CDROM_MEDIA_TRACK_COUNT=3 ID_CDROM_MEDIA_TRACK_COUNT_AUDIO=2 ID_CDROM_MEDIA_TRACK_COUNT_DATA=1 To be honest, I don't think the session offset alone is sufficient. As far as I know there is no actual requirement that the data track in a hybrid data/audio CD be the *first* track. I've never seen it done any other way though. At any rate, blkid will need to get the data track's length from somewhere, so it does seem as if it will need to read the TOC on its own.
I see, the problem is that we need to ask CD for the track size too. OK :-)
BTW, I have CD where data are on last track: READ TOC: len: 116, start track: 1, end track: 13 track=1 info=0x0(audio) start_block=0 track=2 info=0x0(audio) start_block=13338 track=3 info=0x0(audio) start_block=32148 track=4 info=0x0(audio) start_block=79223 track=5 info=0x0(audio) start_block=99120 track=6 info=0x0(audio) start_block=149535 track=7 info=0x0(audio) start_block=168533 track=8 info=0x0(audio) start_block=177160 track=9 info=0x0(audio) start_block=196610 track=10 info=0x0(audio) start_block=209000 track=11 info=0x0(audio) start_block=221350 track=12 info=0x0(audio) start_block=230756 track=13 info=0x4(data) start_block=294840 last track 13 starts at block 294840 disk type 00 hardware reported media status: complete ID_CDROM=1 ID_CDROM_CD=1 ID_CDROM_CD_R=1 ID_CDROM_CD_RW=1 ID_CDROM_DVD=1 ID_CDROM_DVD_R=1 ID_CDROM_DVD_RW=1 ID_CDROM_DVD_RAM=1 ID_CDROM_DVD_PLUS_R=1 ID_CDROM_DVD_PLUS_RW=1 ID_CDROM_DVD_PLUS_R_DL=1 ID_CDROM_DVD_PLUS_RW_DL=1 ID_CDROM_MEDIA=1 ID_CDROM_MEDIA_CD=1 ID_CDROM_MEDIA_SESSION_COUNT=2 ID_CDROM_MEDIA_SESSION_LAST_OFFSET=603832320 ID_CDROM_MEDIA_TRACK_COUNT=13 ID_CDROM_MEDIA_TRACK_COUNT_AUDIO=12 ID_CDROM_MEDIA_TRACK_COUNT_DATA=1 this works with the current libblkid from git tree. I need another CD to test data track on another positions...
(In reply to Karel Zak from comment #7) > this works with the current libblkid from git tree. Yeah, but only because it's the first track in the second session on that CD, so the ID_CDROM_MEDIA_SESSION_LAST_OFFSET happens to point to it. I was thinking it may be possible in some cases for the first track in the last session to not be a data track, i.e. for the data track to come after audio tracks within that last session. ECMA-130 implies that it's possible (see http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-130.pdf, §20.2).
The current upstream fixes the reported issue, but the solution is not 100% for all possible hybrid CDROM. I have another patch to analyse TOC https://github.com/karelzak/util-linux/commit/dab4fc3fb7cf2fec7e91def71449ae18005cf2e4 but still not sure if we really need it :-)
Note that f23 and f24 have been updated be more smart with I/O errors on CDROMS, it fixes many issues on CDROMs/DVDs.
Hi Karel, I am facing the same issue. I took your above mentioned changes and applied onto 2.26.2 . I could see, problem got resolved, but I am getting other I/O error messages. root@mx6q:~# blkid -p -u noraid /dev/sr0 [ 286.713343] sr 1:0:0:0: [sr0] [ 286.713361] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 286.713377] sr 1:0:0:0: [sr0] [ 286.713389] Sense Key : Illegal Request [current] [ 286.713415] sr 1:0:0:0: [sr0] [ 286.713435] Add. Sense: Illegal mode for this track [ 286.713454] sr 1:0:0:0: [sr0] CDB: [ 286.713465] Read(10): 28 00 00 00 9b 34 00 00 01 00 00 00 [ 286.713559] end_request: I/O error, dev sr0, sector 158928 [ 286.714841] sr 1:0:0:0: [sr0] [ 286.714859] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 286.714874] sr 1:0:0:0: [sr0] [ 286.714886] Sense Key : Illegal Request [current] [ 286.714912] sr 1:0:0:0: [sr0] [ 286.714932] Add. Sense: Illegal mode for this track [ 286.714951] sr 1:0:0:0: [sr0] CDB: [ 286.714962] Read(10): 28 00 00 00 9b 35 00 00 01 00 00 00 [ 286.715055] end_request: I/O error, dev sr0, sector 158932 /dev/sr0: APPLICATION_ID="NERO BURNING ROM VER 17,0,8,0" UUID="2016-07-13-15-14-00-00" VERSION="Joliet Extension" LABEL="Mix_Mode_Mode_1" TYPE="iso9660" USAGE="filesystem" root@mx6q:~# Would you please help, to get rid of these I/O error messages ? Regards, Mounesh
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.