Debian Sid – bogues dans les bacs résolus (debriefing)

Les bugs (bogues ? ^^) sont enfin résolus.
Je vous présente ci-après un petit debriefing des bugs et de ce que j’ai appris en essayant de les résoudre.

Résumé très succinct des opérations (en faisant notamment abstraction de mes erreurs et errances personnelles) :

• A la mise à jour de Debian Sid (grosse mise à jour fin de semaine dernière), GDM  – le gestionnaire de démarrage que j’utilisais par défaut, ne fonctionne plus. Le bug est d’autant plus pernicieux que gdm semble fonctionner mais visiblement il ne parvient pas à lancer correctement ni GNOME ni KDE qui plantent tous deux. GDM n’ayant pas été mis à jour, il semble que ce soit les mises à jour effectuées sur KDE et GNOME qui induisent ce dysfonctionnement. Pour contourner ce bug il suffit d’activer (par un « # dpkg reconfigure gdm » qui propose alors de choisir le gestionnaire de démarrage par défaut parmi les gestionnaires que vous aviez installé) par exemple gdm3 (gdm3 ne peut être installé actuellement – suite à un bug important, mais si vous l’aviez déjà installé et non mis à jour, il fonctionne) ou kdm (à installer par un « # apt-get install kdm »)
• Toujours dans cette même mise à jour de Debian Sid, j’ai été confronté à un bug (d’apt-get ?, j’utilise la version 1.0.1, une version 1.0.3 est à présent dans les bacs, j’ignore si elle résout ce problème) à la mise à jour de paquets importants comme systemd-sysv, sysvinit, systemd et libpam-systemd. Ce bug se manifeste à la mise à jour de l’un de ces paquets par un plantage sur une Erreur de segmentation (visiblement un dysfonctionnement d’apt-get qui ne parvient pas à ordonner la mise à jour de ces paquets). La résolution s’effectue en installant manuellement (« # apt-get install nomdupaquet ») un à un les paquets dont ils dépendent (opération assez rapide, les dépendances à mettre à jour étant peu nombreuses et indiquées lors de l’apt-get des paquets pré-cités).

Je vais à présent être en mesure de reprendre la mise à jour du Bottin (avec une perte de production importante pour le Bottin).

L’opération aura eut néanmoins un certain nombre de retombées positives (comme à chaque fois que l’on essaie de résoudre un problème par sois-même – plutôt que de tout réinstaller) en me permettant – notamment, d’en apprendre davantage sur Linux.

Voilà ce que j’ai appris dans la semaine :

• j’ai trouvé un widget sympa pour afficher des listing de commandes sous WordPress : Pastacode (vous le trouverez facilement dans les widgets de WordPress). Il est simple à mettre en oeuvre, donne un affichage assez joli et surtout est peu gourmand en ressources. J’avais aussi testé et mis en oeuvre les widgets WP-Syntax + WP-Syntax Editor Integration Plugin qui donnent un plus bel affichage, plus condensé et plus ergonomique à l’utilisation. L’outil semble plus performant en terme de fonctionnalités, néanmoins il consomme énormément de bande passante ce qui génère un ralentissement important des pages générées, rendant pénible la lecture de votre page.
• CHROOT :
  • j’ai beaucoup appris sur le chroot, notamment que çà n’isole pas les périphériques (et que le noyau utilisé est celui de la clé USB, pas celui du système hôte à dépanner – avec toutes les conséquences induites), ce qui rend difficile / impossible de tester l’accélération graphique d’un système hôte en chroot (pas à ma portée en tout cas). Il faudrait que je creuse encore un peu le sujet (notamment maintenant que c’est réparé, quel est le comportement de l’ensemble démarré avec ma clé USB de dépannage : KDE et GNOME démarrent-ils via cette clé sans accélération nvidia puisque sur ma clé j’utilise le driver Nouveau ? – ou plus probablement, ils vont fonctionner avec Nouveau).
  • Il semble impossible (ou du moins je n’y suis pas parvenu) d’installer un noyau sur un système hôte chrooté à partir d’une clé de dépannage à cause de grub qui nécessite d’accéder au fichier de périphérique du disque de démarrage du PC chrooté (message à l’installation du noyau « /usr/sbin/grub-probe : erreur : impossible d’obtenir le chemin canonique de /dev/sda1 »), ce que ne permet pas le chroot. Ca aurait pu être utile par exemple en cas de plantage d’un noyau – sans noyau de secours (à éviter donc :)).
  • Xorg est très difficile (en tout les cas, pas à ma portée pour l’instant) à démarrer à partir d’un chroot externe (hors du système d’exploitation d’origine) – via une clé USB de dépannage notamment. Lui préférer IceWm (voir ci-après).
  • Pour qu’un chroot fonctionne bien, certaines commandes supplémentaires sont utiles (voir le message précédent : modifs de fstab du système hôte et « mount –bind … »).
• Grâce à IceWm + xnest (+ xterm sous IceWm) installés sur ma clé USB de dépannage, je peux me passer de l’horrible Dselect, en lançant Synaptic à partir de xterm (à condition d’avoir une clé de dépannage avec un gestionnaire graphique installé). Un net progrès dans l’ergonomie de mon système de dépannage. Je vous le recommande chaudement, je pense qu’une bonne idée serait que quelqu’un propose des clés de dépannage à télécharger (association LanPower et/ou Debian ?) comprenant tous ces bons outils.
• Xterm est moche mais robuste, il fonctionne encore quand la console dénommée « Terminal » (et bien d’autres applications) sous IceWm ne fonctionne plus.
• IceWm est moche mais robuste, il fonctionne encore quand GNOME et KDE ne fonctionnent plus.
• Synaptic n’est pas moche et en plus il est robuste, il fonctionne encore quand GNOME, KDE et de nombreuses autres applications ne fonctionnent plus.
• glxinfo est un bon outil pour voir si l’accélération graphique (« direct rendering: Yes ») est fonctionnelle, mais il ne fonctionne pas hors d’un gestionnaire de fenêtre, c’est bien dommage (surtout que l’affichage est purement textuel), il serait encore plus utile (lors des dépannages) s’il fonctionnait dans cette configuration.
• le paquet network-manager est sans doute utile mais pas indispensable pour une communication réseau entre PC.
• DKMS :
  • avec dkms les drivers ne sont plus stockés dans /lib/module/nom_du_noyau mais dans /var/lib/dkms/.
  • fichier de log : ne pas se fier au contenu de /var/lib/dkms/nvidia/xxx.yy.zz/build/make.log. Dans le cas d’un driver nvidia construit via dkms, le fichier de log le plus fiable est celui qui se trouve dans /var/lib/dkms/nvidia-current/xxx.yy/version-du-noyau/i686/log/ et si un module/driver nvidia a été construit, il se trouve dans /var/lib/dkms/nvidia-current/xxx.yy/version-du-noyau/i686/module/ (exemple : « nvidia-current.ko »).
• Attention à gdm : il peut être vicieux dans son comportement en cas de bogue :).
• Je vais finalement passer au dépôts Debian Français (moins récents mais aussi moins de bugs ^^).
• Toujours se méfier des grosses mises à jour dans les dépôts :).

Du coup j’hésite un peu à poursuivre la mise à jour (il me reste encore des paquets à mettre à jour) de mon système :)

Allez, soyons fou … :)

Pour la petite histoire :

Je viens de mettre à jour (le 08/08/2014 à 20:40) tous les paquets Debian Sid de la section « Nouvelle version amont du logiciel » de Synaptic à partir du dépôt Français (de nombreux paquets ont été ajoutés dont apt) : en dehors de gdm (non retesté), sudo en version 1.8.9p5-1 qui ne fonctionne pas (mais c’est récurrent sur ma distrib avec ce paquet) et des paquets grub (signalés avec un bogue grave), tout fonctionne parfaitement (mais aussi après ma manip précédente sur sysvinit et consorts).