Shallow Thoughts
Akkana's Musings on Open Source, Science, and Nature.
Thu, 22 May 2008
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
[
15:56 May 22, 2008
More linux |
permalink to this entry
]
Fri, 04 Apr 2008
I'm experimenting with Ubuntu's "Hardy Heron" beta on the laptop, and
one problem I've hit is that it never configures my network card properly.
The card is a cardbus 3Com card that uses the 3c59x driver.
When I plug it in, or when I boot or resume after a suspend, the
card ends up in a state where it shows up in ifconfig eth0,
but it isn't marked UP. ifup eth0 says it's already up;
ifdown eth0 complains
error: SIOCDELRT: No such process
but afterward, I can run ifup eth0 and this time it
works. I've made an alias, net, that does
sudo ifdown eth0; sudo ifup eth0. That's silly --
I wanted to fix it so it happened automatically.
Unfortunately, there's nothing written anywhere on debugging udev.
I fiddled a little with udevmonitor and
udevtest /class/net/eth0 and it looked like udev
was in fact running the ifup rule in
/etc/udev/rules.d/85-ifupdown.rules, which calls:
/sbin/start-stop-daemon --start --background --pid file /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}
So I tried running that by hand (with $env{INTERFACE} being eth0)
and, indeed, it didn't bring the interface up.
But that suggested a fix: how about adding --force
to that ifup line? I don't know why the card is already in a state
where ifup doesn't want to handle it, but it is, and maybe
--force would fix it. Sure enough: that worked fine,
and it even works when resuming after a suspend.
I filed bug
211955 including a description of the fix. Maybe there's some
reason for not wanting to use --force in 85-ifupdown
(why wouldn't you always want to configure a network card when it's
added and is specified as auto and allow-hotplug in
/etc/network/interfaces?) but if so, maybe someone will
suggest a better fix.
Tags: linux, ubuntu, udev, net
[
13:41 Apr 04, 2008
More linux |
permalink to this entry
]
Sun, 23 Dec 2007
I use wireless so seldom that it seems like each time I need it, it's
a brand new adventure finding out what has changed since the last time
to make it break in a new and exciting way.
This week's wi-fi adventure involved Ubuntu's current "Gutsy Gibbon"
release and my prism54 wireless card. I booted the machine,
switched to the right
(a href="http://shallowsky.com/linux/networkSchemes.html">network
scheme, inserted the card, and ... no lights.
ifconfig -a showed the card on eth1 rather
than eth0.
After some fiddling, I ejected the card and re-inserted it; now
ifconfig -a showed it on eth2. Each time I
inserted it, the number incremented by one.
Ah, that's something I remembered from
Debian
Etch -- a problem with the udev "persistent net rules" file in
/etc/udev.
Sure enough, /etc/udev/70-persistent-net.rules had two entries
for the card, one on eth1 and the other on eth2. Ejecting and
re-inserting added another one for eth3. Since my network scheme is
set up to apply to eth0, this obviously wouldn't work.
A comment in that file says it's generated from
75-persistent-net-generator.rules. But unfortunately,
the rules uesd by that file are undocumented and opaque -- I've never
been able to figure out how to make a change in its behavior.
I fiddled around for a bit, then gave up and chose the brute force
solution:
- Remove /etc/udev/75-persistent-net-generator.rulesa
- Edit /etc/udev/70-persistent-net.rules to give the
device the right name (eth1, eth0 or whatever).
And that worked fine. Without 75-persistent-net-generator.rules
getting in the way, the name seen in 70-persistent-net.rules
works fine and I'm able to use the network.
The weird thing about this is that I've been using Gutsy with my wired
network card (a 3com) for at least a month now without this problem
showing up. For some reason, the persistent net generator doesn't work
for the Prism54 card though it works fine for the 3com.
A scan of the Ubuntu bug repository reveals lots of other people
hitting similar problems on an assortment of wireless cards;
bug
153727 is a fairly typical report, but the older
bug 31502
(marked as fixed) points to a likely reason this is apparently so
common on wireless cards -- apparently some of them report the wrong
MAC address before the firmware is loaded.
Tags: linux, ubuntu, udev, net
[
18:02 Dec 23, 2007
More linux |
permalink to this entry
]
Sun, 13 May 2007
When we left off,
I had just found a workaround for my Feisty Fawn installer problems
and had gotten the system up and running.
By now, it was late in the day, time for my
daily Sitescooper run to grab some news to read on my Treo PDA.
The process starts with making a backup (pilot-xfer -s).
But pilot-xfer failed because it couldn't find the device,
/dev/ttyUSB1. The system was seeing the device connection --
dmesg said
[ 1424.598770] usb 5-2.3: new full speed USB device using ehci_hcd and address 4
[ 1424.690951] usb 5-2.3: configuration #1 chosen from 1 choice
"configuration #1"? What does that mean? I poked around /etc/udev a
bit and found this rule in rules.d/60-symlinks.rules:
# Create /dev/pilot symlink for Palm Pilots
KERNEL=="ttyUSB*", ATTRS{product}=="Palm Handheld*|Handspring *|palmOne Handheld", \
SYMLINK+="pilot"
Oh, maybe they were calling it /dev/pilot1? But no, there was nothing
matching /dev/*pilot*, just as there was nothing matching
/dev/ttyUSB*.
But this time googling led me right to the bug,
bug
108512. Turns out that for some reason (which no one has
investigated yet), feisty doesn't autoload the visor module when
you plug in a USB palm device the way other distros always have.
The temporary workaround is sudo modprobe visor;
the long-term workaround is to add visor to /etc/modules.
On the subject of Feisty's USB support, though, I do have some good
news to report.
My biggest motivation for upgrading from edgy was because USB2 had
stopped working a few months ago --
bug 54419.
I hoped that the newer kernel in Feisty might fix the problem.
So once I had the system up and running, I plugged my trusty
hated-by-edgy MP3 player into the USB2 hub, and checked dmesg.
It wasn't working -- but the error message was actually useful.
Rather than obscure complaints like
end_request: I/O error, dev sde, sector 2033440
or
device descriptor read/64, error -110
or
3:0:0:0: rejecting I/O to dead device
it had a message (which I've since lost) about "insufficient power".
Now that's something I might be able to do something about!
So I dug into my bag o' cables and found a PS/2 power adaptor that
fit my USB2 hub, plugged it in, plugged the MP3 player into the hub,
and voila! it was talking on USB2 again.
Tags: linux, ubuntu, udev, palm, pda, usb
[
20:10 May 13, 2007
More linux |
permalink to this entry
]
Wed, 07 Feb 2007
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
[
21:14 Feb 07, 2007
More linux |
permalink to this entry
]
Mon, 07 Nov 2005
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
[
15:49 Nov 07, 2005
More linux |
permalink to this entry
]