Grâce qu ng, j'ai (presque) résolu mon problème de Clé USB qui ne
voulait pas se mounter.
(Je poste la solution du problème dès que j'ai pigé comment faire un
diff entre le fichier de config du noyau qui ne fonctionne pas et celui
qui fonctionne).
Le problème actuel est que selon /ect/fstab, la CléUSB est reconnue
comme /dev/sda1 et l'APN est reconnu comme /dev/sdb1.
Mais cela necessite que je branche la clé USB avant l'APN.
Je cherche donc la meilleure solution d'automontage.
J'ai entendu parlé (en gogolisant les archive du ng) de autofs et de
udev. Mais quelques questions demeurent:
* Sont-ils complémentaires ?
* Si non, lequel est-il censés être maintenu dans l'avenir ?
Merci de votre aide
--
Hugo NPN (i --> ee)
Je dirais plutot qu'il y a des limites a l'allegeance et a l'abandon
et que les invocations a outrance du realisme de devraient pas se
faire a sens unique. (JK in fcold -+- Es-tu X ? -+-)
On Mon, 18 Oct 2004 20:21:10 +0200, Hugolino wrote:
Le Wed, 29 Sep 2004 23:10:38 +0200, no_spam a écrit:
On Wed, 29 Sep 2004 12:29:29 +0200, Xavier Maillard wrote:
La construction du SYSFS_vendor permet de dire que l'on veut prendre le paramètre vendor du périphérique comme identifiant de notre clé. Ensuite udev va se charger à chaque fois qu'il le détectera, de changer une entrée /dev/sd<qqchose> en /dev/usbkey1 (dans le cas d'une seule clé). udev s'occupera également de supprimer /dev/usbkey1 lorsque le périphérique aura été débranché.
Utiliser les strings "Vendor" et "Product" n'est pas vraiment une idée géniale pour identifier un périphérique USB: il faut savoir que les chaines de description sont optionnelles et libres en USB. Ce qui fait qu'elles sont parfois vide, parfois rempli avec n'importe quoi et il n'est pas rare qu'elles changent entre 2 releases de firmware. De plus, un constructeur vend souvent plus d'un périphérique USB, de types complètement différent. Il faut utiliser les attributs DeviceClass, DeviceProtocol et DeviceSubclass (comme défini dans la norme USB) pour repérer les périphériques génériques (hubs, storages, ...) (voire les classes/protocoles/sous-classes des interfaces, mais c'est plus compliqué et plus rare) et utiliser les VendorID, ProductID et revisionID numériques pour les autres. C'est la seule méthode réellement fiable d'identification, pour l'USB au moins.
Comment obtenir les attributs DeviceClass, DeviceProtocol et DeviceSubclass ?
La commande systool utilisée avec l'option -v (Show all attributes with values) ne donne pas ces paramètres...
Chez moi, en faisant systool -v -b usb j'obtiens les attributs: idVendor idProduct bcdDevice qui correspondent aux VendorID, ProductID et Device de la norme USB et bDeviceClass bDeviceSubClass bDeviceProtocol pour les classes USB des devices. Ainsi que: bInterfaceClass bInterfaceSubClass bInterfaceProtocol pour les classes des interfaces des devices USB.
Les classes les plus utilisées sont: 0x0 => se référer à la classe de l'interface (utilisée pour les devices bluetooth et wifi) 0x1 => classe audio 0x2 => classe communication 0x3 => classe "human interface devices" (clavier, souris, ...) 0x6 => classe "still image" (APN) 0x7 => classe imprimante 0x8 => classe storage 0x9 => classe hub 0xe => classe vidéo
A noter que les classes/sous-classes/protocoles 0xFF veut dire que c'est une implémentation propriétaire et qu'il faut donc se référer aux ID du device.
On Mon, 18 Oct 2004 20:21:10 +0200, Hugolino wrote:
Le Wed, 29 Sep 2004 23:10:38 +0200, no_spam a écrit:
On Wed, 29 Sep 2004 12:29:29 +0200, Xavier Maillard wrote:
La construction du SYSFS_vendor permet de dire que l'on veut
prendre le paramètre vendor du périphérique comme identifiant de
notre clé. Ensuite udev va se charger à chaque fois qu'il le
détectera, de changer une entrée /dev/sd<qqchose> en /dev/usbkey1
(dans le cas d'une seule clé). udev s'occupera également de
supprimer /dev/usbkey1 lorsque le périphérique aura été débranché.
Utiliser les strings "Vendor" et "Product" n'est pas vraiment une idée
géniale pour identifier un périphérique USB: il faut savoir que les
chaines de description sont optionnelles et libres en USB. Ce qui fait
qu'elles sont parfois vide, parfois rempli avec n'importe quoi et il n'est
pas rare qu'elles changent entre 2 releases de firmware. De plus, un
constructeur vend souvent plus d'un périphérique USB, de types
complètement différent.
Il faut utiliser les attributs DeviceClass, DeviceProtocol et
DeviceSubclass (comme défini dans la norme USB) pour repérer les
périphériques génériques (hubs, storages, ...) (voire les
classes/protocoles/sous-classes des interfaces, mais c'est plus compliqué
et plus rare) et utiliser les VendorID, ProductID et revisionID
numériques pour les autres. C'est la seule méthode réellement fiable
d'identification, pour l'USB au moins.
Comment obtenir les attributs DeviceClass, DeviceProtocol et
DeviceSubclass ?
La commande systool utilisée avec l'option -v (Show all attributes with
values) ne donne pas ces paramètres...
Chez moi, en faisant systool -v -b usb
j'obtiens les attributs:
idVendor
idProduct
bcdDevice
qui correspondent aux VendorID, ProductID et Device de la norme USB
et
bDeviceClass
bDeviceSubClass
bDeviceProtocol
pour les classes USB des devices.
Ainsi que:
bInterfaceClass
bInterfaceSubClass
bInterfaceProtocol
pour les classes des interfaces des devices USB.
Les classes les plus utilisées sont:
0x0 => se référer à la classe de l'interface (utilisée pour les
devices bluetooth et wifi)
0x1 => classe audio
0x2 => classe communication
0x3 => classe "human interface devices" (clavier, souris, ...)
0x6 => classe "still image" (APN)
0x7 => classe imprimante
0x8 => classe storage
0x9 => classe hub
0xe => classe vidéo
A noter que les classes/sous-classes/protocoles 0xFF veut dire que c'est
une implémentation propriétaire et qu'il faut donc se référer aux ID
du device.
On Mon, 18 Oct 2004 20:21:10 +0200, Hugolino wrote:
Le Wed, 29 Sep 2004 23:10:38 +0200, no_spam a écrit:
On Wed, 29 Sep 2004 12:29:29 +0200, Xavier Maillard wrote:
La construction du SYSFS_vendor permet de dire que l'on veut prendre le paramètre vendor du périphérique comme identifiant de notre clé. Ensuite udev va se charger à chaque fois qu'il le détectera, de changer une entrée /dev/sd<qqchose> en /dev/usbkey1 (dans le cas d'une seule clé). udev s'occupera également de supprimer /dev/usbkey1 lorsque le périphérique aura été débranché.
Utiliser les strings "Vendor" et "Product" n'est pas vraiment une idée géniale pour identifier un périphérique USB: il faut savoir que les chaines de description sont optionnelles et libres en USB. Ce qui fait qu'elles sont parfois vide, parfois rempli avec n'importe quoi et il n'est pas rare qu'elles changent entre 2 releases de firmware. De plus, un constructeur vend souvent plus d'un périphérique USB, de types complètement différent. Il faut utiliser les attributs DeviceClass, DeviceProtocol et DeviceSubclass (comme défini dans la norme USB) pour repérer les périphériques génériques (hubs, storages, ...) (voire les classes/protocoles/sous-classes des interfaces, mais c'est plus compliqué et plus rare) et utiliser les VendorID, ProductID et revisionID numériques pour les autres. C'est la seule méthode réellement fiable d'identification, pour l'USB au moins.
Comment obtenir les attributs DeviceClass, DeviceProtocol et DeviceSubclass ?
La commande systool utilisée avec l'option -v (Show all attributes with values) ne donne pas ces paramètres...
Chez moi, en faisant systool -v -b usb j'obtiens les attributs: idVendor idProduct bcdDevice qui correspondent aux VendorID, ProductID et Device de la norme USB et bDeviceClass bDeviceSubClass bDeviceProtocol pour les classes USB des devices. Ainsi que: bInterfaceClass bInterfaceSubClass bInterfaceProtocol pour les classes des interfaces des devices USB.
Les classes les plus utilisées sont: 0x0 => se référer à la classe de l'interface (utilisée pour les devices bluetooth et wifi) 0x1 => classe audio 0x2 => classe communication 0x3 => classe "human interface devices" (clavier, souris, ...) 0x6 => classe "still image" (APN) 0x7 => classe imprimante 0x8 => classe storage 0x9 => classe hub 0xe => classe vidéo
A noter que les classes/sous-classes/protocoles 0xFF veut dire que c'est une implémentation propriétaire et qu'il faut donc se référer aux ID du device.
Hugolino
Le Tue, 19 Oct 2004 06:30:28 +0200, no_spam a écrit:
Chez moi, en faisant systool -v -b usb [snip]
Merci de ta réponse
Je vais tacher de mettre à profit les vacances pour écrire ma petite doc sur udev.
-- Hugo NPN (i --> ee) Passe que moi, au départ, j'avais fait informatique comme études, pas NT, et je voudrais revenir à mon métier premier. -+- BB in Guide du Linuxien pervers - Bien configurer son métier. -+-
Le Tue, 19 Oct 2004 06:30:28 +0200, no_spam a écrit:
Chez moi, en faisant systool -v -b usb
[snip]
Merci de ta réponse
Je vais tacher de mettre à profit les vacances pour écrire ma petite doc
sur udev.
--
Hugo NPN (i --> ee)
Passe que moi, au départ, j'avais fait informatique comme études, pas NT,
et je voudrais revenir à mon métier premier.
-+- BB in Guide du Linuxien pervers - Bien configurer son métier. -+-
Le Tue, 19 Oct 2004 06:30:28 +0200, no_spam a écrit:
Chez moi, en faisant systool -v -b usb [snip]
Merci de ta réponse
Je vais tacher de mettre à profit les vacances pour écrire ma petite doc sur udev.
-- Hugo NPN (i --> ee) Passe que moi, au départ, j'avais fait informatique comme études, pas NT, et je voudrais revenir à mon métier premier. -+- BB in Guide du Linuxien pervers - Bien configurer son métier. -+-
