/dev plein qui empêche la mise à jour du kernel

Bonjour,
Depuis quelques jours j’essaye de mettre à jour ma debian (bullseye - amd64) à jour, mais l’installation du kernel échoue :

pigz: abort: write error on <stdout> (No space left on device)
E: mkinitramfs failure cpio 141 pigz 28
update-initramfs: failed for /boot/initrd.img-4.19.0-17-amd64 with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: erreur de traitement du paquet linux-image-4.19.0-17-amd64 (--configure) :
 installed linux-image-4.19.0-17-amd64 package post-installation script subprocess returned error exit status 1
Traitement des actions différées (« triggers ») pour initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-17-amd64
[...]
pigz: abort: write error on <stdout> (No space left on device)
E: mkinitramfs failure cpio 141 pigz 28
update-initramfs: failed for /boot/initrd.img-4.19.0-17-amd64 with 1.
dpkg: erreur de traitement du paquet initramfs-tools (--configure) :
 installed initramfs-tools package post-installation script subprocess returned error exit status 1
Des erreurs ont été rencontrées pendant l'exécution :
 linux-image-4.19.0-17-amd64
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

et en effet :

nicolas@astor:~$ df -Th
Sys. de fichiers           Type     Taille Utilisé Dispo Uti% Monté sur
udev                       devtmpfs   8,8G       0  8,8G   0% /dev
[...]

pourtant, que ce soit avec baobab ou ncdu, ou encore find, je n’y vois que quelques petits fichiers.
Et sudo du -hcs /dev/ indique 0.

Auriez-vous une idée de ce que je peux faire ?

Merci d’avance ^^

Bonjour ncarrier

Bienvenue sur ce forum :slight_smile:

Il y a erreur d’interprétation,
en fait, c’est 0Ko utilisés <=> tout l’espace est disponible

De plus tmpfs n’occupe aucun espace disque :


Ça serait pas plutôt dans le système de fichiers contenant /boot/ qu’il manquerait de la place ?

Voir : https://github.com/Feliz-SZK/Linux-Decoded/blob/master/Fix%20mkinitramfs%20failure%20cpio%20141%20pigz%2028.md

2 J'aime

Et il faut donc donner le retour complet de :

df -Th
1 J'aime

woyoyoye !
Je ne devais pas être réveillé, en effet, /dev n’est pas le soucis, c’est bien /boot/.
Du coup, en ne gardant plus que deux kernels, tout passe.
Par contre, je ne sais pas ce que j’ai fichu à mettre une partition /boot de 240Mo, c’est vraiment pas assez :confused:.

Merci beaucoup pour le dépannage !

C’est suffisant si tu penses à lancer apt autoremove après les mises à jour du noyau.

En fait si, car le contenu d’un tmpfs peut être mis en swap, donc sur disque.
Extrait de Documentation/filesystems/tmpfs.txt de la documentation du noyau :

tmpfs puts everything into the kernel internal caches and grows and
shrinks to accommodate the files it contains and is able to swap
unneeded pages out to swap space.

Il me semble qu’il n’y a pas si longtemps c’était (et c’est peut-être encore) la taille par défaut décidée par le partitionnement assisté lorsqu’il crée une partition /boot séparée. C’est effectivement trop peu pour les noyaux et initramfs actuels qui ne cessent de grossir à chaque nouvelle version.

Pas forcément car autoremove n’agit qu’après qu’un nouveau noyau a été installé, ce qui ne sert à rien si l’espace est insuffisant pour installer ce noyau.

S’il n’est pas possible ou difficile d’agrandir la partition /boot (on peut réduire la partition EFI qui est souvent surdimensionnée) quand elle existe), il existe quelques astuces pour réduire la taille des initramfs.

  • remplacer MODULES=most par MODULES=dep dans /etc/initramfs-tools/initramfs.conf et reconstruire les initramfs avec

    update-initramfs -u -k all
    
  • désinstaller plymouth (le « splash screen » de démarrage)

On peut aussi rapatrier le contenu de /boot dans le système de fichiers racine s’il n’y a pas de nécessité de /boot séparé (BIOS buggé ou racine chiffrée). L’installateur crée une partition /boot séparée quand on utilise le partitionnement assisté avec LVM, mais ce n’est pas indispensable.