Comment résoudre une mise à jour noyau incomplète ? (affaire à suivre)

Support Debian
,
Tags: #<Tag:0x00007fc9f0197fa0> #<Tag:0x00007fc9f0197c80>
#1

Bonjour à tous,

Tout est dans l’ intitulé.
Lors d’ une install party (qui durait une matinée ), une newbie est venu me voir (avec Linuxmint sur un portable) pour résoudre un problème que je n’ ai pas su solutionné …

Ma newbie avait procédé à une mise à jour du noyau et n’ avait pas pu terminer l’ upgrade suite à une coupure de courant.
Sa partition "/boot " était visiblement pleine à ras bord, elle n’ avait pas supprimé
les anciens kernel.
Je ne me rappelle plus exactement la config de ses partitions, mais je me souviens quelle avait une partition cryptée dédiée à windows seven, une linux-swap, ext4 et une partition “/boot”.
J’ ai tenté tout c’ qui était possible, mais rien à faire, quelle que soit mes tentatives,
que ce soit " autoremove ", install, etc, rien à faire, le dernier noyaux bloquait tout.
J’ aurai souhaité passer par un live CD, histoire de supprimer 2 ou 3 anciens kernel,( il y en avait visiblement encore au moins 6 ou 7 )pour libérer de la place, puis terminer la mise à jour du dernier noyau …?
Histoire d’ avoir la solution, au cas ou le problème se répète, afin de ne pas passer
pour un c…, quelqu’ un a-t-il une proposition …?

                          @+
#2

Salut

je ne m’interdis pas de supprimer manuellement des noyaux dans /boot et ne laisser que les noyaux dont je suis certain qu’ils démarrent

exemple

 ls -alrt /boot
total 94508
-rw-r--r--  1 root root   184840 juin  25  2015 memtest86+_multiboot.bin
-rw-r--r--  1 root root   182704 juin  25  2015 memtest86+.bin
-rw-r--r--  1 root root  4982544 mai   27 14:05 vmlinuz-4.16.0-2-amd64
-rw-r--r--  1 root root  3139948 mai   27 14:05 System.map-4.16.0-2-amd64
-rw-r--r--  1 root root   203169 mai   27 14:05 config-4.16.0-2-amd64
-rw-r--r--  1 root root 42295278 juin   9 15:02 initrd.img-4.16.0-2-amd64
-rw-r--r--  1 root root  4221216 juin  10 14:44 vmlinuz-4.9.107-kernelperso
-rw-r--r--  1 root root  3188038 juin  10 14:44 System.map-4.9.107-kernelperso
-rw-r--r--  1 root root   186391 juin  10 14:44 config-4.9.107-kernelperso
-rw-r--r--  1 root root 34749261 juin  10 15:44 initrd.img-4.9.107-kernelperso
-rw-r--r--  1 root root  3402103 juin  13 18:26 initrd-plymouth.img
drwxr-xr-x 25 root root     4096 juin  14 12:08 ..
drwxr-xr-x  3 root root     4096 juin  14 12:15 .
drwxr-xr-x  5 root root     4096 juin  14 12:15 grub

il faut par noyau
1 config
1 initrd
1 System.map
1 vmlinuz

puis reconstruire grub

sudo update-grub

quand des paquets sont coincés je commence par

dpkg --audit

Qui fait le point et donne souvent des recommandations intéressantes

#3

Bonjour grandtoubab,

Merci de me répondre.

je ne m’interdis pas de supprimer manuellement des noyaux dans /boot

Peux-tu être plus explicite ?
Comment procèderais-tu ?

#4

J’ ai oublié de préciser que l’ on pouvait booter, mais qu’ il était impossible
d’ utiliser le terminal ou synaptic pour faire quoi que ce soit, autrement dit
impossible de supprimer ou d’ installer quoi que ce soit une fois la session ouverte,
encore moins de procéder à une mise à jour …

#5

meme en selectionnant recovery mode dans grub? pour se connecter en mode console?

#6

Peut-être vérifier l’espace disque ? df

#7

Bonjour grandtoubab , bonjour PengouinPdt,

Décidément, faut que j’ précise encore mon propos.
Je n’ ai plus le PC.

Je n’ ai pas pu atteindre le " recovery mode dans grub ", because j ’ n’ ai pas tenté.
En recovery mode, en temps normal, j’ aurais fait:

dpkg --get-selections|grep ‘linux-image*’|awk ‘{print $1}’|egrep -v “linux-image-$(uname -r)|linux-image-generic” |while read n;do apt-get -y remove $n;done

Cette commande aurait supprimé tous les vieux kernel et aurait permis de ne garder que le dernier, mais justement, celui-ci me bloquait et en plus, elle n’ avait qu’ une session, avec tous les droits, fait c …

En temps normal, j’ aurais pu aussi générer une commande de suppression des anciens noyau en sachant que la commande head -n 2 permet de garder les 2 derniers noyau :

ls -rt /boot/vmlinuz-* | head -n -2 | sed ‘s@vmlinuz-@linux-image-@g’ | sed ‘s@/boot/@@’ | xargs -I {} apt-get remove -y {}

Mais j’ n’ ai pas tenté mes commandes, because j’ avais, je l’ avoue, la crainte de faire une bêtise qui aurait peut-être eu des conséquences plus que désagréables …
Je voulais lui éviter une réinstall.

L’ environnement était sous " cinnamon " et j’ n’ ai eu l’ idée d’ utiliser un livecd qu’ a la fin de la matinée, après avoir tenté pas mal de bidouille, lorsque j’ ai compris c’ qui bloquait, lorsque mon interlocutrice m’ a enfin expliqué ce qui lui était arrivé, comment elle avait tenté de faire la mise à jour par le biais du terminal et après qu’ elle ait procédé à ses propres tentatives.
Pas d’ bol pour ma pomme, c’ est tombé sur moi. Les copains ont bien rigolé, pas moi.

Ce que je souhaiterai savoir, c’ est connaitre les protocoles à suivre si l’ incident se répète lors d’ une prochaine install.

Par le passé, mes 2 commandes ont fonctionné, mais sur des PC ou la partition boot était simplement saturé et n’ acceptaient plus de nouveaux kernel.

Pour ce qui était de l’ espace disque, sa session était vide, il y avait de l’ espace à gogo.

Après réflexion, j’ me suis dit que j’ aurais peut-être dû utilisé gparted, histoire d’ agrandir sa partition boot, par exemple, puis reboot en mode normal, tenter un upgrade et peut-être que tout serait rentré dans l’ ordre, par exemple …?

Existe-t-il une ou plusieurs solutions simples et efficaces pour résoudre ce problème et si oui comment faire ?

#8

Dans Debian il y a un excellent script

/etc/kernel/postinst.d/apt-auto-removal

qui permet de marquer les noyaux excédentaires et de marquer ceux à garder dans

/etc/apt/apt.conf.d/01autoremove-kernels

avant de faire

apt autoremove

Mais c’est pour Debian, qui gère ses noyaux raisonnablement pas pour ses dérivées genre Ubuntu qui gère et relivre ses noyaux à une cadence délirante pour une même version de noyau

#9

Bonjour grandtoubab,

Merci pour tes propositions.
Je f’ rais avec et si la situation se présente à nouveau,
je ferai part de ma solution à la communauté.
" A coeur vaillant rien d’ impossible ", enfin j’ espère …?

               @+
#10

On ne sait pas quelle est l’erreur précise qui bloque apt.
As-tu essayé de simplement désinstaller le noyau dont l’installation est en échec pour débloquer la situation ?

Si la cause racine du problème est simplement un manque d’espace disque sur la partition /boot à cause du trop grand nombre de noyaux installés, @grandtoubab t’a proposer de supprimer les fichiers dans /boot avec rm ou équivalent, pas de désinstaller les noyaux avec apt ou dpkg. C’est sale et on ne devrait supprimer des fichiers appartenant à un paquet Debian qu’en dernier recours.

Je propose une autre méthode plus propre : il faut savoir que c’est l’initramfs (fichier initrd.img-*) qui occupe le plus de place, et que ce fichier ne fait pas partie du paquet linux-image-*, il est seulement construit par l’invocation de update-initramfs -c -k <version> lors de l’installation du paquet. On peut le supprimer sans porter atteinte au paquet, et on peut même le faire “offciellement” avec

update-initramfs -d -k <version>

Si nécessaire on pourra le recréer avec -c au lieu de -d.
Evidemment, il ne faut pas supprimer l’initramfs du noyau actif (uname -a).

#11

Bonjour PascalHambourg,

Merci pour ta contribution, c 'est noté.

              @+