Looks like a mmc LUN exported like this tgtadm --lld iscsi --op new --mode logicalunit --tid 7 --lun 2 --backing-store some_iso_file.iso --device-type cd tgtadm --lld iscsi --op update --mode logicalunit --tid 7 --lun 2 --params vendor_id="DAVIDZ",product_id="DVDROM",product_rev=0010,scsi_sn=24601,removable=1 tgtadm --lld iscsi --op bind --mode target --tid 7 -I ALL doesn't work correctly... basically /lib/udev/cdrom_id (see [1]) is sending a READ TOC command which fails. Because of this, we don't run blkid(8) on the device and as a result the rest of the OS (in particular the desktop) doesn't know about the device. Note that in earlier udev/cdrom_id versions we always probed the optical drive for media.. but since people complained about errors in the kernel log for e.g. audio or blank discs we started only probing discs when certain there was a data track. And to determine if there's a data track we need to read the TOC... Btw, mounting the device works just fine. So does running blkid(8) manually # blkid -o udev -p /dev/sr0 ID_FS_LABEL=Some_Label ID_FS_LABEL_ENC=Some%20Label ID_FS_TYPE=udf ID_FS_USAGE=filesystem Thanks. [1] : This is on f15 with cdrom_id from udev-166-1.fc15.x86_64. # /lib/udev/cdrom_id --debug /dev/sr0 main: probing: '/dev/sr0' cd_inquiry: INQUIRY: [DAVIDZ][DVD-ROM][0010] cd_profiles: current profile 0x10 cd_profiles: profile 0x10 media_dvd_ro cd_profiles: GET CONFIGURATION: size of features buffer 0x0070 cd_profiles: GET CONFIGURATION: size of features buffer 0x0070 cd_profiles: GET CONFIGURATION: feature 'profiles', with 2 entries feature_profiles: profile 0x10 dvd_rom feature_profiles: profile 0x1b dvd_plus_r cd_profiles: GET CONFIGURATION: feature 0x0001 <ignored>, with 0x04 bytes cd_profiles: GET CONFIGURATION: feature 0x0002 <ignored>, with 0x04 bytes cd_profiles: GET CONFIGURATION: feature 0x0003 <ignored>, with 0x04 bytes cd_profiles: GET CONFIGURATION: feature 0x0010 <ignored>, with 0x08 bytes cd_profiles: GET CONFIGURATION: feature 0x001d <ignored>, with 0x00 bytes cd_profiles: GET CONFIGURATION: feature 0x001f <ignored>, with 0x00 bytes cd_profiles: GET CONFIGURATION: feature 0x002b <ignored>, with 0x04 bytes cd_profiles: GET CONFIGURATION: feature 0x0100 <ignored>, with 0x00 bytes cd_profiles: GET CONFIGURATION: feature 0x0105 <ignored>, with 0x00 bytes cd_profiles: GET CONFIGURATION: feature 0x0107 <ignored>, with 0x04 bytes cd_profiles: GET CONFIGURATION: feature 0x0108 <ignored>, with 0x08 bytes cd_profiles: GET CONFIGURATION: feature 0x010a <ignored>, with 0x0c bytes info_scsi_cmd_err: READ TOC failed with SK=2h/ASC=24h/ACQ=00h cd_media_info: disk type 00 cd_media_info: hardware reported media status: complete ID_CDROM=1 ID_CDROM_DVD=1 ID_CDROM_DVD_PLUS_R=1 ID_CDROM_MEDIA=1 ID_CDROM_MEDIA_DVD=1 ID_CDROM_MEDIA_STATE=complete ID_CDROM_MEDIA_SESSION_COUNT=1 ID_CDROM_MEDIA_TRACK_COUNT=1
what format is cdrom_id's READ TOC asking for? currently only 0 & 1 are supported.
(In reply to comment #1) > what format is cdrom_id's READ TOC asking for? currently only 0 & 1 are > supported. The code is here http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/cdrom_id/cdrom_id.c;h=b2f897e3b55511708ec61534ca4ef11375503487;hb=HEAD#l744 Looks to me like it's asking for format number 0...
it appears the tgt code assumes first track is number 0, whereas cdrom_id and the spec say first track is number 1. http://git.kernel.org/?p=linux/kernel/git/tomo/tgt.git;a=blob;f=usr/mmc.c;h=5ce94d45c0e2cb7fbbe4add1af6a27711342cb0c;hb=HEAD#l194
(In reply to comment #3) > it appears the tgt code assumes first track is number 0, whereas cdrom_id and > the spec say first track is number 1. > > http://git.kernel.org/?p=linux/kernel/git/tomo/tgt.git;a=blob;f=usr/mmc.c;h=5ce94d45c0e2cb7fbbe4add1af6a27711342cb0c;hb=HEAD#l194 The obvious patch - if (toc_track) { + if (toc_track != 1) { indeed makes cdrom_id work. However, with that fix, ordinary block IO starts returning ENOMEDIUM on the initiator side: # dd if=/dev/sr1 of=foo dd: opening `/dev/sr1': No medium found Maybe the returned TOC is invalid and this is freaking out drivers/scsi/sr.c?
Btw, the returned TOC has the wrong length - as per MMC-6 6.25.3.2.4, it should be 0x12, not 0x1a (a data disc in one of my ATA optical drives also gives a TOC of size 0x12). I still get ENOMEDIUM though... So far the patch is like this... --- a/usr/mmc.c +++ b/usr/mmc.c @@ -190,9 +190,9 @@ static int mmc_read_toc(int host_no, struct scsi_cmd *cmd) switch (toc_format) { case 0: /* formatted toc */ - if (toc_track) { + if (toc_track != 1) { /* we only do single session data disks so only - track 0 is valid */ + the first track (track 1) is valid */ scsi_set_in_resid_by_actual(cmd, 0); sense_data_build(cmd, NOT_READY, ASC_INVALID_FIELD_IN_CDB); @@ -206,7 +206,7 @@ static int mmc_read_toc(int host_no, struct scsi_cmd *cmd) /* size of return data */ data[0] = 0; - data[1] = 0x1a; + data[1] = 0x12; data[2] = 1; /* first track */ data[3] = 1; /* last track */ -- 1.7.4.1
I haven't gotten any further on this, but I was going to send the obviously-correct fixes we have so far upstream, maybe get some attention there too. Can I get your official signoff on your patch in the above comment?
Created attachment 489090 [details] Patch (In reply to comment #6) > I haven't gotten any further on this, but I was going to send the > obviously-correct fixes we have so far upstream, maybe get some attention there > too. I didn't get much farther either... > Can I get your official signoff on your patch in the above comment? Certainly. I've attached a git-formatted patch. Thanks!
This udev bug is causing fedora livecds to fail to mount root on some hardware, for example https://bugzilla.redhat.com/show_bug.cgi?id=681999 and https://bugzilla.redhat.com/show_bug.cgi?id=624028 . So hopefully this fix is backported to Fedora 14 aswell!
(In reply to comment #8) > This udev bug But "this" is not an udev bug. It's a bug with scsi-target-utils. > is causing fedora livecds to fail to mount root on some hardware, > for example https://bugzilla.redhat.com/show_bug.cgi?id=681999 and > https://bugzilla.redhat.com/show_bug.cgi?id=624028 . No, I think you're confused. As in I very much doubt a lot of people are booting live CDs from an iSCSI connected drive. It could be you are just running into problems with a buggy drive (either virtualized or iron) but let's not conflate the issues here please.
Ok, sorry. My issue with livecds is also with "READ TOC", but it's a different issue. Thanks.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached 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 to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping