Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

discussion sur les pratiques des aidants

xubu1957

Bonjour,

Le sujet était déjà évoqué > Ne faudrait-il pas un "guide du bénévole" ?

Ekel

Bonjour,

Je suis plus un demandeur qu'un aidant mais cette discussion est très intéressante.
Si mon avis peut aider ou pas, je le donne quand même !

Nam1962 a bien cerner les chose #23.
Diesel83140 a bien raison d'ajouter cet axe nouveau dans le #28.
Moko138 a bien résumé la situation dans le #54.
Erresse a bien ciblé la relation demandeur/aidant,dans le #59, n'en déplaise à diesel83140.

Pour professionnellement faire du dépannage sur logiciel propriétaire, je retrouve bien ici la relation entre aidants et demandeurs, de la même manière que je vis celle que j'ai avec mes clients.

- Certains se foutent royalement du comment et du pourquoi et de pour quelle raison ; ils veulent juste que le truc fonctionne comme avant et ils n'attendent que la solution. Même à la rigueur, que l'on fasse les manipulations à leur place, pour qu'il fasse autre chose pendant ce temps-là.

- D'autres ne peuvent se satisfaire de n'avoir que la solution sans ces explications, car l'objectif est de ne plus devoir faire appel à une aide extérieure et de gagner en autonomie.

Il faut donc continuellement jongler avec tout cela pour apporter l'information/solution qui correspond à l'attente du demandeur.

Personnellement, j'ai cette envie de comprendre les raisons (mauvaises manipulations, manque de connaissances, doute) qui me poussent à devoir vous demander de l'aide quand je ne sais pas faire seul et j'essaye donc de donner le maximum d'informations, quand je le peux sur le phénomène qui me "gène", les recherches effectuées, les essais de résolution que j'ai tenté seul, afin d'orienter au mieux justement le retour attendu.
Cependant, il m'a fallu un peu de temps pour m'habituer, m’adapter, à ce fonctionnement. Peut-être justement à cause de, plus que grâce à, mon emploi.

Je comprends donc par ce fil que vous cherchez à vous "imposer" une démarche de résolution de la demande ; peut-être faudra-t-il aussi penser à "obliger" le demandeur à proposer sa demande sous une forme "structurée". (Vaste autre débat en perspective !)

Professionnellement, nous apprenons à répondre à une demande par des questions, bien avant d'apporter la moindre solution, tout de même. Il s'agit de comprendre le contexte.
Certains fil ici se montent de cette manière naturellement, alors que d'autres se font dans la douleur, voire n'avancent jamais parce que ce retour attendu ne vient pas.
Ils nous a été parfois nécessaire de passer par des formulaires à remplir afin de nous forcer à formater une demande, en interne certes, pour que ce minimum d'informations soit au maximum obtenu de la part du demandeur pour l'aidant.
Alors c'est vrai que cela est fastidieux, mais :
- quel plaisir de voir un retour rapide, quand tous les éléments nécessaires ont bien été transmis.
- quel plaisir de comprendre que cela va être plus long en traitement également quand tous les éléments nécessaires ont bien été transmis, par un premier retour.
- quel plaisir de se prendre un bonne baffe, quand tous les éléments nécessaires n'ont pas bien été transmis.

Maintenant, les uns et les autres, demandeurs et aidants, restons humains et rien ne pourra donner par une recette magique la solution à cette problématique, comme aux autres.

En tout cas, pour conclure, merci pour votre implication, les uns et les autres dans ce forum !

Nous avons une base de connaissances uniquement interne pour retrouver des problématiques et les solutions correspondantes. Cela ne fait pas tout, mais c'est vrai que cela permet d'avancer vers la solution attendue.

Cordialement.

xubu1957

Ekel a écritJe comprends donc par ce fil que vous cherchez à vous "imposer" une démarche de résolution de la demande ; peut-être faudra-t-il aussi penser à "obliger" le demandeur à proposer sa demande sous une forme "structurée". (Vaste autre débat en perspective !)

Déjà débattu > Nouvelles règles du forum !

moko138

nam1962 a écritJe reviens sur ma proposition de créer sur la base de cette discussion une page de doc que le fil enrichira.
Dans la page de doc , il peut très bien y avoir des liens vers des fils (comme justement le fil de nany sur les kernels)

L'avantage de la démarche est que ce fil (et éventuellement d'autres) peut être enrichi sans éparpillement des commandes utiles pour l'aide.

Je n'ai rien compris ; peux-tu préciser ?

nam1962

L'idée est de profiter d'un fil (peut-être un nouveau fil d'ailleurs, celui-çi étant devenu un débat d'idées) pour échanger des méthodos d'aide (commandes, approche, etc...).
Depuis le fil en question, en profiter pour alimenter une page de la doc sur l'assistance aux demandeurs.
Plus clair comme çà ?

NicoApi73

Ekel a écrit Je comprends donc par ce fil que vous cherchez à vous "imposer" une démarche de résolution de la demande ;

La démarche de résolution est très liée à :
- le niveau technique de l'aidant
- l'approche de l'aidant
- les informations fournies au préalable par le demandeur
- la manière dont le demandeur va faire sa demande

Imposer une démarche de résolution lasserait vite certains aidants qui n'ont pas la même approche que celle imposée et découragerait certains de se lancer. A un problème donné, il y a souvent plusieurs manières d'arriver à la solution.

bruno

moko138 a écrit En usage quotidien, en 2012, la Doc sur le nettoyage des noyaux, préconisait
dpkg -l | grep -Ei "linux-headers|linux-image"
Puis, en 2016 dpkg -l | grep -Ei "linux-(g|h|i|lo|si|t)" dont le retour incluait encore les "rc" et affichait les fichiers sans les classer par numéro de version,

Début 2019, on tourne autour de :
echo; dpkg -l | grep -Ei "linux-(g|h|i|lo|mo|si|t)" | grep -v ^rc | sort -k3 | awk '{print $1,$2,$3,$4}' | column -s" " -t ; echo ; uname -mr
Aucun novice ne s'est plaint de cette évolution sur sept ans, et la tâche des aidants en est considérablement simplifiée et accélérée.

Et je crois qu'il ne viendrait à l'idée de personne de
revenir à dpkg -l | grep -Ei "linux-(g|h|i|lo|mo|si|t)".

Bien, voilà un bel exemple d'une commande qui me paraît inutilement alambiquée.

Quel en est l'objectif ? Voir les noyaux installés ?

dpkg -l linux-image* | grep ^ii

ls -l /boot/initrd*

sont deux commandes relativement simples qui permettent de le voir de manière tout à fait lisible.

NicoApi73 a écritImposer une démarche de résolution lasserait vite certains aidants qui n'ont pas la même approche que celle imposée et découragerait certains de se lancer. A un problème donné, il y a souvent plusieurs manières d'arriver à la solution

+1000

xubu1957

@bruno

J'avais obtenu ces précisions :

Le 07/01/2016, nany a écritOui, ma ligne de commande ratisse plus large.
Alors, petite explication:
tout d’abord je renvoie à man dpkg popur la première commande, ou plutôt man dpkg-query pour l’option -l;
ensuite je renvoie à man grep les options;
je passe maintenant au détail de la recherche;

g pour voir la présence ou non du méta-paquet (responsable mes mises à jour);

h pour voir les headers ;

i pour voir les images;

lo pour voir les éventuels paquets lowlatency (Ubuntu Studio);

si pour voir les éventuels paquets signed;

t pour voir les éventuels paquets tools.

À noter que les paquets tools sont apparemment relativement récents et ne sont actuellement pas pris en charge par kclean. J’ai proposé un patch à hoper qui doit faire une nouvelle version très prochainement.

Watael

grep ×2, c'est déjà trop; alors +awk :mad: *

*j'ai laissé ma tronçonneuse ailleurs, mais :massacre:

bruno

@xubu1957 : je ne sais pas quel était l'objectif précis de cette commande mais sur la forme je ne peux qu'approuver ce que dit Watael.
Sur le fond quelle nécessité de voir les headers, les lowlatency, les signed etc. et dans ce cas pourquoi pas les aws, les cloud, kvm et autres ? D'autant que les commandes que je propose montreront tout cela.
Enfin en dernière justification je vois une référence à un script kclean dont je désapprouve l'utilisation (comme de la plupart des scripts non officiels). Car un simple :

sudo apt autoremove

suffit au final à faire le ménage dans les noyaux non utilisés (le bug de autoremove concernant les noyaux n'étant plus d'actualité depuis un bon moment.

J'ai vraiment l'impression que dans le cas précis, de cette commande elle a été reprise et complexifiée au fur et à mesure sans vraiment se poser de question ni sur sa pertinence, ni sur sa syntaxe.

xubu1957

@bruno

J'avais eu cette explication

Le 27/04/2017, cqfd93 a écritBonjour,
(...)
Vous aurez remarqué deux choses déjà connues :

quand c'est la partition /boot qui est pleine, ça ne sert à rien de faire du vide dans /usr/src/ à coup de rm, donc là, vous avez tourné en rond tant que rien n'a été fait suffisamment dans /boot

quand apt est bloqué à cause des dépendances liées à un manque de place dans /boot, lancer des commandes apt ne peut pas marcher, il faut absolument commencer par faire plein de vide dans /boot pour le débloquer

_ _ _

Depuis 3 ans, la commande a été utilisée régulièrement.

bruno

Permet moi de mettre en doute cette affirmation :

quand apt est bloqué à cause des dépendances liées à un manque de place dans /boot, lancer des commandes apt ne peut pas marcher, il faut absolument commencer par faire plein de vide dans /boot pour le débloquer

AMHA et peut-être ai-je tort, ceci ne peut arriver que si l'on a volontairement désactivé l'espace réservé à root du système de fichier où se trouve /boot.

xubu1957

Pour les commandes, je sers celles des aidants confirmés, je ne saurais jamais les alléger.

Le wificheck du forum est plus ramassé que celui du forum anglophone, il m'a fallu deux ans pour pouvoir l'exploiter correctement.

Le boot-info est aussi bien fourni.

cqfd93 a débrouillé des quantités de discussions avec des noyaux mal installés !

On fait ce qu'on peut, avec les outils du moment.

Le but de cette discussion est de voir comment améliorer l'entraide avec des processus actualisés.

moko138

bruno a écritPermet moi de mettre en doute cette affirmation :

quand apt est bloqué à cause des dépendances liées à un manque de place dans /boot, lancer des commandes apt ne peut pas marcher, il faut absolument commencer par faire plein de vide dans /boot pour le débloquer
AMHA et peut-être ai-je tort, ceci ne peut arriver que si l'on a volontairement désactivé l'espace réservé à root du système de fichier où se trouve /boot.

Tu te trompes, pour deux raisons
- l'espace réservé par défaut est de 5%. Sur une /boot/ de 500 Mo, ça représente 25 Mo. Donc même si l'espace réservé pouvait servir au déblocage de noyaux, ce serait insuffisant.

- Mais de toute façon, l'espace réservé, l'est pour une partie des tâches du système (syslogd, journalisation...), et non pour toutes. Cf.

man mke2fs
       -m pourcentage_blocs_réservés
              Indiquer le pourcentage de blocs du système de fichiers réservés pour le super‐
              utilisateur.  Cela permet d'éviter la fragmentation et permet aux démons lancés
              par le superutilisateur, comme syslogd(8), de continuer à fonctionner correcte‐
              ment  après que les processus non privilégiés ne soient plus autorisés à écrire
              sur le système de fichiers. La valeur par défaut est de 5 %.

Une lecture très instructive :
https://www.maccagnoni.eu/2013/10/ubuntu-mise-a-jour-du-noyau-et-aucun-espace-disponible-sur-le-peripherique/#more-1134

bruno

Oui j'avais mal lu trop vite l'affirmation que je mettais en doute. Si c'est apt qui est bloqué c'est une commande lancé par root qui bloque, mon argument sur l'espace réservé ne tient donc pas debout 😉
Mais dans ce cas il y a le mode de récupération.

nam1962

moko138, tu m'as grillé ! 😛
@bruno : il y a eu des dizaines (voire centaines) de fils d'aide sur ce sujet.
On a vu des installs avec plus de 40 kernels, et à peu près tous les statuts de

man dpkg-query

Dans ces cas, l'embouteillage crée des incohérences et les noyaux (ou parfois autres paquets sont parfois incomplets et dans tous les états.
autoremove ne peut rien faire dans ce cas.
D'ailleurs, pour être sûr qu'il fasse le boulot, mieux vaut

sudo apt autoremove --purge

@ Watael : Le seul moyen de bosser proprement est de savoir tous les morceaux qui traînent, d'où l'intérêt très clair de cette commande. Maintenant, une commande plus concise ou lisible qui ferait le même boulot est toujours bienvenue !

Depuis la 18.04, les choses se sont calmées : la gestion des kernels s’améliore (lentement) Tout comme autoremove a progressé, Mais c'est encore loin d'être parfait.

duduche57

Bonjour à tous,

En tant que demandeur, je souhaite d'abord remercier tous les bénévoles qui animent ce site et viennent en aide aux pauvres néophytes qui n'y comprennent rien à Ubuntu mais préfèrent travailler avec un outil libre plutôt que d'alimenter W ou A.

Voilà ce que j'attends des bénévoles:

donner des instructions compréhensibles et s'assurer que le demandeur a la capacité à les mettre en œuvre;
expliquer systématiquement pourquoi ils donnent telle ou telle instruction ou demandent de taper telle ou telle ligne de commande, afin que le demandeur s’instruise et gagne en compétence;
ne pas s'offusquer des questions qui leur paraissent basiques ("qu'est-ce qu'un terminal", "comment insérer une image sur le forum", etc.) mais qui sont autant de montagne à gravir pour le demandeur;
ne pas répondre si on ne maîtrise pas le sujet ("d'abord, ne pas nuire");
ne pas répondre si on sait qu'on ne pourra pas accompagner le demandeur (parce qu'on part en vacances ou qu'on a trop de boulot, par exemple);
garder à l'esprit que c'est grâce au travail des bénévoles qu'il y a des demandeurs qui osent venir à Ubuntu, qui leur en fait pourtant baver pas mal.

Bonne continuation
(Ubuntutiste depuis 2006, qui songe parfois à laisser tomber, et que les bénévoles remettent dans le droit chemin 😉

moko138

bruno a écritvoilà un bel exemple d'une commande qui me paraît inutilement alambiquée.

Quel en est l'objectif ? Voir les noyaux installés ?

dpkg -l linux-image* | grep ^ii

ls -l /boot/initrd*

sont deux commandes relativement simples qui permettent de le voir de manière tout à fait lisible.

"deux commandes relativement simples" : oui, mais insuffisantes.

"Quel en est l'objectif ? Voir les noyaux installés ?"
Non, l'objectif est de montrer les paquets de noyaux
* présents bien installés,
* présents mal installés,
* manquants

- les paquets imparfaitement installés (iF, iU, iH)
- les paquets manquants (-signed, -locale, -modules (apparus avec 18.04), etc., ou tout bêtement -headers, car ça arrive, que le headers manque !)

Et de le montrer lisiblement. Donc
grep -v ^rc évite les retours noyés sous un excès de "rc". (Ils ne prennent pas de place, donc on s'en occupe en dernier) ;

sort -k3
Si les paquets sont dans l'ordre alphabétique, repérer un éventuel paquet manquant, c'est la croix et la bannière.
Mais s'ils sont rangés par numéro de version, s'il en manque un, ça saute aux yeux.

awk '{print $1,$2,$3,$4}'
Supprime les colonnes pour alléger le retour.

column -s" " -t
Réaligne les colonnes, sinon on perdrait la lisibilité.

Les "echo" eux aussi, servent la lisibilité.

uname -mr pour savoir quel noyau opérationnel est à préserver impérativement tant que le système n'est pas remis d'équerre.

Voilà pourquoi cette ligne composite, née de concertations successives entre dénoyauteuse/teurs actifs, est actuellemnt en usage...
...en attendant les prochaines améliorations. Vos contributions sont bienvenues ! 🙂

Watael

moi, je vois un manque de maîtrise de la ligne de commande, et ça se manifeste dès qu'une commande se pipe "elle-même".
et c'est pire quand une commande, derrière, peut faire mieux toute seule.

dpkg -l | awk '$2~/^linux-([ghit]|[lm]o|si)/ && !/^rc/{print $1,$2,$3,$4}' OFS='\t' | sort -k3,3V

mais je préfère quand même la version courte :

dpkg -l linux-image* | grep '^ii'

c'est beaucoup plus clair :
dpkg affiche-moi les noyaux, et grep ne me montre que ceux sont installés.

moko138

Merci duduche57 de ces précisions ! (et de tes remerciements).
[center]= =[/center]

Quant à la commande

ls -l /boot/initrd*

elle est très bien ! Mais

sudo du -a --max-depth=2 /boot | sort -n | tail -23

a l'avantage :
- de montrer le poids total ;
- et surtout de détecter automatiquement le piège d'une corbeille appartenant à root et saturant la partition. (Voir le cas ./viewtopic.php?id=2024752 de La Miecyclette (mai 2018) qui, faute de cette commande, nous avait donné du fil à retordre).

« Page précédente Page suivante »