Alors comme ça, on ne surveille pas son parc de machines ? Et on a laissé un peu trop longtemps ses bécanes installer automatiquement les mises à jour de sécurité, y compris les nouvelles versions de kernel?
Ainsi, à force de laisser-faire, les mises à jour ont fini par saturer la maigre partition « /boot ». En flinguant au passage la dernière mise à jour qui évidemment n’a pu aboutir. Oui, ça m’est arrivé aussi… looser.
Deux actions donc dans l’ordre : réparer les dégâts, puis faire en sorte que ça n’arrive plus.
Si cela a l’air facile dans le texte, pas si simple une fois les mains dans la console…
Diagnostic sur /boot
Il s’agit d’abord de se permettre de réparer la base de paquets APT. C’est le passage obligé pour continuer à installer et/ou mettre à jour sa distribution préférée.
Donc, on va artificiellement dé-saturer le contenu de /boot, si cette partition est à 100%.
stephane@maBecane:~$ ll /boot/ total 146020 drwxr-xr-x 4 root root 4096 janv. 20 09:12 ./ drwxr-xr-x 26 root root 4096 janv. 20 09:12 ../ -rw-r--r-- 1 root root 1165260 nov. 16 20:57 abi-3.13.0-70-generic -rw-r--r-- 1 root root 1165260 déc. 1 05:29 abi-3.13.0-71-generic -rw-r--r-- 1 root root 1165334 déc. 4 18:52 abi-3.13.0-73-generic -rw-r--r-- 1 root root 1165334 déc. 18 01:42 abi-3.13.0-74-generic -rw-r--r-- 1 root root 1165334 janv. 18 19:16 abi-3.13.0-76-generic -rw-r--r-- 1 root root 165763 nov. 16 20:57 config-3.13.0-70-generic -rw-r--r-- 1 root root 165763 déc. 1 05:29 config-3.13.0-71-generic -rw-r--r-- 1 root root 165763 déc. 4 18:52 config-3.13.0-73-generic -rw-r--r-- 1 root root 165763 déc. 18 01:42 config-3.13.0-74-generic -rw-r--r-- 1 root root 165763 janv. 18 19:16 config-3.13.0-76-generic drwxr-xr-x 3 root root 4096 janv. 20 09:12 extlinux/ drwxr-xr-x 5 root root 12288 janv. 20 09:12 grub/ -rw-r--r-- 1 root root 19221128 déc. 1 22:10 initrd.img-3.13.0-70-generic -rw-r--r-- 1 root root 19222732 déc. 2 09:21 initrd.img-3.13.0-71-generic -rw-r--r-- 1 root root 19222460 déc. 17 17:18 initrd.img-3.13.0-73-generic -rw-r--r-- 1 root root 19221735 déc. 19 14:49 initrd.img-3.13.0-74-generic -rw-r--r-- 1 root root 19222215 janv. 20 09:12 initrd.img-3.13.0-76-generic -rw-r--r-- 1 root root 176500 mars 12 2014 memtest86+.bin -rw-r--r-- 1 root root 178176 mars 12 2014 memtest86+.elf -rw-r--r-- 1 root root 178680 mars 12 2014 memtest86+_multiboot.bin -rw------- 1 root root 3392660 nov. 16 20:57 System.map-3.13.0-70-generic -rw------- 1 root root 3392660 déc. 1 05:29 System.map-3.13.0-71-generic -rw------- 1 root root 3392888 déc. 4 18:52 System.map-3.13.0-73-generic -rw------- 1 root root 3392888 déc. 18 01:42 System.map-3.13.0-74-generic -rw------- 1 root root 3392888 janv. 18 19:16 System.map-3.13.0-76-generic -rw------- 1 root root 5823104 nov. 16 20:57 vmlinuz-3.13.0-70-generic -rw------- 1 root root 5823584 déc. 1 05:29 vmlinuz-3.13.0-71-generic -rw------- 1 root root 5825568 déc. 4 18:52 vmlinuz-3.13.0-73-generic -rw------- 1 root root 5825376 déc. 18 01:42 vmlinuz-3.13.0-74-generic -rw------- 1 root root 5825088 janv. 18 19:16 vmlinuz-3.13.0-76-generic
On le voit bien ci-dessus, trop de noyaux !
Opération désaturation
Pour artificiellement baisser l’occupation disque de ces gros fichiers, sans les faire disparaître, on va d’abord identifier quel noyau fait actuellement tourner le système
stephane@maBecane:~$ uname -r 3.13.0-71-generic
Dans l’exemple ci-dessus, on constate un décalage de plusieurs versions entre celle qui tourne (update 71), et la dernière installée a priori (update 76).
Premièrement NE PAS TOUCHER les fichiers du noyau qui est actif!!!
L’idée consiste à vider les fichiers intermédiaires pour libérer de la place. Pour chaque version de noyau, on trouve un initrd.img, un System.map et un vmlinuz qui prennent de la place: vidons-les, pour les versions qui ne nous intéressent plus ici (à savoir 70, 73, 74; on garde le 71 actif, et le petit dernier 76):
echo "" > /boot/initrd.img-3.13.0-70-generic echo "" > /boot/initrd.img-3.13.0-73-generic echo "" > /boot/initrd.img-3.13.0-74-generic echo "" > /boot/vmlinuz-3.13.0-70-generic echo "" > /boot/vmlinuz-3.13.0-73-generic echo "" > /boot/vmlinuz-3.13.0-74-generic echo "" > /boot/System.map-3.13.0-70-generic echo "" > /boot/System.map-3.13.0-73-generic echo "" > /boot/System.map-3.13.0-74-generic
Suite à cette opération, les fichiers ne pèsent plus qu’un octet chacun. Ça libère assez de place pour achever l’installation qui bloquait APT jusqu’à présent.
Remise au propre de la base APT
Pour rappel, la situation de saturation a forcément empêché la dernière opération de mise à jour automatique de s’achever correctement. On va forcer l’achèvement de l’installation de la mise à jour entamée:
apt-get -f install
Purge des vieux noyaux
Avec une base APT à nouveau saine, on peut purger proprement les vieux noyaux cette fois. La commande suivante permet de confirmer la liste des noyaux effectivement installés:
dpkg -l | grep linux
Puis, nettoyer ce dont on ne veut plus:
apt-get purge linux-image-3.13.0-70-generic linux-image-extra-3.13.0-70-generic apt-get purge linux-image-3.13.0-73-generic linux-image-extra-3.13.0-73-generic apt-get purge linux-image-3.13.0-74-generic linux-image-extra-3.13.0-74-generic apt-get purge linux-headers-3.13.0-70 linux-headers-3.13.0-70-generic apt-get purge linux-headers-3.13.0-73 linux-headers-3.13.0-74-generic apt-get purge linux-headers-3.13.0-73 linux-headers-3.13.0-74-generic
Et voilà….. 🙂
Ne plus voir ça
Visiblement, si j’en suis arrivé là, c’est que je ne surveillais pas assez ma machine. Il ne sert à rien de laisser les mises à jour de sécurité s’installer automatiquement si on ne surveille pas ce qui se passe.
Une méthode radicale, c’est d’assumer les mises-à-jour par soi-même. Et par conséquent de supprimer l’automatisme de ces mises-à-jour. Au moins, le /boot ne se remplira plus tout seul…
Pour supprimer la mise à jour automatique, il suffit d’éditer le fichier /etc/apt/apt.conf.d/10periodic
et d’y ajouter la ligne:
APT::Periodic::Unattended-Upgrade "0";
C’est fini. Vous pouvez reprendre une activité normale.