Historique des dysfonctionnements sérieux survenus

Historique des dysfonctionnements sérieux survenus

Cette page récapitule les incidents sérieux survenus sur ma distribution Debian Sid, puis Testing, depuis Juin 2016.

Son intérêt ?

Tracer ces incidents pour offrir un aperçu des soucis sérieux pouvant survenir sur ce type de distribution.
Debian stable mérite son nom, Debian Sid et Testing sont les versions en préparation (future Stable) un peu moins stables mais bien plus récentes. Personnellement j’en ai l’utilité pour les compilations et tests de logiciels récents.

Les bugs sont rares, mais peuvent être sérieux. À réserver à ceux dont la ligne de commande ne fait pas peur.

Historique :

Debian 32-bit :

  • j’ai évité de peu un gros plantage avec udev 232-1 le 4 novembre 2016, mais le dysfonctionnement du paquet était signalé par une erreur à l’installation
  • j’ai évité de peu un gros plantage à la mise à jour (mise à jour importante) de mon PC relié à internet le 7 décembre 2017 suite au plantage de Synaptic. Après la mise à jour de nombreux paquets (vraisemblablement une centaine, voir davantage) sur ce PC, synaptic était devenu complètement léthargique. Dans la liste il y avait des paquets importants tel que libc6. Je l’ai laissé poursuivre une nuit complète et l’ai retrouvé dans le même état le lendemain. La solution aura été de fermer brutalement Synaptic (par un kill -9 en console) et de lancer en console un « # dpkg –configure -a », suivi d’un « # apt-get -f install » pour terminer manuellement la configuration avant de redémarrer. Le redémarrage suivant a très bien fonctionné. Cela m’a servi de leçon, et aujourd’hui je ne lance plus de très grosses mises à jour avec Synaptic (par exemple avec un système pas mis à jour depuis quelques mois) : il est bien plus fiable de lancer en console un « # apt update » suivi d’un « # apt upgrade ». J’utilise Synaptic tous les jours, mais pour de petites à moyennes mises à jour (quelques dizaines de paquets au maximum).
  • j’ai évité de peu (par chance) un gros plantage le 5 Janvier 2018, suite à un dysfonctionnement probable de la création des ramdisks (fichiers /boot/initrd.img-version_noyau) après la mise à jour de bibliothèques (e2fslibs, e2fsprogs, libc-bin, libc-dev-bin, libc6, libc6-x32, multiarch-support), ce qui s’est traduit de la manière suivante :
    • le noyaux Linux 4.13.0-1-686-pae ne démarre plus (« kernel panic » au démarrage du système, alors qu’il fonctionnait jusque là, et que son fichier /boot/initrd.img viens d’être mis à jour) le 4.14.0-2-686-pae (fraîchement installé) ne fonctionne pas non plus (même message).
    • par chance, le noyau 4.12.0-1-686-pae fonctionne encore (son fichier /boot/initrd.img n’a heureusement pas été mis à jour).
    • le 7/1/2018, mise à jour de binutils & dérivés et du noyau linux en version linux-image-4.14.0-3-686-pae : ne marche toujours pas.
    • le 31/01/2018, mise à jour des paquets : binutils, binutils-common, binutils-dev, binutils-i686-linux-gnu, binutils-multiarch, libbinutils, libdbus-glib-1-2, libevdev2, libnss-systemd, libpam-systemd, libsystemd0, libudev1, systemd, systemd-sysv, udev.
      et là le noyau linux-image-4.14.0-3-686-pae fonctionne (ainsi que le noyau 4.12.0-1-686-pae), mais toujours pas le 4.13.0-1-686-pae.
  • le 16/05/2018, perte de la synchronisation des montages RAID de mes disques durs après la mise à jour de mdadm (en version 4.1~rc1-1) et dans le même temps, mise à jour automatique de Grub, et ce dernier ne trouve plus les montages RAID et ne parvient donc plus à mettre à jour son fichier de configuration. Là encore j’ai frisé la galère de me retrouver avec un système qui ne démarre plus (j’avais heureusement remarqué le message d’anomalie de Grub, noyé au milieu de nombreux autres messages informatifs, et ai donc pu agir avant le redémarrage de ma distribution).

Précisions : pour diminuer la fréquence des bugs liés aux mises à jour, j’avais bloqué sous Synaptic la mise à jour de certains paquets (et désinstallé le paquet unattended-upgrades, qui avait la fâcheuse tendance à mettre à jour les paquets bloqués), préférant contrôler moi-même leur installation, quand je l’estime opportun. J’ai ainsi bloqué les paquets suivants : le dernier noyau linux fonctionnel avec les paquets annexes de la même version (car il n’est pas si rare qu’une mise à jour désinstalle une version fonctionnelle pour installer une version mineure buguée, donc quand ça marche je bloque, « le mieux est souvent l’ennemi du bien »), mdadm (inutile de risquer une désynchronisation des disques pour une version mineure), tellico (la 3.1-0.3 fonctionne très bien et les mises à jour apportent peu de nouvelles fonctionnalités) et timidity (la dernière mise à jour avait coupé le son de ma Debian).

Debian 64-bit :

  • le 13/10/2018, après avoir installé une version minimaliste (netinstall à partir d’une clé USB) de la Debian Stable 9.5.0 sur des disques vierges, j’ai changé (avec l’éditeur nano) l’adresse des dépôts (dans /etc/apt/sources.list) pour que ma distribution puisse accéder aux paquets de la Debian Sid (l’idée était de ne pas perdre de temps à télécharger inutilement de nombreux paquets de la Stable pour les passer ensuite en Sid). Ensuite j’ai lancé la grosse cavalerie : l’installation de xserver-xorg, kde, gnome, mate, lxde, … et après 2-3h tout s’est terminé sans erreur affichée. Mais j’ai constaté que la commande apt ne fonctionnait plus (plutôt gênant sous Debian :). Le problème venait d’apt, utilisé pour la mise à jour, il était resté dans son ancienne version (en 1.4.8), au lieu de migrer lui-aussi dans sa version la plus récente (en 1.7.0). De ce fait, il ne parvenait plus à communiquer avec libapt-pkg5.0 (en 1.7.0).
  • le 10/03/2019 puis le 15/04/2019, gros plantage de mon système Debian : glitchs sous MATE puis freeze complet, même avec Ctrl Alt F1 impossible de le récupérer, boot du système (sans que je n’intervienne), avec perte de l’affichage aux démarrages suivants. J’ai fini par éteindre mon PC, l’ai laissé reposer (1/2h ?) puis plus tard je l’ai redémarré et l’affichage est revenu. Le problème était matériel, il venait à la fois d’un faux contact de la prise électrique reliant mon écran à l’onduleur (dont la batterie est hors d’usage, il ne me sert plus) doublé d’un souci avec ma carte graphique (mon ancienne carte graphique à repris du service).
  • le 17/06/2019, après un changement de matériel (carte graphique, carte mère, mémoire, processeur, mais j’ai conservé le reste, dont les disques durs), je tente de redémarrer sur mes anciens disques durs : ça ne démarre pas (j’espérais au moins voir démarrer le noyau Linux), le noyau ne trouve pas mes disques RAID (je pensais que les UUID lui permettrai de les retrouver efficacement mais ça n’a pas été le cas). Après différentes tentatives de démarrage du RAID et d’insertions de clés USB, je me rend compte que l’un de mes disques est vide et que l’autre (RAID) est visiblement en train de s’aligner dessus : j’ai perdu mon disque principal. Même si mon OS n’est vraisemblablement pas entièrement responsable, je considère qu’il en est à l’origine puisqu’il n’a pas été capable de retrouver seul les disques malgré leur numérotation en UUID et qu’ensuite il a été à l’origine de la suppression du disque de sauvegarde. Mais j’avoue que les circonstances exactes ne sont pas claires pour moi.
  • le 10/07/2019, mise à jour de Grub. Après un reboot, mon PC plante dès le démarrage sur « error: symbol ‘grub_file_filters’ not found. ». Même un chroot ne fonctionne pas, et les commandes basiques « ls » ou « mount » me renvoient un message de type « ls: error while loading shared libraries: libpcre2-8.so.0: cannot open shared object file: No such file or directory ». Pas moyen non plus de réinstaller le MBR avec un netinstall (il plantait). Finalement le souci a été résolu en écrasant le répertoire /boot/ par une sauvegarde. J’ai d’abord suspecté la dernière version de Grub, mais il se pourrait que le souci provienne de l’installation du MBR sur la partition /sda1 au lieu de /dev/sda (je l’ai ensuite copié aussi sur /dev/sda), ce qui peut dans certain cas particulier empêcher le système de trouver ce MBR (j’ai lu ça quelque-part). Mais dans ce cas, comment la simple copie du répertoire /boot/ a-t-elle résolue mon problème ? (là non plus c’est pas très clair :)). Tout ceci a sérieusement ébréché ma confiance dans Debian Sid.
  • le 01/08/2019 je suis passé à Debian Testing et ne met pas à jour tous les paquets – seulement ceux qui ont à minima 1 ou 2 versions d’écart.

Mon seuil de tolérance : dysfonctionnements éventuels (en Debian Sid/Testing c’est normal) et éventuellement plus d’interface graphique mais à minima le système démarre (au besoin sur un ancien noyau – qu’il faut toujours garder en réserve sous Grub), permet la saisie de commandes, l’accès aux données et à internet.