un bon lien pour apprendre :
http://www.reactivated.net/udevrules.php
 
en résumé :
vous chopper les informations nécessaires pour faire vos règles via la commande :
udevinfo -a -p /sys/path/to/hardware/info
/sys/path/to/hardware/info est un chemin vers un fichier dev correspondant au matériel que vous voulez gérer
pour trouver la liste des rep :
find /sys -name dev
 
sinon y-a man udev qui donne aussi quelques infos supplémentaires
 
 
Mes règles :
les deux premieres sont pour ma clé usb
Les deux suivantes pour mon dd usb

dans ma debian sid j'ai mis ça dans /dev/udev/udev.rules en dessous de # SCSI block devices (il lit les règles une par une dans l'ordre façon iptables donc l'ordre est important)
 
voilà, avec ça je peux monter ma clé et mon dd sans me prendre la tete avec le nom du bordel
 
par contre si qq'un à une méthode pour monter automatiquement toutes les partitions présente sur un dd sans que j'ai à le faire manuellement, ça serait parfait

par contre il met 3 sec à créer les devices apres que j'ai branché le tout ... spa super rapide

content de voir que ça vous interesse    
vous avez pas des règles bien à vous ?

ben en fait, ya déjà pas grand monde qui utilise le 2.6... donc udev.........

 
oué mais y-en a quand même, et ils le disent pas
n'est ce pas 911 par exemple

ca sert a quoi udev
 
 
 
 
 
 
 
 
 
 
 
 
non j'deconne mais j'en ai pas l'utilite

--offline--
bon, je remet ce que je viens de poster dans le topic du kernel 2.6
--online--
pour les pingouins qui utilisent 2.6+udev+supermount et des périph mass-storage, j'ai pondu ça :

 
faut l'appeler updfstab et le placer dans /usr/sbin (et le rendre exécutable bien sûr). pour l'explication de l'idée de base : https://linuxfr.org/~ccomb/8866.html
 
si jamais vous testez et que vous voyez un bug, ça serait sympa de me le dire
 
@+
 
--edit--
au fait, merci udok pour la doc udev
 
--re-edit--
un pote vien de passer : ça marche avec sa première clé usb, mais pas avec la seconde, qui n'a pas de serial!!!! chuis vert là!  
 
--re-re-edit--
correction du bug précédent. j'ai ajouté la détection du idVendor (obligatoire, sinon hotplug peut pas trouver le périph). le seul problème, c'est si plusieurs périph sont branchés en même temps avec le même vendorId. @+

aller hop, au boulot, faut corriger ça

Pour mon imprimante:  
BUS="usb",   SYSFS{serial}="0NJ220110251043020",  NAME="usblp0"
 
Pour mon stick "lexar":
BUS="usb", SYSFS{product}="JUMPDRIVE PRO       ", KERNEL="sd?1",  NAME="%k",  SYMLINK="lexar"
 
Pour mon diske usb2 archos:
BUS="usb", SYSFS{product}="ARCHOS USB2.0 (P4a)",  KERNEL="sd?1",  NAME="%k",  SYMLINK="archos"

bon, comme tout le monde l'aura remarqué, vu que tout le monde est spécialiste en script bash ( ), il y avait deux erreurs dans la deuxième version, d'où re-edit

 
Une 'erreur' peu grave: peripherique inconnu, en anglais c'est Unknown Device.
 
sinon

 
Ridicule, et a plusieurs termes:
1 si plusieurs disques sont marques inconnues tu va avoir un soucis, ils auront tous le meme dev et le meme point de montage.
2 en bash quand on veut pas ce casser la tete on ecrit

voire:

 
Et enfin, pour chaque peripherique trouvé tu fait un 'umount -a' ce qui n'est pas du plus bel effet et meme completement inutile vu que tu a rajouter un ligne dans le fstab elle ne peut pas etre utilisée.
un simple 'mount /mnt/$product' ou un 'mount -a' A LA FIN du script , pas pour chaque occurence.
 
M'enfin ce que j'en dit moi hein

ca m'a l'air bien chiant pour pas grand chose

 
ce que t'en dis, tu as raison, par contre le "ridicule", tu peux te le garder!    
 
non mais oh! mon script est pas parfait, je sais bien, et les problèmes que tu soulèves je les connais déjà. il n'empêche que c'est un truc vite fait que je mets la paske udok me l'a demandé. alors plutôt que de faire la fine gueule, tu corriges les erreurs et en fait profiter le monde!
 
sur ce, je vous souhaite le bonsoir!  

re! est-ce que quelqu'un saurait comment lancer un script juste après que le symlink soit créé dans les règles udev? j'ai essayé en ajoutant une directive PROGRAM="monScript", mais toutes les directives s'exécutent en même temps, et le symlink n'existe pas au moment où le script est lancé!
 
si vous avez une idée

 
peut-être en créant le lien dans le script/program ?

vouaip, j'étais en train d'y penser, mais je trouve ça dommage. le mécanisme de création de lien est intégré à udev, alors pourquoi pas l'appel d'un script?
 
la doc de udev, pour le moment, n'est pas très fournie quand même!!

c'est encore en cours de devel
mais avec le lien dans le premier post, t'as déjà pas mal d'indication

ben pour faire des trucs simples ouais, mais pour des plus compliqués (montage/démontage des clé usb sans utiliser supermount, exécution de code à l'insertion/suppression).
 
en plus, y'a quand même un truc vachement bizarre je trouve. dans hotplug (dont a besoin udev), pour toute les catégories (scsi, pci, firewire) y'a des évènments add et remove, sauf l'usb qui n'a que le remove! c'est pas très pratique! ;(
 
--edit--
enfin, c'est pas pour critiquer les dev que je dis ça. Par contre, je trouve que dans son état actuel, on peut faire moins de choses automatisées avec un 2.6+udev qu'avec un 2.4+devfs

postes tes remarques sur la mailing list, elle est là pour ça

ouaip, pas bête. je vais le faire dès que j'ai 5 minutes

dans la version 0.23, ils ont intégré un mecanisme qui fait que lorsqu'un noeud est créé, si un fichier du type nomDuNoeud.dev se trouve au bon endroit, il peut capter les évènements de type add/remove device! super cool pour le montage/démontage auto des device!
 
vivement que la version debian sid passe en 0.23!

 
ah ouai, y-a plus besoin de supermount du coup si ?    
faut juste faire le montage avec l'option -sync ?  

ben là déjà, j'ai modifié le script que j'ai mis plus haut pour qu'il monte les devices déclarées mais non montées, et qu'il démonte celles qui sont montées mais qui n'existent plus dans /dev
 
ça marche pas trop mal. encore un tit bug et ça roule. je suis obligé de faire ça, car monté avec supermount, mon dd usb2 plante lors de gros transferts!!
 
sinon, oui, il faut monter les périph en sync

plus besoin de supermount, ça c'est le bonheur
par contre le périph doit encore être présent quand on démonte non ? donc sur un évt remove, comment faut faire ?

ben non, le périph a pas besoin d'être là quand tu démontes!
 
genre, ce que je fais, c'est de voir si un périph monté n'est pas présent dans /dev, et si c le cas, je le démonte
 
est-ce que tu saurais comment, à partir du chemin complet d'un lien symbolique, on peut avoir le chemin complet de sa cible? j'ai essayé rapidos différents trucs, mais rien de vraiment bien.
 
je te filerais le script ce soir si ça t'intéresse
 
sinon, pour les évènements, ils faut la version 0.23. je te fillerais la méthode que m'a donné  le developpeur

ok
 

à part ls -l je vois pas

non    
 

oui  

voici mes régles:

 
la règle de la webcam ne marche pas (reconnu comme v4l/video0)

[citation]
de greg k-h :
if you want to catch the fact when udev removes a /dev node (which
> >odds are is what you really want to catch), put your script, or a link
> >to it in /etc/dev.d/block/ with the extension .dev and you will get both
> >add and remove events that corrisponded to a udev create or remove
> >device node
[/citation]
 
voilà c simple non? si tu arrive à faire quelquechose, fais péter ton code (moi, je vais virer celui que j'ai mis plus haut, il est pas très bon)

bah j'attends le 0.23 avant de tenter quoique ce soit
il est pas encore dans deb

ah bah si, il est dans incoming

respect...
Dire que je me suis cassé la tête avec supermount ....

supermount, c'est bien pour les cdroms, sinon, ça fout la merde! pis j'aime pas ce comportement bizarre. c'est jamais vraiment monté ou démonté, c'est entre les deux...
 
par contre, les développements actuels de hotplug/udev ont l'air bien sympa (d'ailleurs, je me demande si en émulant les cdroms en scsi, on a pas moyen de récupérer l'ouverture /fermeture du tiroir du mange disque)

ayé la version 023 est dans SID!!!
 
bon par contre, je comprends pas comment marche le truc du /etc/dev.d/block
un lien ici : http://www.kernel.org/pub/linux/ut [...] /RFC-dev.d
 
mais comprends pas!

 
cette doc est dans /usr/share/doc/udev
j'ai essayé pendant une bonne heure de faire marcher le bordel, mais ça veut pas
ce que j'ai compris de la doc, c'est qu'il fallait créer un repertoire dans /etc/dev.d qui porte le nom du block ou lien créé dans /dev et y mettre des exécutable avec l'extension .dev
alors j'ai fait ça avec pour contenu :

 
dans un repertoire nommé SDA1 (j'ai aussi essayé sda, SDA et sda1), mais ça fait rien
bon là c'est pas terrible comme script mais ça devrait au moins faire qq'chose  

je précise que ce script fait qqchose quand je le mets dans /etc/dev.d/defaults mais c'est pas comme ça qu'il faut faire et d'ailleurs le comportement est pas terrible
 
donc c'est une histoire de répertoire que j'ai mal crée ... ou alors un bug peut-être
 
 
 
 
 
 
par contre maintenant on peut utiliser le flag RESULT apres PROGRAM dans les règles et il doit y avoir moyen de faire des trucs bien puissant de manière plus simple qu'avant, c'est bien  

chais pas, pour l'instant, j'arrive à rien. en tous cas, c'est normal que defaults marche, c'est son nom qui l'indique!

 
oui je sais bien, c'était juste pour souligner que c'était bien un pb avec mes répertoires dans /etc/dev.d et pas avec mon script

http://marc.theaimsgroup.com/?l=li [...] 113339&w=2
on dirait moi, même question que je me pose, quazi même kernel et tout  

ouais, c'est bon... tout le monde utilises des pseudos, alors hein bon!
 
en attendant, si tu avais suivi la discussion, tu saurais que ça marche (enfin maintenant). j'arrive à choper les add/remove.
 
par contre, si tu mets un script sda1.dev, il chope tous les évènements add/remove, pas seulement ceux de sda1. Faut que je vois si c'est normal ou pas.
 
en attendant, si ça t'intéresse, tu ferais bien de t'inscrire sur la liste!

c'est toi ?    
 

mais je la suis la liste, mais j'ai pas fait que ça toute l'apres midi donc j'avais pas encore vu le résultat