5

Every morning 9am we plug an external HD to our office server (always to the same USB port).
Every day the HD is new, but all of them are made by the same manufacturer (Freecom).

Everyday at 12am, a script runs backing up everything to the HD.
The first step is to mount the HD in this fashion:

mount /dev/sdc1 /mnt/backup

The problem is sometimes the device file is not /dev/sdc1 but something else (i.e. /dev/sdd1). I still can't figure out why as we are not pluging in anything else and we always use the same port.

So my problem is how to programmatically detect the right device file in a very safe way. My only idea so far is to grep the content of the /dev/disk/by-id directory to find and extract /dev/xxx from this line:

lrwxrwxrwx 1 root root 10 Sep 24 11:03 usb-Freecom_ToughDrive_1A90102657FF-part1 -> ../../sdc1

Any better suggestions? Any concerns about my way?

I am pretty surprised how lsusb can't help me that much.

4 Answers 4

5

the by-id entry is a link, in most cases you can simply use that instead of /dev/sdc1. if not, you can dereference it with readlink

readlink -f /dev/disk/by-id/usb-Freecom_ToughDrive_1A90102657FF-part1
/dev/sdc1
1

You can fix is easily with udev rules. udev rules run on boot and at various hot-plug events to run special handling programs / services or set device naming. It sounds like what you want a udev rule to to consistently name your drive to something like /dev/backup so an mtab entry can consistently mount /dev/backup to /mnt/backup (you can even have the device mounted automatically if you'd like.

Here is an older but still largely relevant guide to writing udev rules. In recent Linux distros udevinfo functionallity has been folded into the udevadm command. Using a command like this should help you figure out what particular fields you want to match on:

udevadm info -q all --path=/sys/block/sdc

Once you know what fields are sufficient for mapping, you'll want to create a udev rule file in /etc/udev/rules.d/ (noting that rule files are evaluated in natural sort order and your distribution may have it's own rules stored somewhere such as /lib/udev/rules.d/ so name accordingly). You'll want to create a rule that looks something like this which will create a /dev/backup symlink pointing to whatever the device is named:

ENV{DEVTYPE}=="disk", ID_SERIAL=="Freecom_ToughDrive_1A90102657FF", SYMLINK+="backup"
ENV{DEVTYPE}=="partition", ID_SERIAL=="Freecom_ToughDrive_1A90102657FF", SYMLINK+="backup%n"

Note: I'm guessing the serial number above based on the /dev/disk/by-id/ you list above. This may not be matching on the right field or the right value. Further note that this is matching a specific serial number and therefore a specific device, you'll need to change this if you change devices.

Hope that helps!

Simple approach: Since I use udev all the time to polish products for customer consumption, it's often the first thing I reach for. udev is already doing what you want by creating the device unique /dev/disk/by-id entries. Just change your /etc/mtab to mount /dev/disk/by-id/Freecom_ToughDrive_1A90102657FF-part1 at /mnt/backup. A mount /mnt/backup in your script will suffice for the mount.

0

If you do

tail /var/log/messages

right after you insert the USB you will see as which device it got recognized.

2
  • The problem with that is the HD gets plugged in at 9am while the script runs 12am and something else can happen in the middle that would be printed by dmesg
    – Daniele
    Sep 24, 2010 at 14:24
  • well then not tail but grep?
    – Unreason
    Sep 24, 2010 at 14:59
-1

I faced the same issue in one of my implementation, so after finding the solution i wrote a article. It may help others on finding usb device in Linux in case of UDEV, which automatically create or manage devices.

How to find usb device in linux

2
  • linuxexplore, welcome to Server Fault! This is not a place for self-promotion, if you want your answer to count, please post the essence of the article here. Otherwise your post will be considered spamming. Feb 1, 2013 at 11:31
  • Welcome to Server Fault! We really do prefer that answers contain content not pointers to content. Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
    – user9517
    Feb 1, 2013 at 11:48

You must log in to answer this question.