Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a HDSPA USB stick from Vodafone for mobile broadband, a HUAWEI model K3520 (in some places also designated E169 I think) which works just fine in Ubuntu 10.04 "Lucid" (amd64). This device is automatically mounted as a CD-ROM device by Ubuntu -- supposedly by the HAL daemon, hald -- namely the "partition" containing the device-specific software.

The contents of the auto-mounted partition (upon inserting the stick in a USB port):

ubuntu@lucid:~$ ls -lh /media/VMC\ LITE*/
total 37M
-r-------- 1 ubuntu ubuntu   70 2008-03-13 19:39 Autorun.inf
-r-------- 1 ubuntu ubuntu  36M 2008-04-14 19:28 helper.exe
-r-------- 1 ubuntu ubuntu 316K 2008-03-13 17:33 setup.exe

The symlink /dev/cdrom gets assigned from the CD-ROM device at /dev/sr0 to the device /dev/sr1 upon detection of the USB stick,

ubuntu@lucid:~$ ls -lh /dev/cdrom
lrwxrwxrwx 1 root root 3 2011-04-27 22:48 /dev/cdrom -> sr1
ubuntu@lucid:~$ ls -lh /dev/sr*
brw-rw----+ 1 root cdrom 11, 0 2011-04-27 22:34 /dev/sr0
brw-rw----+ 1 root cdrom 11, 1 2011-04-27 22:48 /dev/sr1

which although not a serious impediment it is nevertheless an annoyance. For example, in the console this forces specifying eject -d /dev/sr0 to open the CD-ROM tray, instead of a simple eject; supposedly, other programs wanting to use the genuine CD-ROM drive will require specifying explicitly the device instead of "assuming" the symlink /dev/cdrom to point to the "correct" device.

I have tried to follow instructions from a Arch Linux thread about hald, by creating my own configuration as /etc/hal/fdi/policy/cdrom.fdi with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
    <match key="block.storage_device" string="/org/freedesktop/Hal/devices/storage_model_CDDVDW_SH_S223C">
      <merge key="volume.policy.should_mount" type="bool">true</merge>
      <merge key="volume.policy.desired_mount_point" type="string">cdrom</merge>
    <match key="storage.vendor" string="HUAWEI">
      <match key="storage.model" string="Mass Storage">
        <match key="storage.bus" string="usb">
          <match key="storage.drive_type" string="cdrom">
            <merge key="volume.policy.should_mount" type="bool">false</merge>

in an unsuccesful attempt to "coherce" hald into always assigning /dev/sr0 to /dev/cdrom instead of auto-mounting the USB stick on insertion.

I realize that I could use gconf-editor to toggle the key /apps/nautilus/preferences/media_automount, but that would affect all media -- which is not quite what I'm looking for, although given the low impact of this "annoyance" it might be an acceptable compromise.

However, I am looking at some insight into what hald configuration might yield the desired results -- ignoring assigning /dev/sr1 (the USB stick) to /dev/cdrom and thereby maintaining the symlink of /dev/cdrom to /dev/sr0 (the CD-ROM drive).

share|improve this question
up vote 1 down vote accepted

The naming of the cdrom devices is configured in /etc/udev/rules.d/70-persistent-cd.rules . In my version of the file there are four lines that create the cdrom, cdrw, dvd and dvdrw symlinks, all pointing to the same drive:

SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-2:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-2:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-2:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-2:0:0:0", SYMLINK+="dvdrw", ENV{GENERATED}="1"

What do these lines do? They test some things with the == operator, and then they add (+=) a symlink or set (=) the environment variable GENERATED.

You want to insert a new test there, so that your HSDPA stick is ignored.

So you need to find a unique attribute of your device. You can run lsusb in the terminal and look if you find your HSDPA stick there. And you can also ask udev itsself, e.g. with

udevadm info --export-db | less

(In "less" you can search with the / key, and quit with q.) Try to find a unique attribute, like ID_SERIAL, ID_VENDOR_ID or ID_MODEL_ID. The hex numbers in ID_VENDOR_ID and ID_MODEL_ID are the same numbers as in the output of lsusb.

If you have found something unique, insert a new test in the udev lines, comparing for inequality with the != operator:

SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_SERIAL}!="_USB_DISK_Pro_075A06420103-0:1", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-2:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1"

Save the file, eject the USB stick, plug it in again and hope that it is working.

share|improve this answer
Unfortunately I am very unfamiliar with the workings of udev. The tip on the 70-persistent-cd.rules file was exactly what I was looking for. There was already a rule for the USB HDSPA stick, and I merely changed the value of the respective SYMLINK parameter for something other than "cdrom". The eject command no longer appears to be confusing the two. Thanks elmicha! – jbatista May 12 '11 at 20:57

This has something to do with writing some udev rules for your device. I'm not an expert on the topic, but you might want to research on these links:

That's all I know. Hope it helps.

share|improve this answer
Thanks for the links. I'll look into them. – jbatista May 12 '11 at 20:58

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.