identify removable hard disk drawers and mount to a fixed ..

J G Miller wrote:
> When a disk is plugged in, you should see a message in dmesg which
> identifies the SATA port eg

Thank you, that did the initial trick.

I'm still learning a lot every new day when configuring systems, so I'm
not sure on how to automate this process.

I am currently writing (c++, because I'm not really good at shell
programming) a little tool that will detect drive insertion (by
searching the appropriate lines in the dmesg output - btw. is there a
stream to poll that has this output? Instead of creating the output in
intervals and checking the whole file?) and then mount the inserted
drive into the desired directory, based on which SATA connector it is
attached to.

Now the next thing I need is to get Lenny to automatically execute this
service (or later I'll rewrite it as a bash script, maybe for
/etc/init.rd/?) whenever a new "unmounted hard disk" is detected.

I tried configuring the autorun-feature of the KDE, by creating a new
service (which worked) and associating that service with "unmounted hard
disk" (which did not work) - but the latter doesn't show up under
"available medium types"...

Any ideas?

Thanks again!

Lars

On 2009-05-14, Lars Uffmann <aral.DeleteThis@nurfuerspam.de> wrote:
> J G Miller wrote:
>> When a disk is plugged in, you should see a message in dmesg which
>> identifies the SATA port eg
>
> Thank you, that did the initial trick.
>
> I'm still learning a lot every new day when configuring systems, so I'm
> not sure on how to automate this process.
>
> I am currently writing (c++, because I'm not really good at shell
> programming) a little tool that will detect drive insertion (by
> searching the appropriate lines in the dmesg output - btw. is there a
> stream to poll that has this output? Instead of creating the output in
> intervals and checking the whole file?) and then mount the inserted
> drive into the desired directory, based on which SATA connector it is
> attached to.
>
> Now the next thing I need is to get Lenny to automatically execute this
> service (or later I'll rewrite it as a bash script, maybe for
> /etc/init.rd/?) whenever a new "unmounted hard disk" is detected.
>
> I tried configuring the autorun-feature of the KDE, by creating a new
> service (which worked) and associating that service with "unmounted hard
> disk" (which did not work) - but the latter doesn't show up under
> "available medium types"...
>
> Any ideas?
>
> Thanks again!
>
> Lars

I would let udev create /dev/drawer[0..3] based on the by-path
specification. It is already there, just use it.

wimpunk wrote:
> I would let udev create /dev/drawer[0..3] based on the by-path
> specification. It is already there, just use it.

That sounds a lot better than my approach! Thanks to you I'll try it
out as soon as I can.

Best Regards,

Lars

wimpunk wrote:
> I would let udev create /dev/drawer[0..3] based on the by-path
> specification. It is already there, just use it.

That was exactly what I needed. Thank you very much for the helpful
information!

I added the following to the bottom of the
/etc/udev/rules.d/50-udev.rules
rules file:
KERNELS=="2:0:0:0" SUBSYSTEMS=="scsi" DRIVERS=="sd" SYMLINK+="drawer0"
KERNELS=="3:0:0:0" SUBSYSTEMS=="scsi" DRIVERS=="sd" SYMLINK+="drawer1"
KERNELS=="4:0:0:0" SUBSYSTEMS=="scsi" DRIVERS=="sd" SYMLINK+="drawer2"
KERNELS=="5:0:0:0" SUBSYSTEMS=="scsi" DRIVERS=="sd" SYMLINK+="drawer3"

I had the KERNELS-information for my 4 hotplug-capable-SATA-drawers from
ls -l /dev/disk/by-path

Works like a charm! Now I only need to find out how to define the
automount action... Didn't quite work for me yet so far.

Edit: From my reading the documentation, my above syntax might (and
will, likely) match both the raw disk and the first partition. So I
suppose a line like
KERNEL=="sd?1" KERNELS=="2:0:0:0" SUBSYSTEMS=="scsi" DRIVERS=="sd"
SYMLINK+="drawer0"
would be the better route to take?

I've been thinking about merging the above 4 rules into 1 general rule,
along the lines of
KERNEL=="sd?1" KERNELS=="[2-5]:0:0:0" SUBSYSTEMS=="scsi" DRIVERS=="sd"
PROGRAM="/bin/device_namer.sh $path" SYMLINK+="drawer%c{0}"
and then my script at /bin/device_namer.sh could extract the first
number from the raw disks KERNEL (as it appears in the path string) and
return a drawer number based on that.

However, it seems I cannot get the script to execute with the above
line. Can someone tell me if there is an apparent mistake?

Also, is the [2-5]:0:0:0 KERNEL part in the path in any way affected by
USB flash drives being plugged into the system? Or can I safely assume
that my 4 removable HD drawers will remain attached under this path as
long as I do not plug in/remove any additional controllers?

Thanks for any help!

Lars

Lars Uffmann wrote:
I added the following to the bottom of the
/etc/udev/rules.d/50-udev.rules
rules file:
KERNEL="sd?1" KERNELS=="2:0:0:0" SUBSYSTEMS=="scsi" DRIVERS=="sd"
SYMLINK+="drawer0"
KERNEL="sd?1" KERNELS=="3:0:0:0" SUBSYSTEMS=="scsi" DRIVERS=="sd"
SYMLINK+="drawer1"
KERNEL="sd?1" KERNELS=="4:0:0:0" SUBSYSTEMS=="scsi" DRIVERS=="sd"
SYMLINK+="drawer2"
KERNEL="sd?1" KERNELS=="5:0:0:0" SUBSYSTEMS=="scsi" DRIVERS=="sd"
SYMLINK+="drawer3"

I had the KERNELS-information for my 4 hotplug-capable-SATA-drawers from
ls -l /dev/disk/by-path

Then, for the mounting, I used autofs:
apt-get install autofs

Add a new configuration for automounts:
vim /etc/auto.master
add line:
/media /etc/auto.removable --timeout=10,sync,nodev,nosuid

Create file /etc/auto.removable:
vim /etc/auto.removable
add lines:
drawer0 -fstype=vfat :/dev/drawer0
drawer1 -fstype=vfat :/dev/drawer1
drawer2 -fstype=vfat :/dev/drawer2
drawer3 -fstype=vfat :/dev/drawer3

Restart autofs:
/etc/init.d/autofs restart

This works a little different from how I originally intended, as it only
mounts the removable hard disks when I actually access the directories
/media/drawer[0-3], and unmounts them again after timeout (10 seconds)
if no read/write operations happen, but that is even better than
the permanent mount, because I don't even have to worry about manually
unmounting the removable hard disks.

Now I can write a tiny backup script which tells the user to "Insert a
backup medium into drawer X" and then backups to exactly that hard disk
as soon as it has been inserted, then gets ready for the next backup
cycle for whenever it is scheduled

I would still kind of like to figure out how to automount when the
device is created/plugged in and then just manually unmount when my
backup operation has finished.

Best Regards,

Lars

On Mon, 25 May 2009 23:01:23 +0100, Lars Uffmann wrote:

> I would still kind of like to figure out how to automount when the
> device is created/plugged in and then just manually unmount when my
> backup operation has finished.

Perhaps, you should look at this section of the udev FAQ, and get udev
to run a script which detaches (to avoid udev being held up) to mount
the device (no need for autofs then), do the backup, and then unmount
it and send a message to the operator?

QUOTE

Running external programs upon certain events

Yet another reason for writing udev rules is to run a particular program
when a device is connected or disconnected. For example, you might want
to execute a script to automatically download all of your photos from
your digital camera when it is connected.

Do not confuse this with the PROGRAM functionality described above.
PROGRAM is used for running programs which produce device names (and
they shouldn't do anything other than that). When those programs are
being executed, the device node has not yet been created, so acting
upon the device in any way is not possible.

The functionality introduced here allows you to run a program after
the device node is put in place. This program can act on the device,
however *it must not run for any extended period of time*, because udev
is effectively paused while these programs are running. One workaround
for this limitation is to make sure your program immediately detaches
itself.

Here is an example rule which demonstrates the use of the RUN list
assignment:

KERNEL=="sdb", RUN+="/usr/bin/my_program"

When /usr/bin/my_program is executed, various parts of the udev environment
are available as environment variables, including key values such as
SUBSYSTEM. You can also use the ACTION environment variable to detect
whether the device is being connected or disconnected - ACTION will be
either "add" or "remove" respectively.

udev does not run these programs on any active terminal, and it does not
execute them under the context of a shell. Be sure to ensure your program
is marked executable, if it is a shell script ensure it starts with an
appropriate shebang (e.g. #!/bin/sh), and do not expect any standard output
to appear on your terminal.

UNQUOTE

J G Miller wrote:
> Perhaps, you should look at this section of the udev FAQ, and get udev
> to run a script which detaches (to avoid udev being held up) to mount
> the device (no need for autofs then), do the backup, and then unmount
> it and send a message to the operator?

Thank you for the pointer, I missed that somehow during my trial and
error research I'lll hopefully get to check that out before I head
off into holidays.

Best Regards,

Lars