Bonjour,
/dev/sda c’est ton disque dur /dev/sdb c’est la clefr USB?
Savoir le nombre de ligne d’un ls ou d’un mount n’a aucune utilité ici.
Quand tu branche ta clef, c’est là qu’on a besoin du dmesg, juste à la fin, où l’on voit les messages dmeshg.
Coté logs, le kernel n’est pas toujorsu suffisant, donc un
journalctl --since ‹ 15 minutes ago ›
par exemple sera plus complet.
Si entre ta machine virtuelle et ton système il y a une différence de comportement c’est que d’une part les paquets installés ne sont pas identiques, et d’autres part que la configuration n’est pas identique.
Et pour les plus vieux, nous portons des lunettes, donc les caractères gras partout ne sont pas nécessaire.
Peu importe (ça risque de changer au reboot suivant).
Toutefois comme indiqué dans le journal en temps réel (journalctl -kf) :
ici sda c’est la clé USB
ici sdb c’est le disque externe
enfin sr0 c’est le smartphone
Si, c’était pour attester que le montage fonctionnait bien !
Voir la remontée du journalctl indiquée dessus
OK je vais refaire les tests quand j’aurais restauré car là je teste une réinstallation complète avec ces réglages sans rien configurer de plus :
Résultat : à la 1ère ouverture de session, j’ai constaté que la clé était tout de suite affichée sur le bureau sans aucun réglage supplémentaire
Peut être que mon installation foireuse n’a pas été installée avec « environnement de bureau Debian » ni « utilitaires usuels du système », mais dans tous le cas j’ai complété suivant les besoins.
Oui, j’ai d’ailleurs fait un diff entre les paquets installés sur la VM et la machine physique, mais bon il y en a trop pour que l’évidence me saute aux yeux.
Désolé , j’ai mis en évidence les parties qui me semblaient importantes car la plupart des utilisateurs lisant en diagonales me répondent en donnant des informations que j’ai déjà incluses dans mon message. Aussi, j’avoue que je ne sais pas trop faire l’équilibre entre trop en dire et pas assez … Mais aucun problème je n’emphaserai pas d’avantage !
Une fois restauré le système indiqué comme foireux, comme j’avais laissé en place la clé qui m’avait permis de réinstaller Debian, je me suis rendu compte qu’à la première ouverture de session avec un utilisateur NON root, qu’elle était affichée sur le bureau ainsi que dans thunar sans avoir rien modifié.
Cette clé USB je l’ai créé avec la commande dd if=debian-12.4.0-amd64-netinst.iso of=/dev/sde bs=1M && sync et j’ai installé Debian avec les paramètres que j’ai indiqué avant.
Également j’ai constaté que dans cette installation fraiche les utilisateurs faisaient parti des groupes disk, plugdevet storage alors que depuis le système restauré, les utilisateurs n’appartenaient pas aux groupes disk et plugdev. Je l’ai ai ajouté, mais ça n’a rien changé.
J’ai donc testé toutes mes clés, qui sont toutes détectées par le noyau et seule celle préparée pour installer Debian 12 est affichée. Et ce n’est à priori pas une histoire de droits puisqu’avec root c’est pareil. Pareil pour un disque dur externe, bien détecté mais pas affiché.
J’ai regardé dans les erreurs (journalctl -p 3 -xb), mais rien vu de suspect (je peux fournir les journaux) :
Salut ! En CLI avec mount et umount , en GUI en double cliquant dessus le périphérique qui est affiché (ou click droit > Monter) mais mon problème actuel est avant le montage.
Les périphériques ne sont affichés ni sur le bureau (alors que le bureau de XFCE est configuré pour afficher toutes les icônes des supports amovibles), ni dans le gestionnaire de fichier thunar (avec les paquets et la configuration qui va avec - voir mon 1er message).
Le truc étrange, c’est que depuis une installation fraîche de Debian avec XFCE, les périphériques sont bien affichés sans avoir rien configuré.
‹ mount › et ‹ umount › sont des commandes root. Ça commence mal, surtout si tu forces le démontage en root, sans t’assurer que la partition n’est pas occupée.
Ta question est relative à thunar dans un espace usager et non root.
Absolument pas besoin de root pour monter une clef USB : l’erreur commence ici.
Commence par vérifier que tes clefs à problèmes ne soient pas vérolées par un démontage branquignole.
Ensuite, identifie clairement une clef , et concentre toi sur cette clef pour maniper (pas besoin de 50).
Si tu manques d’inspiration, tu peux lire [ Montage partition + image iso/disque pour l’usager lambda pour mieux comprendre où je veux en venir.
Alors … comme je l’ai dit dans la réponse avant la tienne (message #4), mais il est vrai que j’écris beaucoup, en session graphique root, donc avec tous les droits, je ne vois pas pour autant le périphérique sur mon bureau alors que ça devrait.
Dans l’installation problématique, que je sois root ou non, je ne vois pas les périphériques alors que pour une installation fraîche, tout fonctionne sans aucun réglage (voir #4). C’est mon 1er indice.
Comme attesté dessus les clés sont détectées sans erreur, opérationnelles, se montent très bien et j’ai accès aux données, … ah et aussi comme je les utilise principalement hors ligne (clés de boot ou de live session) ou en ligne sur des système Linux je ne pense pas qu’elles soient vérolées.
J’ai également remarqué un peu par hasard, que si je clone un ISO avec dd (voir #4) sur une clé, pour faire une clé bootable d’installation par exemple, elle est bien affichée sur mon système problématique (les autres clés non) et montable en root ou non. Pour moi ça aussi c’est un indice
Merci pour les trucs et astuces , je vais jeter un œil dès que possible …
De quel bureau parles-tu ? Le bureau usager ou root, en supposant thunar ouvert en root ?
Ça va être trop confus pour poursuivre.
Donc, c’est bien tes manipulations, ou mauvaises configurations qui sont la cause de tes problèmes, pas le système.
Pour simplifier mon point de vue, ‹ root › ne doit apparaître nul part dans tes manips.
Pardon, je vois que ce n’est pas clair. Quand je parle de session root, je fais référence à une session graphique (et non en sessions console/terminal) qui démarre depuis le greeter (écran d’accueil ou accueillant), dès que je choisi un nom d’utilisateur, ici root, et que je renseigne son mot de passe. Oui la session même qu’il ne faut pas ouvrir, etc. Mais si déjà en session root le périphérique n’est pas affiché, je ne vois pas vraiment comment il peut l’être avec un utilisateur non root.
Je n’ai jamais dit le contraire, mais je n’arrive pas à déterminer ce qui coince.
Là je ne suis pas d’accord avec toi. 1) je sais utiliser root, je sais même octroyer des droits root à un utilisateur non root, 2) c’est souvent un bon moyen de circonscrire le périmètre d’un problème.
De pire en pire. Ça va être un dialogue de sourd, comme si on n’était pas sur la même planète. Tu as visiblement pris de très mauvaises habitudes dont tu constates les conséquences.
Je n’insiste donc pas.
Si je te disais évidemment non, tu serais choqué.
Je n’imaginais même pas que les règles policykit Debian l’autorise.
Je ne vois pas l’intérêt de pouvoir détruire un système entier par une simple erreur de clic de souris (qui n’arrive pas qu’aux autres).
Ce n’est pas mon point de vue effectivement. Eh oui sur Debian, on peut ouvrir une session root. Et oui on n’est pas à l’abri d’une simple erreur qui peut arriver à tout le monde (et j’en ai fait les frais plusieurs fois, même Linus Torvalds). Mais la façon dont tu me parles me laisse penser que tu présupposes que je suis un débutant. Ce que je dois être dans certains domaines, il est vrai. Comme toi j’imagine.
Je te remercie de m’accorder ton temps et ton aide mais là je suis très en colère contre toi.
J’ai des connaissances en administration système et réseaux, j’ai aussi un multi-handicap et j’essaye de composer avec.
Les réponses que tu me fais sont dans une pensé unique, on dirait que seule ta vérité compte. Je ne peux rien t’apporter visiblement et mes points de vue et habitudes ne semblent avoir aucune légitimité.
Je ne sais pas si tu as pris la peine de lire ce que j’ai testé, vu que je t’ai rappelé ce qui était dessus à maintes reprises.
J’ai passé beaucoup de temps à préparer ces machines pour me rendre compte au moment de l’utilisation qu’une clé USB n’était pas remontée sur le bureau et que les utilisateurs ne pouvaient donc pas l’utiliser.
Et que depuis j’essaye tant bien que mal de corriger le problème et comprendre le pourquoi ? Que je n’ai pas vraiment envie de refaire mon master sans comprendre où est le problème. Que j’écume depuis des jours Internet pour trouver des solutions et quand enfin je me résous à publier mon problème sur un forum pour obtenir un peu d’aide, je tombe sur des personnes qui n’entendent pas une position différente de la leur.
Depuis tout à l’heure je suis blessé par les phrases que tu me dis.
Je ne sais pas comment tu prendrais ces remarques :
Ce n’est pas la première fois dans le forum Support Debian que je tombe face à ce type de problématique. Je pense que je vais remonter ces comportements aux personnes concernées. Merde, on est tous des humains avec nos forces et nos faiblesses.
Je te le redis, je ne pourrais que vous remercier (toi et les autres) et avoir de la gratitude pour l’aide que vous nous accordez sur votre temps personnel, mais ça n’ouvre pas une légitimité à être méprisant. Nous ne sommes pas des punching-ball pour satisfaire votre égo.
Et pour information j’ai longtemps cru en te lisant que c’était toi le débutant, c’est pour ça que j’ai détaillé certaines réponses car je ne voulais pas te blesser toi si tu n’avais pas suffisamment de compétences.
Malgré ce que j’ai dit dans ce message, le temps ayant un peu passé, je suis un peu apaisé d’avoir pu te dire ce qui se jouais pour moi et je suis ouvert à une discussion « vraie ».
Tu es un professionnel en administration système, fais moi profiter de ton expertise.
Toutefois je te le dis, si tu ne reviens pas vers moi, c’est que tu restes sur ta position et moi je ne veux pas que ça se reproduise, je remonterais donc cette discussion (et d’autres), auprès de qui de droit. Je pense qu’il y a un problème de respect et ce n’est pas parce que tu ne m’as pas insulté, que tu ne m’en as pas manqué pour autant. Je précise que je n’ai rien dis jusqu’à présent face à ces manquements (condescendance, humiliation oui tu as bien lu, humiliation) et que jusqu’à présent j’ai accepté, au motif principal qu’après tout vous êtes bénévoles et que je me devais d’accepter ces petits écarts sans faire de vagues, faire comme s’ils n’existaient pas. Et non, je ne partirais pas de ce forum que je trouve très intéressant et dont la plupart des bénévoles m’ont toujours respecté et je les respecte aussi. On avancera ensemble …
Mais moi là je cherche une réponse, que je n’ai toujours pas.
Restons zen et courtois, les gens !
Est-ce que tu as essayé en ouvrant une session avec un user « classique » et non root ?
Il me semble que les clés sont montés dans un espace « non root » (sauf dans certains cas, genre clés bootables…). Du coup, le système est peut-être un peu paumé pour savoir où monter quand tu es sur une session root… (après je suis pas expert…).
Par exemple, chez moi, les clés sont montées sur « /media/mu/ ».
Avec une session root, je ne suis pas sur que le système monte « naturellement » les clés sur « /media/root/ »
Je suis tout à fait disposé à rester zen et courtois mais ce n’est pas moi qui envoie gratuitement des propos blessants et je suis prêt à écouter ce qu’il/elle a dire. Aussi ça fait 2 fois que quelqu’un se permet sur ce forum d’être condescendant et humiliant, donc ça se cumule.
Oui, le constat initial vient de là. Après avoir branché sa clé, l’utilisateur (NON informaticien) ne pouvait pas y accéder ; pourtant je pouvais la monter sans problème, mais ce n’était pas plug and play.
Ha ! Je ne savais pas , je creuserais cette piste …
Oublies la session root, je l’ai uniquement testé pour vérifier que ce qui bloquait n’était pas une question de droits.
Quand je réinstalle Debian à la première ouverture de session NON root, les supports sont bien remontés et affichés sur le bureau, sans rien avoir à configurer et je peux les monter automatiquement (double click ou click droit > monter). Ce n’est pas le cas pour ces machines que j’ai mis longtemps à configurer, où rien ne s’affiche sur le bureau. Je cherche à comprendre ce qui bloque.
Aussi, pour le moment je ne parle pas de problème de montage, mais de support qui est non affiché sur le bureau alors qu’il devrait l’être. Le montage vient dans un 2eme temps.
Ben, sur un système Debian fraîchement installé (par ISO netinstall avec XFCE), j’ai ouvert la session de l’utilisateur créé à l’installation. Tu peux constater que la clé USB DISK est bien affichée un peu en transparence sur le bureau, mais que le montage n’est pas effectif pour autant !
Une fois montée, on voit d’ailleurs qu’elle perd sa transparence :
Je dirais donc non, pour que le support soit visible sur le bureau, il ne faut pas nécessairement qu’il soit monté.
Aussi, dans l’exemple de dessus, j’ai pu monter la clé sans être SU. C’est exactement le comportement que je recherchais. Avant, je devais passer par ce type de configuration. Les utilisateurs qui vont brancher leur clé voudront avoir le même comportement que sous Windows (par défaut on branche une clé, elle est directement accessible, sans avoir à demander à un administrateur), sinon … ben ils iront sur le système Windows du dual-boot et j’aurais loupé la phase de sensibilisation aux systèmes Libre.
–
Aussi, je vais pouvoir essayer de vraiment comprendre quel est le problème de fond, puisque j’ai virtualisé mon système défaillant (pas simple, car machine EFI sur disque formaté en GPT avec dual-boot W+Debian). Je vais pouvoir tester tout ce qui est testable et en même temps refaire mon master correctement.
Je reste donc à l’écoute, si quelqu’un a une piste que je n’ai pas encore exploré, c’est avec plaisir
Bon ben finalement j’ai trouvé et solutionné. Et ce n’est pas avec mes compétences techniques que j’ai trouvé ce qui coinçait mais avec le corps spongieux que j’ai entre les oreilles :-p
Le problème venait d’une règle udev trop restrictive, qui était censé cacher sur le bureau les partitions Windows de mon dual-boot mais qui les cachait toutes. J’avais complètement oublié cette modification et à sa mise en place j’ai du omettre de tester avec des supports externes.
Avant de clôturer, je me demandais si quelqu’un avait une méthode pour déterminer quel.s service.s absorbe.nt un évènement donné (ici le branchement d’un support amovible). J’utilise toujours sudo journalctl -kf qui m’affiche en temps réel l’activité du noyau, mais l’activité de udev n’est bien sûr pas remontée ici, auquel cas j’aurais été tout de suite orienté vers la solution.
Pour avoir uniquement udev (depuis le dernier boot):
journal -b | grep -i udev
en flux:
journal -f | grep -i udev
journal -k n’affiche que les messages du kernel, hors udev n’écrit pas que dans kernel.
Par ailleurs, si tu met des règles udev de tonc ru dans la configuration, pense à ajouter les options de logs dans ta règle, comme cela elle sera visible.
!
! Tu m’as mis sur la bonne voie …