I updated my desktop to Fedora Core 3 over the weekend. Technically, Fedora would consider it a fresh install, I just kept /home /work /usr/local and /opt. It all went smoothly thanks to my love of apt for rpm and the various repositories that I’ve talked about before that I use to keep me from hand compiling almost everything. The only thing I’ve done differently this time was that I’ve added DAG’s apt/yum repository to the mix.

With FC3 comes some new ways to get external devices going easier. udev, which “is an implementation of devfs in userspace using sysfs and /sbin/hotplug,” used to be an add on, but is now a central part of the distribution. udev is configured in such a way that it controls all of the /dev entries. Along with udev is the addition of freedesktop.org‘s Hardware Abstraction Layer software. This isn’t like the HAL in some other operating systems and based on the documentation that is not the goal. From the documentation:

HAL which is a piece of software that provides a view of the various hardware attached to a system. In addition to this, HAL keeps detailed metadata for each piece of hardware and provide hooks such that system- and desktop-level software can react to changes in the hardware configuration in order to maintain system policy.

Its not the world’s most useful thing yet, but considering FC3 ships with version 0.4.2 its doing a good job for its level of maturity.

One of the most useful things that HAL provides FC3 is the auto configuration of devices that would have removable media, such as cdrom drives, or is added via USB or firewire. In its default configuration is works pretty good: udev creates the /dev nodes and HAL, after scoping out and probing the hardware, creats mount points in /media and calls /usr/sbin/fstab-sync (which comes with HAL) to edit /etc/fstab with the entries. For my devices that have removable media, HAL has noticed my CD and DVD burners and has created /media/cdrecorder and /media/cdrecorder1. If I connect my iPod up via firewire, I see that /media/ieee1394disk is created. Putting a compact flash card in a slot of my 8-in-1 USB media reader, I see that /media/usbdisk is created.

As I said before, this is pretty good. However, there were a few things that bugged me that I wanted to change. The first problem I ran into was that hald, constantly probes attached media devices for media changes. This works great for my 8-in-1, as it correctly drops access to the device when I run /usr/bin/eject on the mount points. However, this fails dismally with my iPod.

In FC2, to get the iPod to go into the “OK to remove” mode, the eject command did the trick. In FC3, thanks to hald, it tries to spin up the iPod harddrive again. However, the iPod, after its in “OK to remove” mode will not respond to any commands from the computer until removed from the cradle. hald trying to contact it again causes the SCSI subsystem to go into a loop trying to reset the device and the SCSI bus, causes hald to hang, and generally really pisses off Linux. Since this whole ordeal ends with the SCSI subsystem kernel panicing and hald being stuck in a disk wait, the only thing to really get things back to normal that that point is a reboot. The reboot then has some issues thanks to hald being in disk wait, and Linux can’t cleanly unmount /usr.

So, obviously, I wanted to fix the “everything goes to shit when I want to remove my iPod” problem and I wanted to create a better mount point name for the iPod. Face it, /media/ieee1394disk is pretty weak and /media/iPod is much sexier.

I started digging around the hal package to see what docs came with it and what the config files were. The documentation that ships in the RPM is fairly non-existant except for some sample Device Information Files aka .fdi files. Next I looked in /etc/hald/hald.conf. That had a directive called storage_media_check_enabled which was set to true. Setting that to false and halfway fixed my iPod problem, except now two mount points were showing up in media. Also, setting it to false broke the 8-in-1 which was behaving perfectly. Not wanting to throw the baby out with the bathwater, I set it back to true. This setting, however, started to point me in the right direction.

Next I discovered the hal-gnome package by doing an apt-cache search hal. From this I found the misnamed /usr/bin/hal-device-manager. I say its misnamed as you get a Windows-style device manager view, but you can’t actually manage anything, its totally a read-only view. However, this let me see the properties that were being set for each device and its volumes along the way. Thanks to hal-device-manager I was starting to be able to read the .fdi files. However, my next question was “what are all the possible values of propery names that can be set?” For that I needed more documentation.

I visited the freedesktop.org hal site (as linked above) and it didn’t have anything really useful on it. I was getting motivated enough to just start reading C code, so I downloaded the hal-0.4.4 source from freedesktop.org. To my delight, there was actual useful documentation, albiet in raw docbook XML form. I almost cried, but I pulled myself together and typed make to build the documentation into a useful HTML file. Here was a list of all the possible properies, where they were good, and mostly good descriptions of what they did. I still didn’t have a full enough understanding, so it came time to start experimenting.

In my experimenting, I focused totally on making the iPod work the way I wanted and figured I’d tackle the 8-in-1 later as it mostly works the way I want now. The existing .fdi files have a comment that says to create system local files in /usr/share/hal/fdi/95userpolicy as all the other files in the other directories could be overwriten when/if the vendor updates the hal package. I started to write an iPod.fdi file and based my <device> entry on some of the existing firewire disk entry and merged it with the sample firewire connected hard drive example from /usr/share/doc/hal-0.4.2/conf

What I ended up with after my experimenting is something that seems to work really well. It turns off the media check just for the iPod, ignores the first partition used by the Apple Firmware, and makes a mount point at /media/iPod for the second partition where all the music lives. I also was able to add the sync mount option to the automatically created fstab entry. Lots of iPod on Linux people suggest mounting the iPod in sync mode, but I forget exactly why at this moment as my brain is running out of juice as I’m ending of this post.

This was through a bunch of trial and error, and if someone has a better way to do it, please let me know.
Here is my /usr/share/hal/fdi/95userpolicy/iPod.fdi

<?xml version="1.0" encoding="ISO-8859-1"?>  
<deviceinfo version="0.2">
  <device>
    <match key="storage.vendor" string="Apple">
      <match key="storage.model" string="iPod">
        <merge key="storage.requires_eject" type="bool">true</merge>
        <merge key="storage.removable" type="bool">false</merge>
        <merge key="storage.media_check_enabled" type="bool">false</merge>
      </match>
    </match>
    <match key="@block.storage_device:storage.vendor" string="Apple">
      <match key="@block.storage_device:storage.model" string="iPod">
        <match key="block.is_volume" bool="true">
          <match key="volume.fsusage" string="filesystem">
            <match key="volume.partition.number" int="1">
              <merge key="volume.policy.should_mount" type="bool">false</merge>
            </match>
            <match key="volume.partition.number" int="2">
              <merge key="volume.policy.desired_mount_point" type="string">iPod</merge>
              <merge key="volume.policy.mount_option.sync" type="bool">true</merge>
            </match>
          </match>
	</match>
      </match>
    </match>
  </device>
</deviceinfo>