[Toulibre] clé USB sarge

Gaël UTARD gael.utard at laposte.net
Sam 4 Fév 23:08:33 CET 2006


Bonsoir,

Le Samedi 4 Février 2006 14:48, Kevin Rowanet a écrit :
> dans une école primaire où j'ai installé un réseau sarge avec des TX,
> j'ai des problèmes pour lire des clés USB sur sarge 2.6, upgradée
> récemment.

J'ai un peu regardé le problème avec une Debian sid (KDE 3.5). Ce que je vais 
dire n'est donc peut-être pas totalement vrai avec une sarge.

>   * sous KDE, j'ai défini une icone pour un user : lorsqu'il clique sur
> l'icône, la clé se monte, ie /dev/sda1 se monte sur /media/cleUSB.

Qu'est-ce que tu entends par définir une icône ? Tu as créé une entrée 
dans /etc/fstab, puis tu as créé une icône KDE qui pointe sur cette entrée ?

> Il est arrivé que la clé ne puisse pas se monter parce que /dev/sda1
> n'existait pas au moment du montage (ni non plus /dev/sda), alors que
> 2mn plus tôt elle montait parfaitement ; je suppose qu'il s'agit de la
> création dynamique des périphériques par udev ? 

Non, ça n'a pas de rapport avec udev. C'est le noyau qui crée et supprime 
dynamiquement les périphériques. udev se contente de créer et de supprimer 
les entrées correspondantes dans /dev.

/dev/sda correspond au périphérique entier et /dev/sda1 à la première 
partition d'un périphérique partionné. A priori on se trouve généralement 
dans le deuxième cas, mais c'est pas possible à déterminer avec certitude à 
priori. Ça dépend de la manière dont la clé a été (ou pas) partitionnée

Plus grave, si tu mets deux clés USB en même temps, elles ne vont pas 
s'appeler toutes les deux /dev/sda1. Pourtant, tu voudrais les gérer toutes 
les deux. Certes, on peut rajouter /dev/sdb1 à /etc/fstab, mais où 
s'arrêter ? À /dev/sdc1 ? À /dev/sdd1 ? Et puis il faut créer autant d'icônes 
sur le bureau KDE. Mais l'utilisateur, comment il sait sur quel icône 
cliquer ?

Quant au cas de la clé qui marchait pourtant bien avant, si on enlève la clé 
et qu'on la remet tout de suite, on peut supposer que sda n'est pas supprimé 
suffisamment tôt pour pouvoir être réutiliser. De toute façon peut importe, 
le noyau appelle les périphériques comme bon lui semble.

> Ce qui voudrait dire que lorsque udev crée un périphérique, il peut le
> détruire ensuite ? 

Tout à fait. Avec udev, le /dev ne contienne que ce qui existe réellement à 
l'instant présent. Donc si une clé USB disparait, comme le noyau ne la gère 
plus, il demande à udev de la supprimer de /dev.

> On m'a proposé d'utiliser pmount. 

Comme dit précédemment, il n'est pas possible de mettre dans /etc/fstab ce qui 
concerne les clés USB. Donc il faut le supprimer. Conséquence: il n'est plus 
possible de monter les clés USB sans être root. C'est là que pmount vient à 
la rescousse. Avec lui, il n'est plus nécessaire d'être root. Il "suffit" 
d'être membre de plugdev. Il est donc évidemment nécessaire d'ajouter les 
utilisateurs ayant besoin de lire des clés USB au group plugdev. 
L'utilisation de pmount est très simple: "pmount /dev/bidule" 
monte /dev/bidule dans /media/bidule. Mais il n'y a pas besoin de savoir 
l'utiliser, KDE se charge de l'appeler automatiquement quand il en a besoin.

> On m'a proposé aussi de désactiver hal ; quelles conséquences ?

pmount ne devine pas quel périphérique doit être monté. C'est le rôle d'HAL 
d'informer KDE de l'existence des clés USB (et du périphérique qui 
correspond). Une fois que KDE est informé, il affiche automatiquement une 
icône sur le bureau (et avec l'URL "media:/" dans konqueror). Et lorsqu'on 
clique sur l'icône, KDE appelle pmount pour faire le montage. Si tu 
désactives HAL, les icônes des clés USB ne sont plus créées/supprimées 
automatiquement. Je ne vois donc pas en quoi désactiver HAL résoud le 
problème. Ça a plutôt tendance à l'aggraver.

> * j'ai eu aussi un problème avec une clé que j'ai montée, lue, sur
> laquelle j'ai écrit sans problème. Puis après l'avoir rebranchée, elle
> ne clignotait même plus. Dans le dmesg, j'ai vu passer "kobject register
> failed for sda1 (-17)".

Peut-être un bug du noyau. Ça s'est produit avec quelle version du noyau ? 
Après reboot de la machine, ça ne marchait toujours pas ?

> * sur la même machine, je n'ai pas pu lire une clé, qui, après vérifs,
> fonctionne bien sous windows. On m'a parlé de verrouillage possible par
> soft Windows...

J'ai déjà vu une clé avec deux partitions: la première, non protégée, contient 
le soft pour pouvoir lire la deuxième. Donc sous linux, on peut quand même 
lire la première.

> Les problèmes peuvent-ils avoir un rapport avec uhci et ehci ?

Une clé USB2 fonctionne-t-elle forcément sur un port USB1 ? Je n'en sais rien.

> Comment trace-t-on ce genre de problème ?
> Je suppose qu'il faut au moins distinguer la phase "reconnaissance de la
> clé par le bus usb" et la phase "reconnaissance du filesystem de la clé" ?

Oui, en passant par les phases reconnaissance de la clé comme périphérique de 
stockage et de reconnaissance du partitionnement. Tu peux regarder dmesg pour 
voir si la clé est reconnue, /proc/partitions pour voir si elle est 
partitionnée. Tu peux essayer de la monter en NTFS (sait-on jamais).

Le test sous windows a-t-il eu lieu sur une autre machine que celle du 
propriétaire de la clé ? Ce dernier a-t-il installé un soft particulier ? 
A-t-il effectué des opérations particulières (partitionnement, formatage). 
Quel est la marque de la clé ? Son modèle ?

> Merci.

De rien

Gaël



Plus d'informations sur la liste de diffusion Toulouse-ll