Linux, UDEV, HAL, and removable drives.

Apr 17, 2008

Now that I've metabolized the caffeine from the two-and-an-unknown-fraction pots of coffee I've drunk today (don't ask), I have it together enough to write about an unusually annoying glitch that plagues Linux users from time to time: Automatic mounting of USB storage devices stops working after you tinker with the systemware, usually after recompiling something or upgrading a package. I ran into this a few days ago but didn't think much of it because I've mostly been using Windows XP for work (yes, yes, you may now all laugh) but I decided to sit down and figure out what happened tonight.

As near as I can tell, it has to do with an unusual interaction between gparted (which I'd been using to nondestructively repartition a USB hard drive earlier this week) and HAL, the Hardware Abstraction Layer. Gparted is nice, but every once in a while after it finishes an operation (it batches the things that you want to do to a drive and executes them in sequence) it'll segfault and die on you (when I have free time, I plan on debugging this). It will have done what you wanted but it might not have cleaned up after itself, and when you plug a USB device in you'll suddenly feel like you're within spitting distance of Jupiter while locked out of your spaceship. Gparted alters the HAL daemon's policy files in the /usr/share/hal/fdi/policy/ directory for a very logical reason: When you're using it to manipulate the partitions of a disk device, you don't want to distract it if you accidentally plug another device in. Specifically, it creates a file called gparted-disable-automount.fdi, which tells the HAL daemon to do exactly what the name suggests: Disable the automatic mounting of hard drives and data keys when you plug them in, even though they will show up normally as manually mountable block devices. This is all well and good, but if the file is left behind when gparted crashes, hald doesn't know any better and does what it thinks is the right thing. If this happens, there are two things that you can do: The simplest is to delete the above file, reboot (or log out and restart hald), and see what happens.

This didn't work for me, unfortunately, so I had to take a more invasive approach: I booted Windbringer down to single user mode, uninstalled HAL (emerge -C sys-apps/hal) and deleted all of hald's policy files (rm -rf /usr/share/hal) to start over. Then I did some poking around and realized that I'd accidentally compiled hald with gparted support (on Gentoo, the USE flag disk-partition was turned on, which mucked with the HAL subsystem). After turning that off and recompiling the subsystem (emerge sys-apps/hal), I rebooted and everything was back to normal because all of the files in that directory tree had been replaced.

Major thanks to the Ubuntu and Gentoo users' forums for making their archives freely accessible (and for documenting the hell out of the lshal utility), and for pointing me to this entry on the Gentoo wiki, which doesn't show up early enough in web searches on the topic.