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..
Correction, I believe it is the sysfs filename /sys/block/sr0 which is tripping it up due to ending in a number.
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.
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.
Info added
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
*** Bug 201150 has been marked as a duplicate of this bug. ***
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.
Created attachment 134760 [details] Patch This patch (mostly lifted from hal git) fixes the problem for me.
Comment on attachment 134760 [details] Patch This patch breaks automounting, no it's no good.
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?
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?
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.
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.
Thanks. I do not have a freedesktop bugzilla account. Please take care of sending it upstream.
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..
We seem to have stalled. Can we get an update out?
This is fixed in Fedora 7, I don't think Fedora 5 is likely to get patched anymore..