devd and da* devices (the come back)

R

rainbowcrypt

Hi,

I want to automagically mount my external hard drive.

So I've followed these threads :
http://forums.freebsd.org/showthread.php?t=21932
http://forums.freebsd.org/showthread.php?t=23149
and read the devd.conf(5) (I had some difficulties to understand the different possibilities of the "match").

I used the method of WBlock, but it still doesn't work. My script is ok if I launch it on the command line. It seems to me that the event is not triggered. During my test I simplified the best as I could the "match" and the "action", leading me to this rule in the /etc/devd.conf file:
Code: 
notify 200 {
        match "system" "DEVFS";
        action "touch /usr/home/jmi/zzz.txt";
};

I save the file, do a [cmd=]sudo /etc/rc.d/devfs restart[/cmd] (to be sure that my rule is took into acount), unplug and replug my usb hub (with 3 hard drives). And the zzz.txt file is not created!?

Did I misunderstand something? If someone (perhaps wblock? :e) could help me!
 
A couple of things in addition to aragon's point of restarting devd.

It needs to be a lot more specific about the event detected. Just matching "system" "DEVFS" is going to match all kinds of things that don't have anything to do with that external drive. Match the USB vendor/device IDs, or the umass device creation, or maybe a UFS filesystem label with "cdev".

Also, don't count on there being a normal PATH. Give a full path to touch(1) (/usr/bin/touch).
 
Thanks for answers
@aragon: I see that I didn't restart the good thing :)
If I had read your answer sooner, I didn't do all these reboot after each single change in /etc/devd.conf.

@wblock: I know, but it was for the test! Moreover I noticed it, since after the reboot a lot of directories where created (/media/dspx.x (that's the purpose of my modified script).

So now it works fine, the solution was simply to restart devd and not devs (or rebooting) and removing the su user -c in the devd.conf proposed by wblock on the other thread.

I have another question (I think it is still in the purpose of this thread, but if you think I should create another thread, warn me!)
My first idea was to do something like with gnome: create directories /media/label when I connect the hard drive. But I didn't find how to get the "label" with devd.

When I do a [cmd=]echo $device-name>>/path to a file.txt[/cmd] the file is full of blank :\
 
su(1) is not required, but remember that without it the code runs as root.

Just did some experimenting with labels. cdev provides the whole path relative to /dev. It can match on just labels, but better to include the ufs/ or gpt/ path to be specific.
Code: 
# UFS filesystem label
notify 20 {
        match "system" "DEVFS";
        match "type" "CREATE";
        # UFS filesystem label
        match "cdev" "ufs/darootfs";
        # GPT partition label
        # match "cdev" "gpt/something";
        action "do something";
};
 
Sorry wblock, I really do not understand what your are writing. What are ufs/ and /gpt path? My google search on gpt leads me on explanation about replacing the MBR by the GPT. If it's an obligation, why not, but I want to be sure that's what you asked me to do first :e

Furthermore, I'm not sure my question was clear. In fact I didn't talk about the "ufs" label, but the partition label (2 of my ntfs or msdosfs hard-drives are for example labeled "multimedia" and "Programmes").

Since they are connected on the same hub, I don't know which one is da0 and which one is da1. At this time my script (a little modification of yours) mount them in /media/daXs1. and I have to do a "ls" to know where are my data. It's not a big deal, but it would be easier if I could mount directly on /media/multimedia and /media/Programmes for example. And if possible, with only one statement in devd.conf (I could do 4 statements each matching some vendor/device ID, but I find it ugly :) )
 
There are a bunch of different ways that labels assigned to filesystems and devices show up. Attach a device with GPT labels (gpart(8)) and the labels show up in /dev/gpt/. Attach a device with UFS filesystems that have labels assigned (tunefs(8)) and they show up in /dev/ufs. MS-DOS filesystem labels show up in /dev/msdosfs/. There's a list of known filesystems and where the labels appear in glabel(8).

/etc/devd.conf can be used to detect those labels and do something.
 
Hi
I have made a lot of changes...
The "devd method" was too unstable : /dev/daXsY were created multiples times each and when I umounted a disk, it was re-mounted few seconds after. Some mount points appeared and disapeard. It was too confused.

So I decided to do a script that I launch in the command line (when I connect my disks I am aware of it (except if there is too much alcool in my blood) so I can launch the script myself...
The adavantages are that, depending on the number of arguments I can mount/umount a specifique disk-slice or a disk and all its slice or a label or everything it finds in /dev/daXsY (X in [0-9] and Y in [1-9]

So even if I connect my 4 disk on the same hub, I can easily select which one I really want to use!

The Label problem : my disks have no gpt or ufs label. The msdos one do not appear in /dev/msdos (or when there is something here, it's the wrong label (the one give by the vendor, not mine)).
Same thing for the ntfs ones. /dev/ntfs contains only my internal Windows partition and sometime the label of a disk that is already umounted....
So for ntfs I simply use "ntfslabel" that return the ... wait for it ... label! :e

Joint is my script, largely inspired from the one of WB! Of course we can easily improve it!

So now I just have to find out how to get this msdos Label!!
 

Attachments

  • automount.sh.txt
    5.6 KB · Views: 191
Hi,
I think that I understand a part of the "automatic devd" problem.
As I said all my slices appear 2 times in /dev/. When I mount it, one of the 2 "clones" disappears (+ for ntfs(-3g) the "mount" command returns "/dev/fuse0 /media/mointpoint"...).

When I umount it, it re-appears in /dev. So it's normal that each times I tried to umount a disk, the devd statement "CREATE" was triggered! Even more, the "DESTROY" statement was certainly triggered too at mount time (at least for msdosfs) leading to an infinite loop of mount process that only a reboot could kill (I couldn't even stop devd!)

Why do I have these clones in /dev/?
 
You must log in or register to reply here.
Back
Top