[thunar-volman] Type de périphérique USB non supp.. (résolu)

[LuX]

Bonjour,

depuis quelques temps (peut-être assez longtemps, j'en utilise rarement) mes clés USB ne sont plus montées automatiquement par Thunar ou pcmanfm. Je peux seulement les monter à la main (commande 'mount') en tant que root.

Si je lance Thunar en console, au branchement de la clé USB le message suivant s'affiche dans le terminal (sous wmii, pas sous xfce... allez donc savoir pourquoi) :

Code : Tout sélectionner

$ thunar-volman: Type de périphérique USB non supporté.
thunar-volman: Type de périphérique USB non supporté.

La commande 'tail /var/log/messages.log' juste après le branchement me dit ça, qui n'a pas l'air d'être franchement inquietant :

Code : Tout sélectionner

Jan 24 21:51:40 mercure kernel: usb 1-2: new full speed USB device using ohci_hcd and address 9
Jan 24 21:51:40 mercure kernel: scsi9 : usb-storage 1-2:1.0
Jan 24 21:51:41 mercure kernel: scsi 9:0:0:0: Direct-Access                               0.00 PQ: 0 ANSI: 2
Jan 24 21:51:41 mercure kernel: sd 9:0:0:0: Attached scsi generic sg2 type 0
Jan 24 21:51:41 mercure kernel: sd 9:0:0:0: [sdb] 31588352 512-byte logical blocks: (16.1 GB/15.0 GiB)
Jan 24 21:51:41 mercure kernel: sd 9:0:0:0: [sdb] Write Protect is off
Jan 24 21:51:41 mercure kernel: sdb:
Jan 24 21:51:41 mercure kernel: sd 9:0:0:0: [sdb] Attached SCSI removable disk

J'ai vu (merci Google) le même message d'erreur de thunar-volman rapporté sur ce forum : http://forums.archlinux.fr/viewtopic.php?t=7365&p=60857

Malheureusement la solution qui semble marcher là-bas ne donne rien pour moi. Pour la mettre en oeuvre, comme j'utilise lxdm qui ignore sauvagement les .xinitrc, j'ai modifié mon /etc/lxdm/Xsession tout à la fin comme suit, ce qui normalement doit faire démarrer le wm avec dbus-session et ck-launch-session comme indiqué dans l'autre discussion :

Code : Tout sélectionner

# tail -4 /etc/lxdm/Xsession
# 	exec -l $SHELL -c "$CK_XINIT_SESSION \"$LXSESSION\""
exec dbus-launch ck-launch-session wmii
fi

Résultat : aucun changement.

Est-ce que quelqu'un pourrait suggérer quelque chose de pas trop décourageant pour le béotien que je suis ?

Merci d'avance,
LuX.

PS : Il est possible que ce problème soit apparu depuis le changement de mon gestionnaire de connexion. Avant j'utilisais slim, mais depuis une certaine mise à jour il y a un mois ou deux slim ne fonctionne plus chez moi et je suis passé à lxdm. En tout cas je ne peux pas dire depuis combtien de temps j'ai ce problème : je pense que je n'avais plus utilisé de clé USB depuis cet été.

[chipster]

Tu fais parti du groupe storage ?

[tuxce]

Salut, juste au cas où, est ce que t'utilises [testing] ?

Si c'est pas le cas, est ce qu'un lancement avec:

Code : Tout sélectionner

dbus-launch thunar

fonctionne (si jamais tu ne le lances pas en daemon)

Sinon, est ce que:

Code : Tout sélectionner

ck-list-sessions

te sort entre autre:

Code : Tout sélectionner

	active = TRUE
	is-local = TRUE

[LuX]

Bonjour !

Merci pour vos réponses.

@ chipster : Non, je ne faisais pas partie du groupe storage. Je m'y suis ajouté, sans changement visible.

@ tuxce : Je n'utilise pas [testing]. Les commandes 'thunar' et 'dbus-launch tunar' semblent donner le même résultat pour moi (pour root, voir ci-après). Quant à ck-list-sessions, la réponse est "oui et non" :

Code : Tout sélectionner

$ ck-list-sessions
Session1:
	unix-user = '1114'
	realname = '(null)'
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ':0'
	x11-display-device = '/dev/tty7'
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2011-01-29T20:28:28.179195Z'
	login-session-id = ''
Session2:
	unix-user = '1114'
	realname = '(null)'
	seat = 'Seat1'
	session-type = ''
	active = FALSE
	x11-display = ':0'
	x11-display-device = '/dev/tty7'
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2011-01-29T20:28:29.274004Z'
	login-session-id = ''

J'ai aussi essayé de lancer thunar en root pour voir (après un 'su' dans un terminal, commande 'thunar'). Toujours pas de montage automatique de la clé USB, mais le message d'erreur est différent :

Code : Tout sélectionner

# thunar &
[1] 6828
# thunar-volman: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken..
thunar-volman: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken..
thunar-volman: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken..
thunar-volman: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken..

Ce message-là semble en fait lié à dbus-launch puisque la commande 'dbus-launch thunar' lancée de la même manière (dans un ternimal après un 'su') ne produit aucun message d'erreur. Au branchement de la clé je retrouve juste le message habituel :

Code : Tout sélectionner

# dbus-launch thunar &
[1] 10111
# thunar-volman: Type de périphérique USB non supporté.
thunar-volman: Type de périphérique USB non supporté.
thunar-volman: Type de périphérique bloc inconnu.

---EDIT---
Ayant vu ailleurs sur ce forum un message à propos de périphériques USB qui ne se montaient pas, j'ai aussi essayé pour voir :

Code : Tout sélectionner

# /etc/rc.d/hal start
:: Starting Hardware Abstraction Layer                                              [DONE]

Mais ça n'a rien changé non plus.

Je ne me sens pas très avancé. Et vous ?

LuX.

[GuilouV]

Salut,

Comme tu l'as noté au début, un sujet similaire est sur le forum (viewtopic.php?t=7365&p=60857) et j'en suis à l'origine. Je me permets donc de te faire part de mon expérience :

1/ Pour résumer les manip qui ont résolu le problème chez moi :
- assure toi d'avoir bien modifié ton /etc/lxdm/Xsession (comme tu l'as fait visiblement)
- bien entendu tu dois avoir dbus en démon dans /etc/rc.conf
- n'oublie pas d'avoir gvfs installé (dépendance optionnelle mais nécessaire pour la reconnaissance des périphériques depuis thunar 1.2.0.1)

Après tout celà le lancement de thunar par la commande "thunar" et non "dbus-launch thunar" devrait fonctionner.

2/ Si la première manipulation ne fonctionne pas supprimer thunar et thunar-volman puis les réinstaller pourrait résoudre ton souci. Je te dis ça car au cours de mes péripéties thunar a un moment donné perdu la capacité de détecter les périphériques amovibles puis cette manipulation a remis les choses en place.

Désolé de ne pas apporter de solution miracle mais assure toi de remplir toutes les conditions du 1/ et sinon tente le 2/ ça ne coûte rien et perso ça m'a aidé

Soit dit en passant si je lance thunar dans un terminal j'ai toujours

Code : Tout sélectionner

thunar-volman: Type de périphérique USB non supporté.

Et pourtant le montage et démontage auto se passent bien

[LuX]

Merci beaucoup, GuilouV

J'ai installé gvfs sans que ça change rien sur le moment, mais une fois désinstallé et ré-installé thunar, le montage des clés USB par thunar-volman fonctionne de nouveau (avec pour moi aussi le message d'erreur qui continue bizarrement d'apparaitre).

À dire vrai, comme désinstaller thunar nécessite de désinstaller avant thunar-volman (et xfdesktop) je soupçonne que la désinstallation/réinstallation de thunar-volman suffit.

Comme je ne sais pas à quoi sert exactement ck-launch-session, mais que je crois qu'initialement il me servait justement à faire marcher thunar-volman dans wmii, je l'ai supprimé de la ligne de démarrage et ça marche aussi bien. En résumé, au cas où ça puisse servir à quelqu'un, je récapitule à mon tour les étapes :

1) Installer gvfs
2) désinstaller et ré-installer thunar (ainsi que thunar-volman)
3.a) avec un environnement de bureau comme xfce, c'est tout
3.b) avec un gestionnaire de fenêtre comme wmii démarré via une commande dans ~/.xinitrc, remplacer la ligne "wmii" par "dbus-launch wmii"
3.c) avec wmii démarré via lxdm, dans le fichier /etc/lxdm/Xsession juste avant la ligne (tout à la fin) :

Code : Tout sélectionner

exec -l $SHELL -c "$CK_XINIT_SESSION \"$LXSESSION\""

ajouter la condition :

Code : Tout sélectionner

# Condition rajoutee par moi pour wmii
     if [ "$LXSESSION" == "wmii" ]; then
     	CK_XINIT_SESSION="dbus-launch"
     fi

Je vais de ce pas modifier en conséquence le titre de la discussion en [resolu].

[GuilouV]

Content d'avoir pu aider.

Pour info, ck-launch-session fait appel à consolekit et permet de gérer les paramètres de session et l'auto-montage des périphériques amovibles. Il était utile lorsque ces tâches étaient sous la dépendance de Hal, maintenant l'emploi de dbus rend une fois de plus Hal obsolète (mais pas inutile pour d'autres fonctions).

[tuxce]

ck-launch-session ne gère pas l'automontage, il ne fait que spécifier des variables selon la session, polkit se sert ensuite de ces valeurs pour donner ou non une autorisation. consolekit ne se substitue pas à un gestionnaire de session, il faut toujours le lancer, certains gestionnaires tel gdm le lance tout seul.

[GuilouV]

Voilà qui est bien formulé et qui confirme mes dires puisqu'effectivement :

- je n'ai pas dit que consolekit se substituait à un gestionnaire de session
- ck-launch-session ne gère pas directement l'auto-montage mais permet de le gérer en étant initiateur de ce procédé

[tuxce]

euh, avant de modifier ton message, tu parlais de substitution avec pour exemple slim ! (ou alors, faut que je me repose ...)
sinon, c'est pas pour insister, mais il n'initie ni ne gère le montage, ck ne sait pas ce qu'est une partition un montage etc..., tout ce qu'il sait, c'est ce qui est listé dans "ck-list-sessions", on peut très bien s'en passer en indiquant à polkit de ne pas tenir compte de l'état local/actif de la session (ce que font les fichiers fournis par le packageur de xfce-session) et ce n'est pas dbus qui rend hal obsolète ou le remplace mais udisks et upower (et les prochains u* à venir)

[GuilouV]

Bon de toute façon LuX a trouvé une solution à son problème et c'est bien ça l'essentiel.

Pour le reste je ne juge personne et je peux me tromper mais pour être clair je dirai simplement que je n'aime pas les mauvaises ambiances infertiles suscitées par des querelles de supériorité et je ne cherche pas à avoir raison ou à prétendre posséder le savoir divin, j'essaie juste de contribuer avec ma petite expérience (bien loin de la tienne visiblement).

[tuxce]

C'est vrai que corriger une erreur, c'est juger et mettre une mauvaise ambiance, dommage...

[GuilouV]

C'était pour éviter que tu prennes la mouche que je précisais "je peux me tromper". Pas toujours évident de saisir les intentions à l'écrit. En tout cas nous voilà rassuré sur nos intentions respectives.

Allez bisous?

PS : petit troll... ces connaissances c'est perso ou lié à ton boulot? (parce que chapeau !)
C'est d'ailleurs pour ça que je fais parfois quelque erreurs que je suis ravi que tu corriges, j'aime apprendre.

[LuX]

Bonjour à tous !

tuxce : euh, avant de modifier ton message, tu parlais de substitution avec pour exemple slim ! (ou alors, faut que je me repose ...)

Je faisais allusion dans mon premier post à un autre problème que j'ai, en effet, depuis un certain temps : slim ne marche plus chez moi, comme chez d'autres apparemment (mais pour d'autres raisons), voir :
https://bbs.archlinux.org/viewtopic.php ... 77#p862277

J'ai contourné ce problème il y a déjà un moment en remplaçant slim par lxdm. Si tu as une idée de ce qui empèche slim de marcher sur mon portable (il marchait au début, quand j'ai installé Arch), je serais très intéressé.

tuxce : ck-launch-session ne gère pas l'automontage, il ne fait que spécifier des variables selon la session, polkit se sert ensuite de ces valeurs pour donner ou non une autorisation. consolekit ne se substitue pas à un gestionnaire de session, il faut toujours le lancer, certains gestionnaires tel gdm le lance tout seul.

J'ai vu que tu étais sans doute l'auteur des pages du wiki francophone d'Arch sur consolekit et policykit. J'avoue ne pas y comprendre grand chose . Tu me suggères de maintenir le lancement de ck-launch-session au démarrage de ma session (donc pour moi dans /etc/lxdm/Xsession), c'est bien ça ?

Actuellement je démarre avec 'exec -l /bin/bash -c "dbus-lauch wmii"'. Si je tape dans un terminal la commande 'ck-list-sessions' elle me répond toujours quelque chose. Dois-je en déduire que lxdm lance ck-launch-sessions de toutes façons ?

Cordialement,
LuX.

[tuxce]

Il y a tellement de choses que c'est presque normal de plus s'y retrouver... Déjà, entre le début du topic et aujourd'hui, il y a eu des mise à jour (slim entre autre), le passage d'une version de consolekit de [testing] à [extra], des paquets qui court circuitent les permissions polkit (xfce4-session par exemple, ce qui impacte le système même si on utilise pas xfce), bref, à mon avis, si ça fonctionne pour toi et qu'en plus ck-list-sessions te retourne des infos, autant ne rien changer pour l'instant.

[LuX]

[Merci tuxce.] Maintenant le sujet est vraiment (résolu) !!