hal does not detect non-ATAPI CD-ROM drives

I have connected a DVD burner to my laptop by USB. The burner is recognized and available as /dev/scd0 and /dev/sg0.

However if I insert a medium in the burner (i.e. a disc with data on it or an audio CD) the disc is not automounted, no icon appears on the desktop. In fact exactly nothing happens.

This is on an up-to-date edgy installation.

Perhaps the root of the problem is that hal detects the drive as a "scsi generic" device.

I can mount CDs by double clicking on CDROM1 in Places->Computer but I have no way of using for instance sound-juicer or banshee because I assume they only look at hal to find the CD drives (and don't find any in my case).

I'll attach the lshal output. The relevant udis start with "/org/freedesktop/Hal/devices/usb_device_5e3_701_noserial_if0"

Let me know if you need more info.

An additional note:
When I have mounted the disk by double clicking on CDROM1 in Places->Computer and then right-click on the disk icon on the desktop I have no option to eject the disk only to unmount.
Clicking that unmounts the disk but the tray stays closed.

I have the same with my Serial ATA CD drive on my Dell Inspiron 630m. Works fine with Breezy and Dapper, but doesn't after installing Edgy a week or so back. hal can't see the disc, but sees the drive fine.

Here I've attached my lshal output.

I can also confirm this. Now, this is breaking hubackup's ability to detect target devices for backups properly. Should I workaround it by rewriting the detection code , or is it going to get fixed ? AFAICS this has to be fixed since just working around this will turn out ot be a hack, while the hal system needs to be backward compatible to its behavior in dapper.

setting to high as this breaks a range of programs relying on HAL to detect media changes and optical devices.

Can you please do

  sudo udevmonitor -e | tee udevmonitor.txt

then connect the drive, wait some seconds until it settled, press Control-C to stop udevmonitor, and then do

  dmesg > dmesg.txt

? Please attach the two logs here.

Added an attachment of hubackup's device detector code. Just save it in a folder, chmod 755 the file and execute it. If you have a CDRW or DVRW or a USB disk attached to the system you should see a listing showing them as entries.

I can reproduce it here with ogra's USB DVD.

The output of udevmonitor seems cut off at the end. I don't know why. It stayed that way for more than 10 seconds, so I quit...

Sivan, running your script gives me:

ImportError: No module named fsMisc

So, the old bug 36274 seems to have reappeared, forwarded upstream.

Got a workaround now.

 hal (0.5.7.1-0ubuntu6) edgy; urgency=low
 .
   * Add 16-nonpartitions-ending-in-nums.patch:
     - Hal currently assumes that device names ending in numbers are
       partitions. This patch adds a safe and easy, but slightly ugly
       workaround. (Real fix will be discussed with upstream at
       https://bugs.freedesktop.org/show_bug.cgi?id=5558)
     - This breaks SCSI, USB, and Firewire CD drives, which are usually called
       'scd0', 'sr1', etc.
     - Closes: LP#56484 and an impressive number of duplicates.

Fixed for me. Thanks a lot!

Also fixed for me. Thanks, pitti!

High-impact bug with an easy patch (https://bugs.freedesktop.org/attachment.cgi?id=6658), I think we want that in dapper, too.

Matt, can I please have your blessing for dapper-updates?

Hi Matt,

I propose to fix https://launchpad.net/bugs/56484 in dapper.

Impact: hal does not detect drives whose device file name ends in
numbers; this particularly affects non-ATAPI CD-ROM devices (/dev/sr0)
and floppies (/dev/fd0). (Please look at the bug duplicates for
confirmation that dapper is affected as well). Apparently this worked
fine in breezy. We have a request from the support center to fix this
in Dapper.

Patch: http://librarian.launchpad.net/4313504/16-nonpartitions-ending-in-nums.patch

While this is not a nice an general solution for future upstream
versions, it is a very conservative and cautios solution. Hal's
current logic is flawed: if a device ends in numbers, then the code
assumes it's a partition on a drive and takes dirname(drive name) as
the parent sysfs device. However, in the case of e. g. /dev/sr0 (which
is a drive and not a partition), the parent of /sys/block/sr0 is
/sys/block which is not a valid sysfs device, and thus the device is
discarded with 'no parent'. According to Scott James Remnant, sysfs
gurarantees that /sys/block/foo are drives and /sys/block/foo/bar are
partitions, thus the patch just special-cases the flawed logic and
re-sets the 'is_partition' flag if the device name is a direct entry
in /sys/block (as opposed to a subdirectory of a /sys/block/ dir).

Status: Applied in Edgy some weeks ago, tested with appropriate
hardware, no reported regressions.

Martin

On Tue, Sep 19, 2006 at 06:44:20PM +0200, Martin Pitt wrote:
> I propose to fix https://launchpad.net/bugs/56484 in dapper.
>
> Impact: hal does not detect drives whose device file name ends in
> numbers; this particularly affects non-ATAPI CD-ROM devices (/dev/sr0)
> and floppies (/dev/fd0). (Please look at the bug duplicates for
> confirmation that dapper is affected as well). Apparently this worked
> fine in breezy. We have a request from the support center to fix this
> in Dapper.
>
> Patch: http://librarian.launchpad.net/4313504/16-nonpartitions-ending-in-nums.patch
>
> While this is not a nice an general solution for future upstream
> versions, it is a very conservative and cautios solution. Hal's
> current logic is flawed: if a device ends in numbers, then the code
> assumes it's a partition on a drive and takes dirname(drive name) as
> the parent sysfs device. However, in the case of e. g. /dev/sr0 (which
> is a drive and not a partition), the parent of /sys/block/sr0 is
> /sys/block which is not a valid sysfs device, and thus the device is
> discarded with 'no parent'. According to Scott James Remnant, sysfs
> gurarantees that /sys/block/foo are drives and /sys/block/foo/bar are
> partitions, thus the patch just special-cases the flawed logic and
> re-sets the 'is_partition' flag if the device name is a direct entry
> in /sys/block (as opposed to a subdirectory of a /sys/block/ dir).
>
> Status: Applied in Edgy some weeks ago, tested with appropriate
> hardware, no reported regressions.

Looks fine, please upload to dapper-proposed.

--
 - mdz

Matt Zimmerman [2006-09-19 20:55 -0700]:
> Looks appropriate; please upload to dapper-proposed.

Done:

   * Add 16-nonpartitions-ending-in-nums.patch:
     - Hal currently assumes that device names ending in numbers are
       partitions. This patch adds a safe and easy, but slightly ugly
       workaround. (Real fix will be discussed with upstream at
       https://bugs.freedesktop.org/show_bug.cgi?id=5558)
     - This breaks SCSI, USB, and Firewire CD drives, which are usually called
       'scd0', 'sr1', etc.
     - Closes: LP#56484 and an impressive number of duplicates.

I attached the debdiff to the bug report.

Bug submitters, can you please test this, too, after it's available in
dapper-proposed? Thank you!

> Status: Applied in Edgy some weeks ago, tested with
> appropriate hardware, no reported regressions.

I'm running up-to-date edgy and this still does not work for me despite the patch. lshal does not list any of my two internal SCSI disc drives (one DVD drive and one CD burner). The kernel recognises them fine, and the appropriate information can be found in /sys/block/srX/*

Is this supposed to work now for my case as well?
If yes, anything I can provide to help track this down further?

Tim, apparently you have a different problem then. Please create a new bug and do the steps on https://wiki.ubuntu.com/DebuggingRemovableDevices . Thanks!

Package is in dapper-proposed. Testing and feedback would be highly appreciated! It will go into -updates next Wednesday if all goes well.

Marc Tardif has verified that it does not break on removable CD-ROM drives.

We're waiting for Oliver to confirm that it fixes his bug.

works fine here, my usb dvd mounts properly and shows the right icon on the desktop

Thank you for testing, I did the -updates upload which is now waiting for an archive team member to approve:

 hal (0.5.7-1ubuntu18.2) dapper-updates; urgency=low
 .
   * No-change upload of 0.5.7-1ubuntu18.1 to dapper-updates.
   * Thanks to Simon Law and Oliver Grawert for testing!

Accepted into dapper-updates. Per StableReleaseUpdates, Martin, please shout ASAP if there are any regressions.

This version breaks Kubuntu media mounting.

See: bug #72869

I shortly discussed that with Jonathan. It only breaks with the unofficial KDE 3.5.5 packages, not with Dapper's KDE.

<Riddell> pitti: but I'll look into making a suitable hal package for those kubuntu.org packages when I have some spare time
<pitti> Riddell: shall I revert the ubuntu-updates patch for now?
<pitti> it'll break SCSI and USB CD-ROMs again, but...
<Riddell> pitti: I wouldn't revert a fix in ubuntu because it breaks some unsupported packages

<pitti> Riddell: hm, in dapper's hal there's only a '<policy at_console="true">' policy for the Mount methods, no 'group=plugdev' as in edgy
<pitti> Riddell: so it actually appears that it should fail the same way with dapper final's hal
<pitti> Riddell: the curious thing is that they claimed that downgrading to 18.1 from dapper-proposed fixed it
<pitti> Riddell: but 18.2 is the same as 18.1, just uploaded to dapper-updates
<-- jonh_wendell hat sich getrennt (Client Quit)
<Riddell> pitti: the kubuntu.org kde 3.5.5 archive has a modified version of 0.5.7-1ubuntu18.1
<pitti> Riddell: aah, that explains it then
<pitti> Riddell: so reverting the hal fix in ubuntu would not fix it at all then

So the SRU is ok as it is.