Choosing mount folders for udev/HAL

[SimonJW]

EDIT: I have solved the problem of having USB media mounting where I want it to. I have written a short HOWTO three or four posts further down in this thread. Enjoy!
----------------------

I recently switched back from using kde to gnome (on my FC3 desktop), and so I can now take advantage of the udev, HAL, gnome-volume-manager combo, which is great!

The only problem is, I want HAL to mount certain devices that I own in specific mount point - for example, I want my iRiver H140 to be automagically mounted at /media/iriver instead of /media/usbdisk.

I was previously using a udev rule to identify my hardware:

BUS="usb", SYSFS{manufacturer}="iRiver", SYSFS{serial}="0123456789AB", NAME="%k", SYMLINK="iriver"

and create the symlink /dev/iriver. Then, with the appropriate entry in fstab:

/dev/iriver   /media/iriver   vfat  noauto,users,uid=500,rw,dev,sync   0 0

I could simply run mount /mnt/iriver, and the device would be mounted regardless of where it is located.

Now, however, HAL automatically mounts the hardware whenever I plug it in - but not, obviously, to the place I want it to, because fstab-sync is generating a new line in /etc/fstab. How do I tell it that this piece of hardware should be mounted at /media/iriver, and all others still mounted in the default locations?

I heard there is a way to do this that is similar to writing udev rules, where HAL can identify a specific piece of hardware, but HAL's documentation seems a bit shabby at best. Has anyone else done this?

Cheers,
SimonJW

[tashirosgt]

An embarrasing silence! It's sad how many former Linux experts have been demoted to novice status by udev, HAL and logical volumes. (I include myself.)

[SimonJW]

Hehe, too true!

I *think* I've figured out how to do it, by creating fdi files in /usr/share/hal/fdi/95userpolicy/.
I have it working for two or so of my devices, so far so good.

Once I'm sure what I'm doing, I'm thinking that I might post a quick howto here to explain how it's done. After all, having your USB stick automagically mount in where *you* want it to must be quite a common request, right?

[tashirosgt]

Yes it is. You can find about 1/3 of the requests by searching for "thumb drive", "pen drive" or "memory stick" respectively. They add up to an impressive number.

[Finalzone]

That reminds me when hal used to automatically mount non-hotpluggable device such as hard drive on earlt FC3T3. That feature was disabled due to this critical bug. I don't know if that issue is solved yet.
Now that this topic is brought, let's work to create a decent tutorial since I cannot find any around.

[SimonJW]

HOWTO: Modify the automatic mounting of devices
This is a quick HOWTO I've made because I wanted my MP3 player to always mount in the same place so that I could write scripts that knew where it would be mounted.

Fedora automagically mounts devices using a program called HAL (and D-BUS, and gnome-volume-manager, and udev, but it's HAL that we need to look at to change things.) I'm not an expert at using HAL, I picked it up quickly to perform a specific task with. Correction are more than welcome!
Why?
When you insert a new piece of hardware (an external harddisk, a USB Stick, an MP3 player), Fedora Core 3 automagically mounts it to /mnt/usbdisk. This is, obviously, really really cool! But if you have two things inserted, it will mount the second one in /mnt/usbdisk2. Then, if you unplug them and plug them back in the other way around, the locations that they mount to will switch!

I wanted to be able to have my iRiver H140 MP3 player mount at /mnt/iriver and my USB stick mount at /mnt/usbstick. This is much easier if you want to write a script to copy things from place to place - it's also much neater, and a lot less confusing.

There are many other reasons for playing about with HAL files - you can give a more helpful label your USB stick on the GNOME desktop (that "Generic" thing annoys me!). You can change the settings a particular device is mounted with (I want to set uid,gui settings on removeable FAT32 USB sticks!), and you can make the iPod work (details in a link at the end)...

How?
1) First things first, we need the right tools for the job. You need to be running Fedora Core 3 or later (I have not tested this on Core 4!). This is the first Fedora to use HAL. Now you need to open up a terminal and type:

rpm -q hal-gnome

Does RPM tell you that you have a copy of the hal-gnome package installed? If not, you need to install it. Run:

yum install hal-gnome

assuming you have set up yum properly.

Once you have installed the hal-gnome package, you are ready to begin.

2) We need root permissions for this, so in that terminal type

su -l

and enter your root password.

Now navigate to /usr/share/hal/fdi/ and see what's there using the ls command. Inside these directories are .fdi files, and HAL will look inside these directories for files telling it what to do everytime something new is added. We will put our files in 95userpolicy. Inside this directory, we want to create a file with a relevant name. Any name is OK, so long as it ends in .fdi. I am after changing the behaviour for my iRiver, so I type:

gedit iriver.fdi

You can use any text editor you prefer.

3) We need to add the basic structure to this file. Add this:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">


</deviceinfo>

4) Now we're going to look at the properties of a device, and how we use them to identify a specific device, and then how we use them to control the mounting of a device.

Remember we installed the hal-gnome package? We're now going to use the important tool in that - run:

hal-device-manager

and take some time to familiarise yourself with the program. It reminds me quite a bit of Registry Editor in windows, except it can't be used to make changes.

Make sure to select the "advanced" tab to see all the information. Plug in a USB device and watch what happens as HAL updates the information. Look at the properties of the device.

For most USB devices, you will see a large tree of items be created - the bottom most one is the partition's filesystem. You can think of it as the /dev/sda1 if you like. Its parent is the device itself, like the /dev/sda.

I have included some images of my device manager, before and after plugging in my iRiver.

5) Now we go back to the gedit window. Here is a completed file to use as an example:

<deviceinfo version="0.2">
<device>
    <match key="block.is_volume" bool="true">
      <match key="volume.fsusage" string="filesystem">
        <match key="@block.storage_device:storage.vendor" string="TOSHIBA">
          <match key="@block.storage_device:storage.model" string="MK4004GAH">
            <merge key="volume.policy.desired_mount_point" type="string">iriver</merge>
            <merge key="volume.label" type="string">iRiver H140</merge>
          </match>
        </match>
      </match>
    </match>
  </device>
</deviceinfo>

Let's work through this file.

The match tags are used to specify a particular device to HAL. In this example, HAL asks if the device has block.is_volume=true, which the filesystem device for my iriver does. Secondly, it asks if it has volume.fsusage=filesystem, which again I know that it does. These properties are common to almost all USB drives filesystem devices.

Now, I want to match one or two more properties that are specific to my iRiver. The @block.storage_device: bit tells HAL that I don't want to match the storage.vendor property of my device. Rather, I want to match any device whose parent has this storage.vendor. Every device in HAL has a unique ID number, and the block.storage_device property (for USB filesystems) stores the unique ID number of the parent device.

To explain this slightly more simply, /dev/sda is the USB device, and so would have information about the manufacturer. /dev/sda1 is the partition, and so it is this device we want to match in order to change its mount point, but it is its parent /dev/sda that had the properties we need to check.

6)Once I'm sure I've have matched sufficient properties to narrow my search down to one device only, I want to change what happens. I use the merge tag to do this. This simply overwrites the property with whatever you choose.

I overwrite the volume.policy.desired_mount_point property with iriver, so that my device mounts in /media/iriver. I also change the volume.label property, because this seems to be the first place GNOME looks to decide upon a name for the desktop icon.

7) Now I save the file, and I'm done! Next time I plug the iriver in, HAL should change the mount point and label properties, and then GNOME will use the new values when it mounts it!

If that HOWTO seemed a bit confusing, don't worry. For most USB storage media - usb pen drives, memory sticks, external card readers (that have the card inserted *before* they are plugged in), MP3 player, external hard drives - the example I gave will do the job just fine.

Just use hal-device-manager to find the correct values for your specific product.

Anything else?
Here is the official HAL documentation, which is not usual included with HAL on your computer. It tells you what every property does. Remember, you can change any property with the merge tag.

This web site discusses how to alter HAL's treatment of an iPod to stop some ugly problems you might have with it. It also has a very good and quite complex .fdi file which you can look at to better understand how they work.

Hope this helped out, suggestions more than welcome!

[tashirosgt]

This is great! I think you should submit it to one of the Linux magazines.

A user with a low res display may not see the full width of the hal-device-manager window. Tell them they should not only see the key name but also its type and value.

Section 5 could use a better topic sentence - something like "We will use some information from the hal-device-manager display to flesh out our iriver.fdi file". The matching with the '@' sign could be explained graphically. The lowest level on the device tree has keys like block.is_volume. ( I note the usual contradictory precision of computer terminology. The device manager shows is_volume as "int" and the *.fdi file calls it "boolean". ) The block_storage_device:storage_vendor info is in the keys that are in an entry one level higher. Would this be an over simplification?

Is there a log where syntax errors in the *.fdi file would be reported? I tried this:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
<device>
<match key="block.is_volume" bool="true">
<match key="volume.fusage" string="filesystem">
<match key="@block.storage_device:storage.model" string="LEXAR">
<match key="@block.storage_device:storage.model" string="JUMPDRIVE SECURE">
<merge key="volume.policy.desired_mount_point" type="string">lexmarThumb</merge>
<merge key="volume.label" type="string">lexmar thumb"</merge>

</match>
</match>
</match>
</match>
</device>
</deviceinfo>

And I got the mount point /media/LEXMAR_MEDIA instead of /media/lexmarThumb. But I'm still delighted to have some control over the situation.

[SimonJW]

Thanks very much for the encouragement and suggestions, tashirosgt! I'll work on adding in your ideas as soon as I have time.

Not sure whats wrong with your file... I notice that you use storage.model twice, with different values, but this means the .fdi file *should* just match nothing and change nothing about how the device mounts. Weird that it did nevertheless change something!

I reckon you simply need to change one storage.model for storage.vendor.

[tashirosgt]

I got it to work by leaving off the match on block.is_volume and making the change that you suggested. And I made the cosmetic correction of "lexmar" to "lexar", the correct name. So this worked:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
<device>

<match key="volume.fsusage" string="filesystem">
<match key="@block.storage_device:storage.vendor" string="LEXAR">
<match key="@block.storage_device:storage.model" string="JUMPDRIVE SECURE$
<merge key="volume.policy.desired_mount_point" type="string">lexarThumb$ <merge key="volume.label" type="string">lexar thumb"</merge>

</match>
</match>
</match>
</device>
</deviceinfo>

---edit The paste process put in some $ signs that I can't delete with the forum's message editor. So what I meant was:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
<device>

<match key="volume.fsusage" string="filesystem">
<match key="@block.storage_device:storage.vendor" string="LEXAR">
<match key="@block.storage_device:storage.model" string="JUMPDRIVE SECURE">

<merge key="volume.policy.desired_mount_point" type="string">lexarThumb</merge>
<merge key="volume.label" type="string">lexar thumb"</merge>

</match>
</match>
</match>
</device>
</deviceinfo>

[Finalzone]

On Fedora Core 4 Test 2, there is no folder called 95userpolicy. I guess that was renamed polcy.

[da644]

Hi.

Excellent HOWTO, I have just been trying this with my Belkin CF Card reader and it works to a point, but it doesn't actually mount the FS. When I plug the device in with a CF card it, it creates the directory in /media/ but if I enter the cfcardreader directory there are no files. If I become root and type mount /dev/sda1 /media/cfcardreader there are then files. Any ideas? Here is the contents of my FDI file.

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
<device>
<match key="block.is_volume" bool="true">
<match key="volume.fsusage" string="filesystem">
<match key="@block.storage_device:storage.vendor" string="BELKIN">
<match key="@block.storage_device:storage.model" string="USB 2 HS-CF">
<merge key="volume.policy.desired_mount_point" type="string">cfcardreader</merge>
<merge key="volume.label" type="string">CF Card Reader</merge>
</match>
</match>
</match>
</match>
</device>
</deviceinfo>

Thanks.

Andrew.

[SimonJW]

da644: Are you sure that the rules you have created are matching the card itself, or the card reader. I've heard that there are a lot of issues with card readers, and things not being dynamicallly updated by udev. Try plugging in the card-reader with the card in and re-checking that your rule is actually getting the right device. Otherwise, it may be creating the directory and then trying to mount the card reader onto it - not a good idea!

Hope that helps, I'll try and think if i could be anything else!

[da644]

I think the problem is with KDE as it works ok in GNOME. I KDE I seem to need to actually tell it to mount, whereas in GNOME it mounts it straight away without me telling it too. Once mounted it appears in the right place. I read elsewhere that this has been fixed in KDE 3.4. Thanks anyway.

Andrew.

[SimonJW]

Ah yes, KDE doesn't have any capabilities yet deal with information from HAL, whereas GNOME has gnome-volume-manager. As you point out, KDE 3.4 has had this added, but the kde-redhat repos don't seem to have this feature. Hopefully it'll be in the version of KDE that comes with Core 4!

[Nemo]

I might be being a complete newbie here, but im trying to mount my iRiver H10 to /media/iRiver by following your steps. But looking through hal-device-manager I have found my iRiver, but looking through the 'Advanced' tab i cant see any of the values labled block.is_volume, volume.fusage, block.storage_device:storage.vendor or block.storage_device:storage.vendor. Is there something im missing here, or am i just beling blind?

the device tree i have looks kinda like this:
-nForce2 USB Controller
------IRIVER H10
-----------Vendor Specific Interface
------USB Hub Interface

In the Vendor Specific Interface bit i have values like: usb.vendor string IRIVER etc... is this the kind of thing i should be looking for to enter into my iriver.fdi?

Many Thanks for any help you can give

Nemo