discussion sur les pratiques des aidants

nam1962 · Le 03/03/2019, à 18:38

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 · Le 03/03/2019, à 19:15

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 · Le 03/03/2019, à 20:01

bruno a écrit :

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.

"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 · Le 03/03/2019, à 20:15

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 · Le 03/03/2019, à 20:18

Merci duduche57 de ces précisions ! (et de tes remerciements).

= =

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).

xubu1957 · Le 03/03/2019, à 20:20

Résultat :

xubu@xubu-ThinkPad-T410:~$ dpkg -l | awk '$2~/^linux-([ghit]|[lm]o|si)/ && !/^rc/{print $1,$2,$3,$4}' OFS='\t' | sort -k3,3V
ii	linux-headers-4.15.0-44	4.15.0-44.47	all
ii	linux-headers-4.15.0-44-generic	4.15.0-44.47	amd64
ii	linux-image-4.15.0-44-generic	4.15.0-44.47	amd64
ii	linux-modules-4.15.0-44-generic	4.15.0-44.47	amd64
ii	linux-modules-extra-4.15.0-44-generic	4.15.0-44.47	amd64
ii	linux-tools-4.15.0-44	4.15.0-44.47	amd64
ii	linux-tools-4.15.0-44-generic	4.15.0-44.47	amd64
ii	linux-headers-4.15.0-45	4.15.0-45.48	all
ii	linux-headers-4.15.0-45-generic	4.15.0-45.48	amd64
ii	linux-image-4.15.0-45-generic	4.15.0-45.48	amd64
ii	linux-modules-4.15.0-45-generic	4.15.0-45.48	amd64
ii	linux-modules-extra-4.15.0-45-generic	4.15.0-45.48	amd64
ii	linux-tools-4.15.0-45	4.15.0-45.48	amd64
ii	linux-tools-4.15.0-45-generic	4.15.0-45.48	amd64
ii	linux-tools-common	4.15.0-45.48	all
ii	linux-generic	4.15.0.45.47	amd64
ii	linux-headers-generic	4.15.0.45.47	amd64
ii	linux-image-generic	4.15.0.45.47	amd64
ii	linux-tools-generic	4.15.0.45.47	amd64
xubu@xubu-ThinkPad-T410:~$

xubu@xubu-ThinkPad-T410:~$ 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

ii  binutils-x86-64-linux-gnu              2.30-21ubuntu1~18.04  amd64
ii  linux-headers-4.15.0-44                4.15.0-44.47          all
ii  linux-modules-4.15.0-44-generic        4.15.0-44.47          amd64
ii  linux-modules-extra-4.15.0-44-generic  4.15.0-44.47          amd64
ii  linux-headers-4.15.0-44-generic        4.15.0-44.47          amd64
ii  linux-tools-4.15.0-44                  4.15.0-44.47          amd64
ii  linux-tools-4.15.0-44-generic          4.15.0-44.47          amd64
ii  linux-image-4.15.0-44-generic          4.15.0-44.47          amd64
ii  linux-generic                          4.15.0.45.47          amd64
ii  linux-headers-generic                  4.15.0.45.47          amd64
ii  linux-image-generic                    4.15.0.45.47          amd64
ii  linux-tools-generic                    4.15.0.45.47          amd64
ii  linux-headers-4.15.0-45                4.15.0-45.48          all
ii  linux-tools-common                     4.15.0-45.48          all
ii  linux-modules-4.15.0-45-generic        4.15.0-45.48          amd64
ii  linux-modules-extra-4.15.0-45-generic  4.15.0-45.48          amd64
ii  linux-headers-4.15.0-45-generic        4.15.0-45.48          amd64
ii  linux-tools-4.15.0-45                  4.15.0-45.48          amd64
ii  linux-tools-4.15.0-45-generic          4.15.0-45.48          amd64
ii  linux-image-4.15.0-45-generic          4.15.0-45.48          amd64

4.15.0-45-generic x86_64
xubu@xubu-ThinkPad-T410:~$

nam1962 · Le 03/03/2019, à 20:25

Watael a écrit :

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.

Wiwiwi ! Très concis... Comme ta lecture des posts précédents...

Une fois informé des ii, comment fais tu pour supprimer les paquets en vrac dont tu n'as pas été informé ?

Je pense que si ça continue, je vais quitter ce fil que j'avais abordé avec enthousiasme : au lieu de suggestions constructives et observations qui pourraient aider les aidants, je ne vois que démontages hâtifs de gensses que je n'ai en plus jamais vu sur les fils de démerdage concernés.

Watael · Le 03/03/2019, à 20:36

xubu1957 a écrit :

Résultat

oui, ça démontre quoi ?

nam1962 a écrit :

Une fois informé des ii, comment fais tu pour supprimer les paquets en vrac dont tu n'as pas été informé ?

je ne comprends pas de quoi tu parles sans exemple.
je tourne sur une toute petite Debian, qui ne me pose pas ce problème.

xubu1957 · Le 03/03/2019, à 20:43

Watael a écrit :

oui, ça démontre quoi ?

J'ai mis les deux retours pour comparer l'affichage.

Watael · Le 03/03/2019, à 20:47

ah, oui. dans le deuxième il y a binutils. est-ce pertinent ?

moko138 · Le 03/03/2019, à 21:18

Watael a écrit :

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.

"manque de maîtrise de la ligne de commande"
Évidemment : le peu que je sais en informatique, je l'ai appris sur ce site et dans les man.
C'est bien pour ça que je suis preneur d'améliorations ! (en conservant l'alignement des colonnes et le nom du noyau actif.)

Et oui, exclure binutils du retour ce serait bien ! Bien vu !
Et donc, que proposes-tu de mieux que

echo; dpkg -l | grep -Ei "linux-(g|h|i|lo|mo|si|t)" | grep -Ev "^rc|binutils" | sort -k3 | awk '{print $1,$2,$3,$4}' | column -s" " -t ; echo ; uname -mr

Qu'est-ce qu'une « commande [qui] se pipe "elle-même" » ?
| grep ceci | grep -v cela ?
Si oui, en quoi est-ce à éviter ?

Watael a écrit :

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

La version courte suffit pour un utilisateur chevronné. Ce n'est pas l'objet de ce fil.
La version courte ne satisfait pas aux besoins du dénoyautage chez un non-spécialiste en carafe.

Watael · Le 03/03/2019, à 21:42

je propose awk.

le but est de recueillir des informations; peu importe la méthode, tant que le code respecte les pratiques recommandées (aka best practices).
donc, si sur la ligne de commande, l'une des commandes peut faire ce que font les autres, on privilégie celle-là. donc, awk!!!!!!
peu importe comment, mais pas n'importe comment.

ils vont refaire ce qu'on leur montre.
c'est pourquoi je fustige ceux qui initient au codage en parsant une sortie de ls, parce qu'ensuite les débutants croient que c'est comme ça qu'on parse une liste de fichiers.

Qid · Le 03/03/2019, à 22:10

Faut aussi voir les problèmes de compréhension syntaxique des commandes qu'on donne...
Et sur ce point il me semble bien plus facile de faire/comprendre/relire un grep que un awk...

Watael · Le 03/03/2019, à 22:24

les deux commandes utilisent la même regex, et il n'y a que la regex à comprendre, avec cet avantage pour awk de pouvoir les appliquer à des champs uniquement.

Dernière modification par Watael (Le 03/03/2019, à 22:27)

moko138 · Le 04/03/2019, à 09:01

Un cas de système à headers manquant : ./viewtopic.php?pid=22029186#p22029186

= =

Je n'ai jamais rien compris au man d'awk.
Je n'ai pas trouvé ce qu'apportait ici OFS='\t'

man awk
     OFS       inserted between fields on output, initially = " ".

à part contrarier l'alignement des colonnes.

Pour saisir, par contre, l'intérêt de sort -k3,3V il faut le tester non pas sur vos systèmes bien entretenus, mais sur un fichier compilant les embrouilles.(*)
Et là - ô miracle ! - les numéros de version paraissent dans l'ordre

ii  linux-headers-4.4.0-14-generic         4.4.0-14.999          amd64
ii  linux-headers-4.4.0-90-generic         4.4.0-90.999          amd64
iU  linux-image-extra-4.4.0-142-generic    4.4.0-140.168         amd64
iF  linux-image-4.4.0-142-generic          4.4.0-142.168         amd64
ii  linux-tools-euclid                     4.4.0.9029.30         amd64
ii  linux-modules-4.15.0-43-generic        4.15.0-43.46          amd64

À première vue, du moins.

Parce qu'en réalité, l'option -V de sort traite les 0. après les 0- ! Donc sépare des paquets ayant le même numéro de version :

echo; cat noyaux_test.txt | awk '{print $1,$2,$3,$4}' | sort -k3,3V | column -s" " -t

ii  binutils-x86-64-linux-gnu              2.30-21ubuntu1~18.04  amd64
ii  linux-headers-3.13.0-53                3.13.0-53.89          all
ii  linux-headers-3.13.0-150               3.13.0-150.99         all
ii  linux-headers-4.4.0-14-generic         4.4.0-14.999          amd64
ii  linux-headers-4.4.0-90-generic         4.4.0-90.999          amd64
iU  linux-image-extra-4.4.0-142-generic    4.4.0-140.168         amd64
iF  linux-image-4.4.0-142-generic          4.4.0-142.168         amd64
ii  linux-headers-4.4.0-142                4.4.0-142.168         all
ii  linux-headers-4.4.0-142-generic        4.4.0-142.168         amd64
ii  linux-tools-common                     4.4.0-142.168         all
iU  linux-image-extra-4.4.0-142-generic    4.4.0-142.168         amd64
iU  linux-signed-image-4.4.0-142-generic   4.4.0-142.168         amd64
ii  linux-tools-4.4.0-9029-euclid          4.4.0-9029.31         amd64
### Et hop, le tri redémarre à partir de "0." :
ii  linux-image-machin                     4.4.0.43.45           amd64
ii  linux-tools-truc                       4.4.0.43.45           amd64
iU  linux-signed-image-generic             4.4.0.140.148         amd64
ii  linux-headers-generic                  4.4.0.142.148         amd64
iU  linux-generic                          4.4.0.142.148         amd64
iU  linux-image-generic                    4.4.0.142.148         amd64
iU  linux-signed-generic                   4.4.0.142.148         amd64
iU  linux-signed-image-generic             4.4.0.142.148         amd64
rc  linux-signed-nawak-en-r-c              4.4.0.142.148         amd64
ii  linux-tools-euclid                     4.4.0.9029.30         amd64
ii  linux-modules-4.15.0-43-generic        4.15.0-43.46          amd64
ii  linux-modules-extra-4.15.0-43-generic  4.15.0-43.46          amd64

Et ça, dans les méthodes de dénoyautage, ce serait un fâcheux retour en arrière.

/!\ Mais ça permet de définir une prochaine amélioration :
ordonner correctement les numéros de version, tout en gardant l'alignement des colonnes.

= =

En tâtonnant, je suis arrivé à rétablir l'alignement :

echo; dpkg -l | awk '$2~/^linux-([ghit]|[lm]o|si)/ && !/^rc/{print $1,$2,$3,$4}' | column -s" " -t | sort -k3 ; echo ; uname -mr

Apparemment, ça marche aussi bien que

echo; dpkg -l | grep -Ei "linux-(g|h|i|lo|mo|si|t)" | grep -Ev "^rc|binutils" | sort -k3 | awk '{print $1,$2,$3,$4}' | column -s" " -t ; echo ; uname -mr

et que

echo; dpkg -l | grep -Ei "linux-(g|h|i|lo|mo|si|t)" | grep -Ev "^rc|binutils" | sort -k3 | tr -s " " | cut -d" " -s -f1,2,3,4 | column -s" " -t ; echo ; uname -mr

qui (à part le binutils) donnait toute satisfaction jusqu'au 19/01/2019

mais je ne sais toujours pas pourquoi l'une des trois vaudrait mieux que les autres.

____
(*) Exemple de fichier compilant des possibilités d'embrouilles, voici mon noyaux-test.txt du moment :

ii  binutils-x86-64-linux-gnu             2.30-21ubuntu1~18.04  amd64
rc  linux-signed-nawak-en-r-c             4.4.0.142.148  amd64
ii  linux-headers-3.13.0-53               3.13.0-53.89   all
iU  linux-generic                         4.4.0.142.148  amd64
iU  linux-signed-generic                  4.4.0.142.148  amd64
ii  linux-headers-generic                 4.4.0.142.148  amd64
iU  linux-image-generic                   4.4.0.142.148  amd64
iU  linux-signed-image-generic            4.4.0.142.148  amd64
ii  linux-headers-4.4.0-142               4.4.0-142.168  all
ii  linux-tools-common                    4.4.0-142.168  all
iU  linux-image-extra-4.4.0-142-generic   4.4.0-142.168  amd64
ii  linux-headers-4.4.0-142-generic       4.4.0-142.168  amd64
iF  linux-image-4.4.0-142-generic         4.4.0-142.168  amd64
iU  linux-signed-image-4.4.0-142-generic  4.4.0-142.168  amd64
ii  linux-tools-euclid                    4.4.0.9029.30  amd64
ii  linux-tools-4.4.0-9029-euclid         4.4.0-9029.31  amd64
ii  linux-headers-4.4.0-14-generic        4.4.0-14.999   amd64
ii  linux-headers-4.4.0-90-generic        4.4.0-90.999   amd64
ii  linux-headers-3.13.0-150              3.13.0-150.99  all
iU  linux-image-extra-4.4.0-142-generic   4.4.0-140.168  amd64
iU  linux-signed-image-generic            4.4.0.140.148  amd64
ii  linux-image-machin                    4.4.0.43.45    amd64
ii  linux-tools-truc                      4.4.0.43.45    amd64
ii  linux-modules-extra-4.15.0-43-generic 4.15.0-43.46   amd64
ii  linux-modules-4.15.0-43-generic       4.15.0-43.46   amd64

moko138 · Le 04/03/2019, à 09:03

Watael a écrit :

je propose awk.
le but est de recueillir des informations; peu importe la méthode, tant que le code respecte les pratiques recommandées (aka best practices).
donc, si sur la ligne de commande, l'une des commandes peut faire ce que font les autres, on privilégie celle-là. donc, awk!!!!!!

Tu te comprends, c'est très bien.
Maintenant, peux-tu nous expliquer l'esprit de ce "on privilégie" ? En te mettant à la portée de ceux qui n'ont pas ton savoir ?

= =

peu importe comment, mais pas n'importe comment.

Ça sonne très bien ! Mais qu'est-ce que ça veut dire ?

= =

Watael a écrit :

ils vont refaire ce qu'on leur montre.
c'est pourquoi je fustige ceux qui initient au codage en parsant une sortie de ls, parce qu'ensuite les débutants croient que c'est comme ça qu'on parse une liste de fichiers.

Je te remercie d'avoir apporté tes fustigations-maison.
Mais je reste avec mes questions sans réponses :

Qu'est-ce qu'une « commande [qui] se pipe "elle-même" » ?
| grep ceci | grep -v cela ?
Si oui, en quoi est-ce à éviter ?

Et pourquoi nous sors-tu maintenant un "ls" dont il n'a pas été question jusqu'ici ?

Que signifie « en parsant une sortie de ls » ?
Déjà, "parser", j'ai du mal : j'avais demandé jadis, et noté la réponse :

parse veut dire "parcourir", "filtrer"

Est-ce à dire que ls...|grep et ls...|sort bien que marchant, seraient à proscrire ?
Si oui, pourquoi ? (Mais pour éviter le hors-sujet, Watael, merci d'ouvrir un fil).

= =

Si tu veux bien troquer la badine, empruntée à va savoir qui, pour l'écharpe d'Iris, tu rendras service à tout le monde,
merci !

Watael · Le 04/03/2019, à 09:39

quand les aidants ont besoin d'aide

grep + awk = awk #c'est plus clair ?

awk peut faire ce que fait grep, et plus encore; donc, on n'emploie que awk.
dans le même ordre d'idée, je ne vais pas appeler un programme de regex (grep sed awk...) derrière un parser xml, je sélectionne avec le parseur XML ce que je veux conserver.
je n'utilise pas sed avec awk non plus : les deux peuvent faire la même chose, mais soit je travaille sur des champs (awk) soit sur des lignes.

bon, pour le grep | grep -v, je suis allé un peu vite (c'est vrai) : je n'ai pas prêté attention au -v à cause du awk qui suit, et qui discrédite l'emploi de grep comme je viens de le montrer.
mais j'en vois tellement des grep | grep...

et, oui ls | grep, et pire ls | sort, sont à proscrire.
en général, ça passe, mais des fois pas, donc par prudence on ne le fait pas.
essaye avec un nom de fichier qui contient un passage à la ligne !

Dernière modification par Watael (Le 04/03/2019, à 09:56)

nam1962 · Le 04/03/2019, à 11:46

Un fil type pour moi : https://forum.ubuntu-fr.org/viewtopic.php?id=2037604
- questions basiques quand un comportement est anormal, pour savoir comment l'install est organisée
- précos pour nettoyer et traiter le problème en indiquant ce qui va se passer
- résolution rapide
- alors, oui, l'aidée a appliqué scrupuleusement et pas tout pigé, certaines des commandes sont absconses mais le fil est réutilisable

j'essaie en général

méthode : d'abord s'assurer que la base est saine
simplicité : on pose des questions progressives pour déterminer le problème
pédagogie : le demandeur peut suivre (et les lecteurs ultérieurs aussi)
pérennité : la solution résout et évite que le problème se répète

Sinon, un point fort de Hugo (réflexion sur la refonte du forum) : la possibilité d'indiquer quelle réponse apporte la soluce est un vrai plus : https://forum.manjaro.org/t/swapfile-fs … -all/77654

Dernière modification par nam1962 (Le 04/03/2019, à 11:49)

bruno · Le 04/03/2019, à 12:11

Je crois que ce qui manque, en fait, c'est un endroit où regrouper toutes les commandes et scripts utiles pour dépanner. Et où chacun pourrait y proposer des améliorations.

Sur le fil cité par nam1962, je ne vois rien à redire si ce n'est que les commandes proposées devraientt être un tout petit peu plus expliquées. Ici par exemple ./viewtopic.php?pid=22062166#p22062166 :
Nettoyage du dépôt local des paquets :

sudo apt clean

Suppression des résidus de configuration :

dpkg -l | grep ^rc | cut -d' ' -f3 | xargs sudo dpkg -P

Dernière modification par bruno (Le 04/03/2019, à 12:11)

nam1962 · Le 04/03/2019, à 12:16

bruno a écrit :

Je crois que ce qui manque, en fait, c'est un endroit où regrouper toutes les commandes et scripts utiles pour dépanner. Et où chacun pourrait y proposer des améliorations.
(....)

C'est la propal que je réitère !
Créer une page dans la doc, rappelant les principes :

méthode : d'abord s'assurer que la base est saine
simplicité : on pose des questions progressives pour déterminer le problème
pédagogie : le demandeur peut suivre (et les lecteurs ultérieurs aussi)
pérennité : la solution résout et évite que le problème se répète

Et autres trucs de base, par exemple sortir du cercle : quand je vois un problème Teamviewer, je suggère Anydesk ou DWservice, par exemple. Dans le fil Manjaro que j'indique, le pose une question sur /swapfile et les aidants, m'indiquent de la remplacer par systemd-swap, etc...

Puis les commandes courantes (ou les adresses des fils qui traitent de sujets précis, comme le post wifi ou le post de nany)

Ce fil de discussion pouvant servir à indiquer ce qui doit être dans cette doc

Pour l'explication plus détaillée dans un fil, oui, ça dépend aussi du temps qu'on a )

Dernière modification par nam1962 (Le 04/03/2019, à 12:18)

Mornagest · Le 04/03/2019, à 12:36

Salut,

Moins (beaucoup) de temps pour aider sur le forum, mais je profite de ce sujet et de ces derniers messages pour souscrire à la proposition d'une page de doc pour l'aide. Déjà pour les gens qui en ont besoin, et pour ceux qui en proposent.

Je pense qu'il pourrait être intéressant de lister les commandes selon leur utilité : diagnostic (donc aucune altération du système), réparation (système de paquets cassés, par exemple, quoi qu'on fait dans ce cas-là ?), mise à jour, installation de paquets/pilotes en ligne de commandes (notamment les pilotes proprio dont la procédure n'est pas toujours évidente)...

Bref, de classer et expliciter ces commandes pour qu'un néophyte puisse savoir s'il peut utiliser telle ou telle commande sans craindre d'effacer son système ou de foutre le feu au salon.

nam1962 · Le 04/03/2019, à 13:19

Je plussoie !
Je suis souvent effrayé de voir une aide commençant par "passe :"

sudo apt update 
sudo apt full-upgrade

Quand on ne sait pas si le système ne contient pas du proposed ou des PPA pourris.
Le diagnostic sans altération du système doit être une première priorité !

La dite page de doc pourra également permettre à moindre temps passé, d'expliquer au demandeur ce qui lui arrive (si il en est curieux).

Dernière modification par nam1962 (Le 04/03/2019, à 13:20)

Qid · Le 04/03/2019, à 13:26

nam1962 a écrit :

Je plussoie !
Je suis souvent effrayé de voir une aide commençant par "passe :"
sudo apt update 
sudo apt full-upgrade 
Quand on ne sait pas si le système ne contient pas du proposed ou des PPA pourris.
Le diagnostic sans altération du système doit être une première priorité !

Bof... Pas d'accord... Ppa ou autres joyeusetés présents ou pas je refuse de faire un dépannage sur une machine qui n'a potentiellement pas été mise à jour depuis plus d'un mois...

nam1962 · Le 04/03/2019, à 13:40

Euhhh...
Tu as une idée de ce que fait une mise à jour avec du proposed ou du nilarimogard ?

...eh ben ça t'installe des paquets avec des numéros de version ultérieurs, voire parfois incohérents...
Donc pas rattrapables autrement qu'en les virant/remplaçant un à un car dpkg et apt ne remplacent que des numéros antérieurs ou qu'ils connaissent.
Exemple type : le kernel installé "à la main". Tu peux toujours tenter tous les upgrades que tu veux, même 5 mois après....

Et après, amuse toi à retrouver les paquets/dépendances qui fusillent le système !

Peut-être possible avec

apt-forktracer -v

Mais la mise à jour rallonge ton fil de pas mal de manips (si ne plante pas définitivement le système malade)

Perso, je commence par regarder les sources du problème (ou de soucis ultérieurs) via :

cat /etc/apt/sources.list
ls /etc/apt/sources.list.d -1

(Pour déminer ceusses qui diront que la seconde commande ne montre pas les PPA désactivés : ça permet de savoir si des toxiques avec nomenclature foireuse n'ont pas été utilisés, laissant des scories)

Dernière modification par nam1962 (Le 04/03/2019, à 13:51)

erresse · Le 04/03/2019, à 15:12

nam1962 a écrit :

la possibilité d'indiquer quelle réponse apporte la soluce est un vrai plus

Ma signature incitait déjà à mentionner brièvement la solution finale dans le premier message du sujet, lorsqu'on le passait en résolu. Y indiquer quel message apporte la solution est évidemment ce qu'on peut trouver de plus bref comme mention.
Je dis "bravo", si la solution est apportée par un seul message dans la conversation. Si elle est apparue au fil de plusieurs messages, il serait alors plus simple de synthétiser la solution finale par une mention plus explicite dans ce premier message.
Cela étant, comme chaque message ne peut être édité (et c'est bien normal) que par son rédacteur, il incombe forcément au demandeur de faire cette démarche, l'aidant ne peut guère que l'y inciter...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#76 Le 03/03/2019, à 18:38

Re : discussion sur les pratiques des aidants

#77 Le 03/03/2019, à 19:15

Re : discussion sur les pratiques des aidants

#78 Le 03/03/2019, à 20:01

Re : discussion sur les pratiques des aidants

#79 Le 03/03/2019, à 20:15

Re : discussion sur les pratiques des aidants

#80 Le 03/03/2019, à 20:18

Re : discussion sur les pratiques des aidants

#81 Le 03/03/2019, à 20:20

Re : discussion sur les pratiques des aidants

#82 Le 03/03/2019, à 20:25

Re : discussion sur les pratiques des aidants

#83 Le 03/03/2019, à 20:36

Re : discussion sur les pratiques des aidants

#84 Le 03/03/2019, à 20:43

Re : discussion sur les pratiques des aidants

#85 Le 03/03/2019, à 20:47

Re : discussion sur les pratiques des aidants

#86 Le 03/03/2019, à 21:18

Re : discussion sur les pratiques des aidants

#87 Le 03/03/2019, à 21:42

Re : discussion sur les pratiques des aidants

#88 Le 03/03/2019, à 22:10

Re : discussion sur les pratiques des aidants

#89 Le 03/03/2019, à 22:24

Re : discussion sur les pratiques des aidants

#90 Le 04/03/2019, à 09:01

Re : discussion sur les pratiques des aidants

#91 Le 04/03/2019, à 09:03

Re : discussion sur les pratiques des aidants

#92 Le 04/03/2019, à 09:39

Re : discussion sur les pratiques des aidants

#93 Le 04/03/2019, à 11:46

Re : discussion sur les pratiques des aidants

#94 Le 04/03/2019, à 12:11

Re : discussion sur les pratiques des aidants

#95 Le 04/03/2019, à 12:16

Re : discussion sur les pratiques des aidants

#96 Le 04/03/2019, à 12:36

Re : discussion sur les pratiques des aidants

#97 Le 04/03/2019, à 13:19

Re : discussion sur les pratiques des aidants

#98 Le 04/03/2019, à 13:26

Re : discussion sur les pratiques des aidants

#99 Le 04/03/2019, à 13:40

Re : discussion sur les pratiques des aidants

#100 Le 04/03/2019, à 15:12

Re : discussion sur les pratiques des aidants

Pied de page des forums