Éviter de présenter simultanément la mise à jour des paquets importants du système avec celle des gros gestionnaires de fenêtres (KDE et Gnome) (message aux mainteneurs Debian si par un heureux hasard l’un d’eux nous lisait) :
Comme je l’ai lu ailleurs, je suis d’accord pour dire qu’une Debian Sid représente un bon compromis entre stabilité et fraîcheur des mises à jours (quotidienne, contrairement aux distros classiques qui font des pas de plusieurs mois mais vous offrent en contre-partie un assemblage testé).
Sauf qu’en plus de ces mises à jours quotidiennes des paquets, en moyenne une fois par an vous tombe dessus une avalanche de paquets liés à de nouvelles versions de KDE ou Gnome. Le souci c’est qu’au milieu de ces innombrables paquets viennent se mêler des mises à jours simultanées de paquets importants qu’il est difficile/pénible de dissocier du reste (du fait des dépendances entre paquets).
Pour exemple, lors de cette récente migration vers KDE 4.4.4, j’ai dénombré ces mises à jour simultanées (paquets importants) : bsdutils, dpkg, e2fslibs, e2fsprogs, grub2, grub-common, grub-pc, initramfs-tools, initscripts, libc6, libc-bin, libcomerr2, liblzma2, libpopt0, libsepol1, libss2, libssl0.9.8, libtasn1-3, libuuid1, locales, mount, sysvinit-utils, sysv-rc, udev, util-linux, vim-common, vim-tiny, xz-utils et je dois en oublier un ou deux encore … sans parler des mises à jour de versions dérivées du noyau 2.6.32 (nous ne sommes pas arrivé au 2.6.35 :).
En mettant tout çà à jour d’un coup, nous mettons toutes les chances de notre côté d’arriver à un beau plantage au milieu de nulle part, avec des paquets à moitié configurés, sans accès Xorg, sans accès internet, avec une console aride comme principal outil, nous offrant aussi le plaisir indescriptible du retour au papier et au bon vieux crayon pour noter les messages importants lorsqu’on en a le temps (si vous avez en plus des soucis avec les locales – ce qui a été en plus mon cas cette fois-ci).
Ajoutez que dans bien des cas, le système ne démarre plus, que cette console est celle obtenue à partir d’un CDROM de récupération/netinstall Debian, avec un bash minimaliste (où la ré-édition des lignes est parfois foireuse), que nano l’éditeur de texte ne fonctionne pas dans certains cas (contrairement à vi qui est encore plus aride :), qu’après chaque test de démarrage infructueux il faut reprendre le démarrage à partir du CDROM, recommencer éventuellement le paramétrage réseau (si vous souhaitez installer éventuellement d’autres paquets complémentaires), recommencer les montages, que le changement de version de paquet à l’aide de la commande dpkg nécessite de saisir des noms de paquets à rallonge, etc …et vous obtenez un tableau assez fidèle :).
L’autre souci c’est qu’au lieu de vous retrouver avec une piste de recherche (vous venez de mettre à jour 2 paquets importants la veille : vous constatez un dysfonctionnement, pas besoin d’aller chercher plus loin pour réparer), vous vous retrouvez avec autant de pistes potentielles que de paquets en rapport.
Certains dirons qu’une Debian Sid est faite pour les tests (en plus de la version ‘Expérimentale’). C’est à la fois vrai et tellement dommage, car le restant de l’année elle fonctionne vraiment comme une horloge et elle est certainement très près du Nirvana des distros par ses mises à jours régulières, sa facilité d’emploi (en dehors des situations énumérées ci-avant) et son catalogue.
A l’heure où l’on veut attirer les utilisateurs vers Linux, çà ne vaudrait pas le coup de les bichonner un peu en leur évitant ces grosses galères ?
Imaginez un novice qui se retrouve planté avec tous ces paquets importants en vrac et un système qui ne redémarre plus.
Il lui faudra une sacré dose de ténacité pour résister à l’envie de reformater son disque et recommencer son installation, voir de laisser tomber Linux.
Une solution simple ?
Séparer d’un mois ou deux les mises à jours des paquets importants (et pourquoi pas : à des dates données) quitte à retarder d’autant la disponibilité des nouvelles versions des principaux gestionnaires de fenêtre (on est pas à un mois près) en essayant de fractionner ces groupes de paquets importants pour qu’ils ne soient pas mis à disposition tous en même temps.
En ce qui me concerne :
Chaque souci de ce genre me fais grincer des dents mais c’est aussi l’occasion d’en apprendre un peu plus sur les rouages de cette mécanique de précision en perpétuelle évolution.
Un formatage bien ordonné serait peut-être parfois plus rapide mais certainement moins formateur (et plus rageant).
Qu’est-ce que j’ai appris cette fois-ci ?
– tout d’abord, la libc6 en version 2.11.1-2 fonctionne (contrairement à la version 2.11.1-1) :),
– cette grosse mise à jour aura été bien foireuse à cause des noyaux 2.6.32-5 et 2.6.32-3 (je n’ai pas noté les versions exactes de ces paquets) qui ne fonctionnent plus après les dernières mises à jour. Néanmoins le noyau linux-image-2.6.32-2-686-bigmem en version 2.6.32-8 fonctionne bien (en montage RAID).
A ce sujet, une leçon à retenir : lorsque le système plante après grub, penser à tester tous les noyaux disponibles (il est intéressant de garder au moins 3 ou 4 noyaux disponibles sous grub en cas de souci de démarrage avec l’un d’entre eux).
Je n’en ai testé que deux (les plus récents : 2.6.32-5 et 2.6.32-3), ai constaté que le système plantait (message répété : « /bin/sleep : not found » suivi d’un shell simplifié), que le répertoire ‘/dev/disk/by-uuid’ n’existait pas (grâce à grub, on peut à présent naviguer et saisir des commandes dans ce shell même si le disque principal n’est pas monté. J’ai alors pensé à un bogue du paquet libuuid1 faisant parti de la mise à jour et ai donc abandonné la piste du noyau foireux, en n’effectuant mes autres tests qu’avec le noyau 2.6.32-5.
Grosse erreur :)) Si j’avais été plus loin dans mon essai, j’aurai vu que le 2.6.32-2 (celui que j’utilise en ce moment-même) situé juste en dessous dans le menu de grub fonctionnait bien !
Ça m’aurait évité une réinstallation (pour tests) de plusieurs versions de libuuid1, de grub (foireuse, qui m’a donné là aussi du fil à retordre), des sysv* et des libc …
– des choses que j’avais déjà appris mais oublié.
Une révision sur la syntaxe des options des commandes apt et dpkg :))
– mémo pour moi pour une prochaine fois éventuelle :) :
– pour changer une version de libc, l’ordre de mise à jour avec dpkg est le suivant : libc-bin > libc-dev-bin > libc6 > libc6-dev > locales.
– pour retrouver le réseau, lancer successivement les commandes ‘ifconfig eth0 192.168.0.2 netmask 255.255.255.0 up’ et ‘route add -net default netmask 0.0.0.0 gw 192.168.0.3 dev eth0
– en cas de soucis avec les locales,
mon fichier /etc/environment contient :
LANG= »fr_FR.UTF-8″
LANGUAGE= »fr_FR »
mon fichier /etc/default/locale contient :
LANG=fr_FR.UTF-8
lancer la commande dpkg-reconfigure locales puis choisir fr_FR.UTF-8 UTF-8, pour « jeu de paramètres régionaux actif par défaut » prendre fr_FR.UTF-8
Pour tester si le problème est résolu, lancer : ‘perl -v’ (les messages doivent avoir disparu).
– la mise à jour des paquets demande souvent de pouvoir afficher un menu avec des choix.
Si vous aviez choisi un terminal graphique (kde ou gnome) par défaut, s’il ne peut accéder à ce terminal, en principe il bascule automatiquement sur un terminal texte. Dans mon cas, pour une raison X (probablement liée à des paquets laissés non configurés), il n’y est pas parvenu, du coup la boîte de dialogue n’apparaissait pas, laissant le paquet dans une configuration inconnue.
L’éditeur nano a lui aussi besoin d’un terminal spécifique. S’il n’y arrive pas avec le terminal courant, il affiche le message « Unknown terminal : bterm ».
La solution est toute simple : saisir ‘TERM=vt100;export TERM’.
Ensuite faire un ‘dpkg-reconfigure debconf’ et choisir l’interface Dialogue pour régler le problème de manière durable.
– last but not least : il vaut mieux effectuer le chroot à partir du menu dédié du netinstall Debian que de le faire manuellement comme je le faisais précédemment (voir ci-dessous : 63ème révision).
Lorsque le netinstall Debian démarre, aller dans les menus : Advanced options > Rescue mode > (choix du disque de démarrage sur lequel il va chrooter, exemple : /dev/sda1) > Exécuter un shell dans /dev/sda1.
En effet dans le cas d’une réinstallation de grub (test que j’ai souhaité effectuer vu mes doutes), un chroot manuel a conduit à un plantage de grub car il ne trouvait pas de périphérique disponible dans ce chroot (il y a des techniques pour qu’il reconnaisse des liens dynamiques d’après ce que j’ai lu, mais çà m’a semblé compliqué).
Alors qu’avec le chroot effectué via ce menu ‘Rescue mode’, cette réinstallation de grub s’est passée sans encombres.