[lug] Help w/udev rules

Maxwell Spangler maxlists at maxwellspangler.com
Tue Sep 24 00:20:39 MDT 2013


On a backup server I have two external USB docks.  I'm writing scripts
so a user can install new offsite backup drives and tell the computer to
make them available to receive backups.  Another script will copy the
appropriate backup files to the drives.  For the backup script to work
consistently, I want to present the removable storage in a predictable
manner.

Because these are USB, I've seen their actual drive devices in /dev
change letters based on a variety of factors.

So I'm trying to use udev rules to make this predictable:

1) User installs drive and powers on the dock
.. works

2) udev uses standard rules to identify a storage device and
create /dev/sdf (for example)
.. works

3) I have installed a user rule which is specific to this USB3 dock and
piggybacks a little more onto step 2:  It will create a symlink
from /dev/sdf to /dev/usb3dock so that my scripts can use /dev/usb3dock
as a predictable location.
.. works

At least while developing this remotely (without actually power cycling
the dock), it appears as though udev will correctly identify /dev/sdf as
the USB3 dock and correctly make a symlink to /dev/usb3dock, but it
fails to load the partitions on the drive and create /dev entries for
them.

If you've worked with udev can you tell me if that should be happening?

My work-around tonight was to insert a small bash script into the custom
udev rule, call it, and run partprobe.

With a little more work involving two udev rules and a custom script, I
can see udev wake up six times* and everything is working.  I'd like to
know if I'm followng best practices or whether this is a hack that
works.

* six times: one for /dev/sdf, one for the symlink'd /dev/usb3dock, two
for /dev/sdf1 and /dev/sdf2, and two for /dev/usb3dock1
and /dev/usb3dock2.

It's been a long night of fighting with udev but I'm happy it seems I've
won.

-- 
Maxwell Spangler
========================================================================
Linux System Administration / Virtualization / Development / Computing
Services
Photography / Graphics Design / Writing
Fort Collins, Colorado
http://www.maxwellspangler.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20130924/e94d6627/attachment.html>


More information about the LUG mailing list