Bug 1327815

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.