# /dev plein qui empêche la mise à jour du kernel **URL:** \ **Category:** Support Debian\ **Created:** [Juin 28, 2021, 2:12 UTC](https://www.debian-fr.org/t/dev-plein-qui-empeche-la-mise-a-jour-du-kernel/84876 "2021-06-28T14:12:21Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![ncarrier](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/ecc23a/32.png) [@ncarrier](https://www.debian-fr.org/u/ncarrier)\ **Post date:** [Juin 28, 2021, 2:12 UTC](https://www.debian-fr.org/t/dev-plein-qui-empeche-la-mise-a-jour-du-kernel/84876/1 "2021-06-28T14:12:21Z")
Bonjour, Depuis quelques jours j’essaye de mettre à jour ma debian (bullseye - amd64) à jour, mais l’installation du kernel échoue : ```auto pigz: abort: write error on (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 (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 : ```auto 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 ^^ ---
**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\ **Post date:** [Juin 28, 2021, 2:21 UTC](https://www.debian-fr.org/t/dev-plein-qui-empeche-la-mise-a-jour-du-kernel/84876/2 "2021-06-28T14:21:17Z")
Bonjour [**ncarrier**](https://www.debian-fr.org/u/ncarrier) Bienvenue sur ce forum 🙂 > [@ncarrier](#): > > … > et en effet : > > ```auto > nicolas@astor:~$ df -Th > Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur > udev devtmpfs 8,8G 0 8,8G 0% /dev > [...] > > ``` > > … 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 : > [@Wikipedia tmpfs](#): > > **tmpfs** is a [temporary file](https://en.wikipedia.org/wiki/Temporary_file) storage paradigm implemented in many [Unix-like](https://en.wikipedia.org/wiki/Unix-like) operating systems. It is intended to appear as a mounted [file system](https://en.wikipedia.org/wiki/File_system), but data is stored in [volatile memory](https://en.wikipedia.org/wiki/Volatile_memory) instead of a persistent storage device. A similar construction is a [RAM disk](https://en.wikipedia.org/wiki/RAM_disk), which appears as a virtual disk drive and hosts a [disk file system](https://en.wikipedia.org/wiki/Disk_file_system). * * * Ça serait pas plutôt dans le système de fichiers contenant **`/boot/`** qu’il manquerait de la place ? Voir : [Linux-Decoded/Fix mkinitramfs failure cpio 141 pigz 28.md at master · Feliz-SZK/Linux-Decoded · GitHub](https://github.com/Feliz-SZK/Linux-Decoded/blob/master/Fix%20mkinitramfs%20failure%20cpio%20141%20pigz%2028.md) ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 28, 2021, 4:51 UTC](https://www.debian-fr.org/t/dev-plein-qui-empeche-la-mise-a-jour-du-kernel/84876/3 "2021-06-28T16:51:40Z")
Et il faut donc donner le retour complet de : ```auto df -Th ``` ---
**Author:** ![ncarrier](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/ecc23a/32.png) [@ncarrier](https://www.debian-fr.org/u/ncarrier)\ **Post date:** [Juin 29, 2021, 10:16 UTC](https://www.debian-fr.org/t/dev-plein-qui-empeche-la-mise-a-jour-du-kernel/84876/4 "2021-06-29T10:16:01Z")
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 😕. Merci beaucoup pour le dépannage ! ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 29, 2021, 10:43 UTC](https://www.debian-fr.org/t/dev-plein-qui-empeche-la-mise-a-jour-du-kernel/84876/5 "2021-06-29T10:43:32Z")
> [@ncarrier](#): > > Par contre, je ne sais pas ce que j’ai fichu à mettre une partition /boot de 240Mo, c’est vraiment pas assez C’est suffisant si tu penses à lancer` apt autoremove` après les mises à jour du noyau. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Juin 29, 2021, 11:38 UTC](https://www.debian-fr.org/t/dev-plein-qui-empeche-la-mise-a-jour-du-kernel/84876/6 "2021-06-29T11:38:16Z")
> [@anon29980398](#): > > **`tmpfs`** n’occupe aucun espace disque 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. > [@ncarrier](#): > > une partition /boot de 240Mo, c’est vraiment pas assez 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. > [@anon70622873](#): > > C’est suffisant si tu penses à lancer ` apt autoremove` après les mises à jour du noyau. 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 - 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.