Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

Most USB keys work on my system: plug one in and udev will create a device file for the key as a whole (e.g. /dev/uba), as well as a device file for the partition (e.g. /dev/uba1).

I have a specific USB key (a Sandisk Cruzer Micro 2Gb) which udev misbehaves with. The device file for the key is created, but not for the partition.

If I compare the dmesg output between a working key and my problem key, it is identical except for one line which is missing when using the problem key: uba: uba1. It would appear from this that mknod is never creating a node for the disk partition.

The weird thing is that I can do...

sudo sfdisk -R /dev/uba

...to force drive partitions to be re-examined and suddenly the partition will be recognised, mknod will create a device file it and I can access the key all fine and dandy like. Some kind of timing issue?

EDIT:

Automount USB Rules:

ACTION=="add", KERNEL=="ub[a-z]*[1-9]*", PROGRAM="/sbin/blkid -o values -s TYPE %N", RESULT=="vfat", RUN+="/home/ubuntu/.mount_usb %k %n"
ACTION=="remove", KERNEL=="ub[a-z]*", RUN+="/home/ubuntu/.unmount_usb"

Also: The problem key defaults to FAT16 when being reformatted. Forcing it to FAT32 results in udevadm monitor --property spitting out exactly the same properties for the device and partition as for a working key, but the problem still remains. This leads me to think that it's less likely to be a problem with the device detection rules and perhaps a problem with the device itself? Is this a logical conclusion?

share|improve this question
add comment

1 Answer 1

up vote 0 down vote accepted

Just from the /dev/uba naming structure, it sounds like you created your own UDEV rule and now it's not working out for you. We'll need to see that code to assist you.

I'm sure you've consulted this already but just in case please consult this reference for creating UDEV rules. http://wiki.debian.org/udev

Feedback based on update

ACTION=="add", KERNEL=="ub[a-z]*[1-9]*", PROGRAM="/sbin/blkid -o values -s TYPE %N", RESULT=="vfat", RUN+="/home/ubuntu/.mount_usb %k %n"
ACTION=="remove", KERNEL=="ub[a-z]*", RUN+="/home/ubuntu/.unmount_usb"

It looks like your predecessor didn't know about usbmount. This rule will only work on vfat formatted drives, now you could expand that list, or... you could install usbmount and tweak it to create the device names you want. Then you have something that's maintained for you with only minor configuration changes vs a complete home brew solution.

BTW, there's a syntax error in there, it's value not values, running this from the CLI shows.

sudo blkid -o value -s TYPE /dev/sdb1
vfat

So the %N is the input, e.g. the block device and RESULT is stdout. This is detailed in the udev man page. You might be able to do something like this RESULT=="[vfat|fat16]", or you could forward the output to a script and do a richer comparison there. A quick look at the usbmount package shows that rich comparisons are done in the callout script for both add and remove. I strongly recommend you migrate to usbmount.

share|improve this answer
    
I've inherited this issue and it's the first time I've gotten down and dirty with Ubuntu, so please assume that I'm ignorant of anything outside the research shown above! That said, I did think it was odd that my devices are being named ub* rather than sb*. I have four sets of rules in /etc/udev/rules.d: 60-automount-usb, 70-persistent-cd, 70-persistent-net, 80-usb-permissions. All seem irrelevant, except the automount set (which I've added above) - but even that seems like a response to the partition device file being added rather than the specification for how to create the file. –  sjwarner Apr 17 '12 at 7:33
    
Alright then, if it were me, I would seek and destroy that entire rule as it offers no value. Just grep until you find it and remove the ruleset. The right way to do this is scan for something unique, like make, model, and serial #, and then create a symlink to the normal sdx devices. This way you keep all the original devices in place, including the partition probing, and you just mixin your additional label. The reason you're not seeing a partition is whoever made that ubX rule failed to run partprobe or equivalent on the raw device. Hope this helps. –  ppetraki Apr 17 '12 at 13:01
    
Cheers for the continued help! I don't understand though, I need the rule above to my automount script so I can't just get rid of it. Don't I need to find the rule that actually creates the ubX device in the first place? And wherever that rule is defined, if it's missing a partprobe why do some keys work and some don't? Surely it would either work or it wouldn't? Sorry if I'm being wilfully dense :P –  sjwarner Apr 17 '12 at 13:40
    
This is where it get's complicated, I need to see the actual script. My current assumption is the rule is creating a new ubX block device instead of creating an sdx block device. I would like to leave block device creation alone and instead symlink to the proven sdx block devices. It'll also be easier to maintain as you're just an ls -l away to finding out what that device really is. As for it's inconsistency, udev is premised on pattern and rule matching, without seeing the original rule, I can only speculate as to why it's not running consistently. You're not dense, UDEV is awkward. –  ppetraki Apr 17 '12 at 14:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.