Shallow Thoughts : tags : hal

Fixing scanner permissions on Hardy

Dave needed something scanned. Oh, good! The first use of a scanner under a new distro is always an interesting test. Though the last few Ubuntu releases have been so good about making scanners "just work" that I was beginning to take scanners for granted. "Sure, no problem," I told Dave, taking the sketch he gave me.

Ha! Famous last words. For Hardy, I guess the Ubuntu folks decided that users had had it too easy for a while and it was time to throw us a challenge. Under Hardy, scanning works fine as root, but normal users can't access the scanner. sane-find-scanner sees the scanner, but xsane and the xsane-gimp plug-in can't talk to it (except as root).

It turns out the code for noticing you plugged in a scanner and setting appropriate permissions (like making it group "scanner") has been removed from udev, the obvious place for it ... and moved into hal. Except, you guessed it, whatever hal is supposed to be doing isn't working, so the device's group is never set to "scanner" to make it accessible to non-root users. Lots of people are hitting this and filing bugs (search for scanner permissions), in particular bug 121082 and bug 217571.

Fortunately, the fix is quite easy if you have a copy of your old gutsy install: just copy /etc/udev/rules.d/45-libsane.rules from gutsy to the same place on hardy. (If you don't have your gutsy udev rules handy, I attached the file to the latter of the two bugs I linked above.)

Then udev will handle your scanner just like it used to, and you don't have to wait for the hal developers to figure out what's wrong with the new hal rules.

Tags: linux, ubuntu, scanner, udev, hal
[ 16:56 May 22, 2008    More linux | permalink to this entry | ]

k3b breaks without hal

I burned a CD for the Ubuntu hardy beta alternate installer. I used k3b since that's been a good, fairly reliable burning app with a well designed UI -- I've been using it for years despite not running a KDE desktop. I selected "Burn CD Image", reduced the speed (burning apps are always wildly optimistic about speed, with the result that they create a lot of coasters) and checked the box for "verify contents after burning".

The burn went fine, and k3b ejected the CD, then sucked it back in again for the verification stage. At that point k3b started spewing lots of errors to the terminal, things like "/dev/hdd: READ 10 failed!" and "Failed to init HAL context!" repeated many times.

How annoying! k3b has added a new dependency on hal, and although it can burn a CD just fine, without hal it then forgets where the CD drive was so it can read the CD back in to verify it.

Fortunately dd /dev/cdrw | md5sum worked fine to verify that the burn was correct. I guess it's time to investigate other CD burning programs.

Tags: linux, hal
[ 11:04 Apr 10, 2008    More linux | permalink to this entry | ]

Udev Tidbits Picked Up at LCA

A couple of udev tips I picked up at LinuxConf, mostly from talking to folks in the hallways:

I'd been having trouble getting my laptop to read its built-in memory stick since upgrading to Ubuntu Edgy. It's basically the same problem I described in an earlier article: the machine boots, sees the built-in reader with no card there, and udev creates /dev/sda but not /dev/sda1. Later, I insert a memory stick, but the reader (like so many other USB-based flash card readers) does not generate an event, so no new device is created.

In that earlier article, the solution was to change the udev rule that creates the device and add something like NAME{all_partitions}="stick". The all_partitions tells it to create /dev/stick1, /dev/stick2 etc. up through the possible maximum number of partitions. (It would be nice to limit it just to /dev/stick1, but there doesn't seem to be any way to do that.)

Unfortunately, in edgy, the udev rules have been rewritten to be a lot more general, and adding {all_partitions} wasn't working. But LinuxConf gave me two solutions to this problem:

First, I was able to pester one of the hal developers about hal's annoying mandatory polling. (This is the official Ubuntu solution to the problem, by the way: if you let hald wake up twice a second to poll every device on the USB bus to see whether anything new has been added, then you'll get that /dev/sda1 device appearing. I wasn't the only one at the conference, I was happy to find, who was unhappy about this hald misbehavior. It got mentioned in at least two other talks as an example of inefficient behavior that can eat batteries and CPU, and a questioner during the hal talk echoed my opinion that the polling should be made optional for those of us who don't want it.)

Anyway, I asked him what hald does to create the /dev/sda1 device once it sees a card. It turns out that touch /dev/sda causes udev to wake up and re-check the device, and create any new device nodes which might have appeared. Hurrah! That's a much cleaner workaround than sudo mknod.

But at breakfast a few days later, I found myself sitting next to a udev expert. He took a look at the file I'd created, /etc/udev/rules.d/memstick.rules, and after a few minutes of fiddling discovered what it was missing: a crucial ACTION=="add" directive which hadn't been required under the old system. The working line now looks like this:

KERNEL=="sda", ACTION=="add", OPTIONS=="all_partitions", NAME{all_partitions}="stick"

Tags: linux, udev, hal
[ 22:14 Feb 07, 2007    More linux | permalink to this entry | ]

UDEV and Multiple Flash Card Readers

Update: Some of this has changed; see my newer entry, Update on writing udev rules for flash card readers.

Dave had one of those nifty front-panel multiple flash card readers sitting on a shelf, so I borrowed it. It's USB based, fits in a CD drive bay, and has slots for all the common types of flash memory, as well as a generic USB socket.

With the device installed, I booted into my usual Ubuntu (hoary) partition, inserted an SD card and checked dmesg. Nothing! The four logical units of the device had been seen at boot time, but nothing new happened when I inserted a card.

I tried mounting /dev/sda1, /dev/sdb1, /dev/sdc1, /dev/sdd1, and /dev/sde1 anyway, but got "No such device" each time.

Dave muttered darkly about udev and hal and said I should try it under an older Debian with a normal /dev. I rebooted my old sid partition, with a kernel I built myself. I needed a kernel with "Probe all LUNs on each SCSI device", of course. I still got no messages or hotplug events when inserting the card, but /dev/sdd1 mounted the SD card.

(For anyone reading this who's not familiar with Linux' handling of USB storage devices, sd in /dev/sdd1 stands for "SCSI disk" and has nothing to do with the fact that I was using a "secure digital" media card. Any USB disk or flash card is supposed to show up under /dev/sdsomething and the main trick is figuring out the something. Which is part of what udev and hal are supposed to help with.)

Then I discovered that doing an fdisk -l /dev/hdd gave the right answer (one partition) for the SD card. And as soon as I did that, the /dev/sdd1 device appeared and I was able to mount it normally.

Apparently, when udev sees the logical units at boot time, with no cards inserted, it decides that there's a /dev/sdd, but it has no partitions on it so there's no such device as /dev/sdd1. Since inserting a card later doesn't generate a hotplug event, udev never re-evaluates this, unless somehow forced to (apparently running fdisk forces it, though I'm not sure why). Dave was right: udev/hal are the culprit here, and the kernel was fine.

A helpful person on #ubuntu pointed me to this tutorial on writing rules for udev. It mentions the problem with multi USB card readers not getting additional events when cards are plugged in, and suggests modifying the NAME key in the rules (which seem to be in /etc/udev/rules.d/udev.rules to:

BUS="usb", SYSFS{product}="USB 2.0 Storage Device", NAME{all_partitions}="usbhd"

Elsewhere in the document, it suggests getting that SYSFS{product} string by running a command like udevinfo -a -p /sys/block/sdd

Unfortunately, that seems to be completely ignored. udevinfo told me the string was "CardReader SD ", but plugging that in to udev.rules did not create any /dev/usbhd* devices. It also seemed clear that udev is using BUS="scsi" rather than BUS="usb" for these devices, based on the device names that are being created (sd* rather than ub*). But making that change didn't help.

Eventually I found a combination that worked. Ubuntu's current rules for usb-storage devices are:

BUS="scsi", KERNEL="sd[a-z]*", PROGRAM="/etc/udev/scripts/removable.sh %k", RESULT="1", NAME="%k", MODE="0640", GROUP="plugdev"
BUS="usb", KERNEL="ub[a-z]*", NAME="%k", MODE="0640", GROUP="plugdev"

(I don't know what devices create the ub* devices. It's nothing I've used so far).

I changed the "sd[a-z]*" to "sd[e-z]*", so that it wouldn't apply to the four devices grabbed by the multicard reader. Then I added these four lines:

BUS="scsi", KERNEL="sda*", PROGRAM="/etc/udev/scripts/removable.sh %k", RESULT="1", NAME{all_partitions}="cfcard", MODE="0640", GROUP="plugdev"
BUS="scsi", KERNEL="sdb*", PROGRAM="/etc/udev/scripts/removable.sh %k", RESULT="1", NAME{all_partitions}="smcard", MODE="0640", GROUP="plugdev"
BUS="scsi", KERNEL="sdc*", PROGRAM="/etc/udev/scripts/removable.sh %k", RESULT="1", NAME{all_partitions}="mscard", MODE="0640", GROUP="plugdev"
BUS="scsi", KERNEL="sdd*", PROGRAM="/etc/udev/scripts/removable.sh %k", RESULT="1", NAME{all_partitions}="sdcard", MODE="0640", GROUP="plugdev"

That worked. Now udev creates /dev/sdcard[1-15] as well as /dev/sdcard (and likewise for the other three flash types), and I can make a normal /etc/fstab entry:

/dev/sdcard1    /sd             auto    rw,user,noauto   0       0

Now as a user I can say mount /sd without needing to su to root or do any extra fiddling. Hurrah!

Tags: linux, udev, hal
[ 16:49 Nov 07, 2005    More linux | permalink to this entry | ]

"I'm sorry, Dave, but I can't let you have your disk back"

I got a new, large, and most important, quiet disk for my laptop.

The first Linux distro I installed on it was Ubuntu. Since quiet was my biggest incentive for buying this disk (the old IBM disk was so loud that I was embarassed to run the laptop in meetings), as soon as the install was finished I carried the laptop into a quiet room to listen to the disk,

Turns out it was making a faint beep-beep noise every second or two, plus some clicking in between.

Another, non-Linux, operating system installed on the same disk does not make these beeping or clicking noises. It was clearly something Ubuntu was doing.

After a long series of ps and kill, I finally narrowed the problem down to hald. HAL is polling my disk, once per second or so, in a way that makes it beep and click.

(HAL, if you're not familiar with it, is the Hardware Access Layer which works hand in hand with the kernel service udev to monitor hardware as it comes and goes. No one seems to know where the dividing line is between udev and hal, or between the daemons udevd and hald. Most systems which enable one, enable both.)

I floated down to the control room to dismantle HAL, humming "Daisy".

But it turned out I didn't need to kill HAL entirely. The polling apparently comes from HAL's attempt to query the CDROM to see if anything has been inserted. (Even if there is no CDROM connected to the machine. Go figure!)

The solution is to edit /etc/hal/hald.conf, and change true to false under <storage_media_check_enabled> and <storage_automount_enabled_hint>. This changes hald from a "blacklist" policy, where everything is polled unless you blacklist it, to a "whitelist" policy, where nothing is polled unless you whitelist it. Voila! No more polling the disk, and no more beepy-clicky noises. I suspect my drive will last longer and eat less battery power, too.

Tags: linux, hal
[ 20:00 Jul 30, 2005    More linux | permalink to this entry | ]