[résolu] pb démontage clef USB et noyau 2.6.19

Support Debian
#1

Bonsoir,

je suis en debian/sarge/2.6.19.2

Depuis que je suis passé en 2.6.19.2, je n’arrive plus à démonter normalement mes clefs usb :
montage et utilisation sans problème mais au démontage :

dès que ma clef est inséré, le process usb-storage se lance.
$ ps -ef|grep usb
root 1237 6 0 20:12 ? 00:00:00 [ksuspend_usbd]
root 4785 6 0 21:22 ? 00:00:00 [usb-storage]

Bon… résolu, c’est une façon de parler : de toute évidence, c’est le paquet gnome-volume-manager qui est la source de mes tracas.
Exit le-dit paquet, je préfère nettement le montage manuel pour ce genre de périférique.

D’ailleurs, mon fils, sans précaution en retirant une clef l’a faite passer de 128Mo à … 96Mo de capacité ( Devrait-on laisser les enfant utiliser linux ? :o\ )

Tiens, cela m’inspire un petit jeu :
Quel le bit d’adresse qui a été grillé ?

Merci à tous de votre aide
Marcel

#2

Si tu montes en console et sous root et si tu démontes sous root aussi, tu as le m^ problème ?

#3

et la clé ne se monte pas ailleurs sans que tu y ait fait attention ?
tu as fait un ‘lsof /media/usb_1er’ (genre) pour déterminer le processus qui bloque ?
tu as essayé un ‘eject /media/usb_1er’, à tous hasards ?

#4

oui, j’enfiche la clef, elle ne se monte pas seule.
Mais même réponse lors du mount / umount sous root.

#5

quand tu la démontes, tu es sûr qu’aucun autre soft soit concerné, m^ un gestionnaire de fichiers ?
avant de démonter, arrête ts les autres prog pour essai.

#6

/dev/sda1 /media/usb_1er vfat rw,user,noauto 0 0
essaie aussi de modifier ton fstab en le plaçant en dernière ligne et une fois à la fin de ligne, un retour chariot supplémentaire.
Si pas mieux, essaie de supprimer le 'vfat’
Si pas mieux, remplace ‘sda1’ par 'uba1’
Si pas mieux, cherche du côté de ‘fam’

#7

[quote=“mattotop”]et la clé ne se monte pas ailleurs sans que tu y ait fait attention ?
tu as fait un ‘lsof /media/usb_1er’ (genre) pour déterminer le processus qui bloque ?
tu as essayé un ‘eject /media/usb_1er’, à tous hasards ?[/quote]

Ah, bonne piste : $ lsof|grep /media/usb_1er
famd 3914 marcel 109r DIR 8,1 16384 152 /media/usb_1er/.Trash-marcel

Il suffit que je kill ce process famd pour pouvoir démonter ma clef…

famd dépend du paquet fam - File Alteration Monitor.
Bon… suffirait-il de supprimer le paquet fam ?
Le paquet fam ne peut être désintallé par apt, car le système veut désinstaller gnome et gnome-desktop-environnement du même coup (!)
Dpkg -r ne le fera pas non plus car gnome-desktop-environnement dépend de fam…
Hem… :ox
Côté configuration, il me semble que la commande famd devrait être lancée avec l’option -T 0 (histoire de time-out…).
D’ailleurs quand le fais un /etc/init.d/fam restart ça à l’air d’être ok…
Bon… je reboot pour voir comme sont les process au demarrage…

à suivre…
Marcel

#8

famd<->konqueror

moi qd j’ai ça, je fais “killall konqueror” ou j’évite konqueror (en konsole tu n’auras pas de pb)

Vérifie avec un top que tu n’as pas un konqueror zombie.

#9

[quote=“Bluenote”]famd<->konqueror

moi qd j’ai ça, je fais “killall konqueror” ou j’évite konqueror (en konsole tu n’auras pas de pb)

Vérifie avec un top que tu n’as pas un konqueror zombie.[/quote]

bon, ça m’a donné l’idée de voir comment ça se comporte côté KDE :

  • la clef se monte automatiquement dès que je “navigue” dessus. (je connais pas KDE donc je n’en sais pas plus)
    Le premier démontage se passe bien (que ce soit par le gestionnaire de disks ou par Konsole), mais, comme sous gnome, ça bloque dès la deuxième opération (j’entends pas là un premier démontage, où un écriture sur la clef.)
    J’ai noté au passage d’un environnement à l’autre que c’est bien un prog propre à l’utilisateur qui bloque, puisque clore la session X à le même effet qu’un restart de /etc/init.d/fam.
    Une autre chose m’intrigue : pourquoi est-ce l’utilisateur marcel (votre serviteur) et pas root qui lance ce daemon ???
    à suivre…
#10

[quote=“ricardo”]/dev/sda1 /media/usb_1er vfat rw,user,noauto 0 0
essaie aussi de modifier ton fstab en le plaçant en dernière ligne et une fois à la fin de ligne, un retour chariot supplémentaire.[/quote]
sans effet…

Euh… qu’elle en seraient les conséquences sur le format des fichiers sur la clef ? je m’en sert essentiellement pour tranferer des dossier vers un autre O$… :os

[quote]
Si pas mieux, cherche du côté de ‘fam’[/quote]
Curieux process : quand c’es tbloqué, je fais un /etc/init.d/fam restart
dès lors root apparaît dans le ps…
Puis dès que marcel (celui par qui le scandale arrive :o) mount une clef, il devient “propriétaire” du-dit process famd !! :

ps -ef|grep fam

root 6809 1 0 19:29 ? 00:00:00 /usr/sbin/famd -T 0
debian-station1:/home/marcel# ps -ef|grep fam
marcel 6809 1 0 19:29 ? 00:00:00 /usr/sbin/famd -T 0
…

#11

Bon… je crois que je progesse : j’ai créé un autre utilisateur lambda, et sous ce profil vierge de toute “bidouille”, le système se comporte normalement. (ouf !)

Donc pour résumer : si l’utilisateur marcel se logue et manipule des fichiers il bloque la clef usb (non seulement pour lui mais pour tous les utilisateurs (root compris)

Question, comment nettoyer les fichiers de config de cet utilisateur (un vrai bidouilleur qui avait personalisé son environnement gnome à donf avant ce changement de noyau…).

Sans doute y a-t-il une commande shell pouvant me dire quels fichiers propres à Marcel sont utilisés par fam.

encore merci de votre aide
à suivre…
Marcel (oui, j’ai honte ! :os)