Bug 201533

Summary: SCSI (libata) CD/DVDs not handled properly by hal
Product: [Fedora] Fedora Reporter: Robert Hancock <hancockrwd>
Component: halAssignee: David Zeuthen <davidz>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: akopps, davidz, graeme, mclasen, orion, phil
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-07-14 07:37:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch
none
Makes SCSI/SATA cdrom work again none

Description Robert Hancock 2006-08-07 07:31:02 UTC
Description of problem:

hal apparently does not handle at least an IDE DVD-ROM/CD-RW drive which is
being driven by libata using the libata PATA patch. I assume this would also
affect any other optical drives using the sr driver (SATA, SCSI, USB) as well.

Specifically it doesn't seem to be recognized as a CD drive by HAL, and discs
are not automatically mounted as they should be. lshal shows this part when the
drive is being driven by IDE (as /dev/hdc) but not when being driven by libata
(as /dev/scd0):

udi = '/org/freedesktop/Hal/devices/storage_model_QSI_CD_RW/DVD_ROM_SBW_241'
  info.addons = {'hald-addon-storage'} (string list)
  block.storage_device =
'/org/freedesktop/Hal/devices/storage_model_QSI_CD_RW/DVD_ROM_SBW_241'  (string)
  info.udi =
'/org/freedesktop/Hal/devices/storage_model_QSI_CD_RW/DVD_ROM_SBW_241'  (string)
  storage.cdrom.write_speed = 4236  (0x108c)  (int)
  storage.cdrom.read_speed = 4224  (0x1080)  (int)
  storage.cdrom.support_media_changed = true  (bool)
  storage.cdrom.hddvdrw = false  (bool)
  storage.cdrom.hddvdr = false  (bool)
  storage.cdrom.hddvd = false  (bool)
  storage.cdrom.bdre = false  (bool)
  storage.cdrom.bdr = false  (bool)
  storage.cdrom.bd = false  (bool)
  storage.cdrom.dvdplusrdl = false  (bool)
  storage.cdrom.dvdplusrw = false  (bool)
  storage.cdrom.dvdplusr = false  (bool)
  storage.cdrom.dvdram = false  (bool)
  storage.cdrom.dvdrw = false  (bool)
  storage.cdrom.dvdr = false  (bool)
  storage.cdrom.dvd = true  (bool)
  storage.cdrom.cdrw = true  (bool)
  storage.cdrom.cdr = true  (bool)
  storage.requires_eject = true  (bool)
  storage.hotpluggable = false  (bool)
  info.capabilities = {'storage', 'block', 'storage.cdrom'} (string list)
  info.category = 'storage'  (string)
  info.product = 'QSI CD-RW/DVD-ROM SBW-241'  (string)
  storage.removable = true  (bool)
  storage.physical_device = '/org/freedesktop/Hal/devices/pci_8086_24ca_ide_1_0'
 (string)
  storage.firmware_version = 'VH04'  (string)
  storage.vendor = ''  (string)
  storage.model = 'QSI CD-RW/DVD-ROM SBW-241'  (string)
  storage.drive_type = 'cdrom'  (string)
  storage.automount_enabled_hint = true  (bool)
  storage.media_check_enabled = true  (bool)
  storage.no_partitions_hint = true  (bool)
  storage.bus = 'ide'  (string)
  block.is_volume = false  (bool)
  block.minor = 0  (0x0)  (int)
  block.major = 22  (0x16)  (int)
  block.device = '/dev/hdc'  (string)
  linux.hotplug_type = 3  (0x3)  (int)
  info.parent = '/org/freedesktop/Hal/devices/pci_8086_24ca_ide_1_0'  (string)
  linux.sysfs_path_device = '/sys/block/hdc'  (string)
  linux.sysfs_path = '/sys/block/hdc'  (string)

With libata this entire section is missing from the output.

Version-Release number of selected component (if applicable):

hal-0.5.7.1-2.fc5

How reproducible:

Every time

Steps to Reproduce:
1. Run FC5 on a system using a CD/DVD drive being driven by the sr driver
2. 
3.
  
Actual results:

CDs/DVDs are not auto-mounted when inserted.

Expected results:

CDs/DVDs should be auto-mounted as they are when a drive is being driven by ide-cd.

Additional info:

From what I can tell it seems that hal is getting confused. From the hal verbose
output with IDE:

01:04:16.396 [I] hotplug.c:208: /sys/block/hdc is a block device (devpath)
01:04:16.396 [I] blockdev.c:637: block_add: sysfs_path=/sys/block/hdc
dev=/dev/hdc is_part=0, parent=0x08b8bca8
01:04:16.396 [I] blockdev.c:867: parent_bus is ide
01:04:16.397 [I] blockdev.c:492: Probing storage device /dev/hdc

and with libata:

00:55:32.188 [I] hotplug.c:208: /sys/block/sr0 is a block device (devpath)
00:55:32.188 [I] blockdev.c:637: block_add: sysfs_path=/sys/block/sr0
dev=/dev/scd0 is_part=1, parent=0x00000000
00:55:32.189 [I] blockdev.c:547: get_luks_uuid: device_file=/dev/scd0
00:55:32.189 [I] blockdev.c:673: Ignoring hotplug event - no parent
00:55:32.189 [W] blockdev.c:1043: Not adding device object

Note that is_part is set to 1. Looking at the code in HAL hotplug.c to detect
this flag:

is_partition = isdigit(hotplug_event->sysfs.sysfs_path[len - 1]) ||
       strstr (hotplug_event->sysfs.sysfs_path, "/fakevolume") ;

In other words it assumes the device node is a partition if it ends with a
number. This is clearly wrong as it will think that /dev/scd0 is a partition
when it is an entire device. This seems to be causing HAL to get confused and
not handle the device properly.

This was changed in the hal git repository just recently (since 0.5.7.1) such
that it no longer appears to make this invalid assumption:

http://gitweb.freedesktop.org/?p=hal;a=commit;h=963aa432d16ba81c3f5c404a02b8a5befef7521d
http://gitweb.freedesktop.org/?p=hal;a=commit;h=57a4df10e1d8d2919d2fc2ad358bbfd0de702953

However I have no way of easily testing whether these changes actually fix the
problem..

Comment 1 Robert Hancock 2006-08-07 07:42:22 UTC
Correction, I believe it is the sysfs filename /sys/block/sr0 which is tripping
it up due to ending in a number.

Comment 2 David Zeuthen 2006-08-07 17:33:10 UTC
Interesting. Does HEAD of the git master repo work as it should? It's easy to
test, no need to 'make install', just 

  git clone git://git.freedesktop.org/git/hal.git

then ./autogen --prefix=/usr --sysconfdir=/etc --localstatedir=/var
--disable-policy-kit

then 'make', then cd to hald/ and then ./run-hald.sh from there as root. Of
course you need to 'service haldaemon stop' too.

Thanks.


Comment 3 Robert Hancock 2006-08-07 22:12:40 UTC
No dice on compiling the git HEAD on FC5. Looks like it needs this new
libvolume_id library which is only in the development repo and seems to require
a glibc update to the development version which I don't really want to do..

checking for VOLUME_ID... configure: error: Package requirements (libvolume_id
>= 0.66) were not met:

No package 'libvolume_id' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables VOLUME_ID_CFLAGS
and VOLUME_ID_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

Comment 4 Robert Hancock 2006-08-07 22:13:22 UTC
Info added

Comment 5 akopps 2006-08-13 05:54:59 UTC
I think I am observing the same problem. My PC has two SCSI optical drives. Hald
does not recognize them:

Aug 12 22:49:37 ping hald[13967]: 22:49:37.580 [I] hotplug.c:208: /sys/block/sr0
is a block device (devpath)
Aug 12 22:49:37 ping hald[13967]: 22:49:37.592 [I] blockdev.c:637: block_add:
sysfs_path=/sys/block/sr0 dev=/dev/scd0 is_part=1, parent=0x00000000
Aug 12 22:49:37 ping hald[13967]: 22:49:37.604 [I] blockdev.c:547:
get_luks_uuid: device_file=/dev/scd0
Aug 12 22:49:37 ping hald[13967]: 22:49:37.624 [I] blockdev.c:673: Ignoring
hotplug event - no parent
Aug 12 22:49:37 ping hald[13967]: 22:49:37.635 [W] blockdev.c:1043: Not adding
device object


Comment 6 Graeme Coates 2006-08-17 12:03:15 UTC
*** Bug 201150 has been marked as a duplicate of this bug. ***

Comment 7 Graeme Coates 2006-08-17 12:09:58 UTC
I see the same symptoms for a USB cd-writer (which uses the sr driver) - the
relevant section in lshal is completely missing. (using hal-0.5.7.1-2.fc5).

This worked correctly using a vanilla fc5 install, but became broken after
update through yum.


Comment 8 Philippe Troin 2006-08-23 23:56:24 UTC
Created attachment 134760 [details]
Patch

This patch (mostly lifted from hal git) fixes the problem for me.

Comment 9 Philippe Troin 2006-09-05 23:23:05 UTC
Comment on attachment 134760 [details]
Patch

This patch breaks automounting, no it's no good.

Comment 10 Philippe Troin 2006-09-05 23:25:03 UTC
Created attachment 135616 [details]
Makes SCSI/SATA cdrom work again

This much simplier patch fixes the problem, and now automounting also works!
Please apply.
Is there anyone working on this bug?

Comment 11 John (J5) Palmieri 2006-09-05 23:32:35 UTC
Yes.  I am though I have been busy with fc6 and D-Bus 1.0 lately.  What exactly
is your patch doing?  It is saying if using the sr driver and we have a digit at
the end it still is not a partition.  Does this work for all disk types?

Comment 12 Philippe Troin 2006-09-06 00:22:16 UTC
Hi John.
SOrry to push you a little bit ;-)
Basically, the method of detecting cdroms has changed between hal-0.5.7 and
hal-0.5.7.1.  The newer hal assumes that a device node is a CDROM iff it does
not end with a digit.
That's fine for IDE drives (hda, hdb, etc), but SCSI and libata CDROMs use scd0,
scd1, etc or sr0, src1.
What happens is that SCSI CDROMs are detected as partionnable devices (they're
not), and hal fails to put them in its device list since it cannot find any
partitions.

The patch just extends:
  if the device does not end in [0-9], then the "master" device (hda) is the
partition itself
to
  if the device does not end in [0-9], or if its class matches block/sr, then
the master device (hda, or scd0/sr0) is the partition itself.

I'm not sure what you mean by "working for all disk types".  I've tested the
patch successfully on a laptop with a SATA DVD-/+R DL drive and on a desktop
with a SCSI CDROM drive.  Both drives are now detected successfully, and
automounting, DVD/CD burning etc works as before the 0.5.7.1 release.

I can send the SRPM and i386/x86_64 packages to anyone else willing to test the
changes.  Email me.

Comment 13 John (J5) Palmieri 2006-09-06 00:28:22 UTC
I'll patch tomorrow and send it out.  Thanks for the work.  Can you ping
upstream with the patch or would you like me to do it if you are not already
subscribed to the mailing list or bugzilla.  Thanks.

Comment 14 Philippe Troin 2006-09-06 00:38:18 UTC
Thanks.
I do not have a freedesktop bugzilla account.  Please take care of sending it
upstream.

Comment 15 Robert Hancock 2006-09-06 02:45:02 UTC
Upstream looks like it has a patch which should handle this more generally
rather than special-casing the sr driver, which is what the patch in Comment #8
was apparently based on (but it seems didn't quite work). It may work as it is
in the upstream -git repository, I don't know since I can't build it..

Comment 16 Orion Poplawski 2006-09-26 21:07:47 UTC
We seem to have stalled.  Can we get an update out?

Comment 17 Robert Hancock 2007-07-14 07:37:57 UTC
This is fixed in Fedora 7, I don't think Fedora 5 is likely to get patched anymore..