Oups... désolé les gars, j'aurai du répondre à la liste et pas en privé
Le 23 mai 2018 à 07:40, Pascal Hambourg <pas...@plouf.fr.eu.org> a écrit : > Le 22/05/2018 à 23:20, kaliderus a écrit : >> >> >> dpkg: erreur de traitement de l'archive >> >> /var/cache/apt/archives/linux-image-3.16.0-6-amd64_3.16.56-1+deb8u1_amd64.deb >> (--unpack) : >> impossible de copier les données extraites pour « >> ./lib/modules/3.16.0-6-amd64/kernel/fs/ext4/ext4.ko » vers « >> /lib/modules/3.16.0-6-amd64/kernel/fs/ext4/ext4.ko.dpkg-new » : échec >> d'écriture (Aucun espace disponible sur le périphérique) > > > Pas assez d'espace libre dans la racine. > >> J'ai supprimer un maximum de paquets/applis qui ne me servent >> qu'occasionnellement (soit à la main, soit avec deborphan) en espérant >> faire de la place dans /lib mais rien n'y fait, c'est comme si le >> système de fichier refusait de ré-allouer l'espace libéré... > > > La majorité des paquets installent le gros de leurs fichiers dans /usr. Si > /usr est séparé de la racine, cela n'influe pas sur l'occupation de cette > dernière. > >> En plus le fichier en question n'est pas bien gros : >> du -hs /lib/modules/3.16.0-6-amd64/kernel/fs/ext4/ext4.ko >> 898K /lib/modules/3.16.0-6-amd64/kernel/fs/ext4/ext4.ko >> >> Et j'ai suffisamment de place dans /lib : >> df -h /lib >> Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur >> /dev/dm-1 453M 415M 11M 98% / > > > Ce fichier est juste la goutte d'eau qui fait déborder le vase. Comme on > peut le voir dans le message d'erreur, dpkg copie d'abord tous les nouveaux > fichiers avec le suffixe temporaire .dpkg-new, et lorsque la copie est > complète, ils sont renommés et remplacent les anciens fichiers. En cas > d'erreur, les fichiers temporaires sont supprimés. Cela évite qu'une > interruption de la mise à jour laisse une partie des fichiers de la nouvelle > version du paquet et une partie des fichiers de la nouvelle version. La > contre-partie est qu'il faut disposer d'un espace libre égal à la taille > occupée par le paquet. Pour le noyau 3.16 de Jessie, c'est environ 160 Mio. > > 11 Mio est donc très insuffisant pour mettre à jour le noyau. Une taille de > 450 Mio est très faible pour une racine même avec /usr séparé. Mon premier > réflexe serait de faire du nettoyage sur la racine. Voir dans /root, /tmp et > /var si pas séparés. Désinstaller d'éventuels anciens noyaux. Ce que je n'explique pas c'est que l'espace qui sera utilisé n'a pas à augmenter, le message est clair sur ce point. Toutes les mise à jour (de noyau) se sont déroulées sans encombres jusqu'à présent. Mon partitionnement pour infos : df -h Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/dm-1 453M 415M 11M 98% / udev 10M 0 10M 0% /dev tmpfs 3,2G 9,4M 3,1G 1% /run /dev/dm-2 6,3G 5,2G 782M 88% /usr tmpfs 7,8G 167M 7,7G 3% /dev/shm tmpfs 5,0M 8,0K 5,0M 1% /run/lock tmpfs 7,8G 0 7,8G 0% /sys/fs/cgroup /dev/mapper/think-var 2,7G 910M 1,7G 36% /var /dev/mapper/think-tmp 360M 2,1M 335M 1% /tmp /dev/mapper/think-home 197G 186G 1,6G 100% /home /dev/sda2 229M 58M 160M 27% /boot /dev/sda1 487M 132K 486M 1% /boot/efi > > Ensuite j'envisagerais d'agrandir la racine si possible. C'est un volume > créé par le device-mapper, donc peut-être un volume logique LVM. Il est > assez facile d'agrandir un volume logique LVM. lvextend, resize2fs. > > En dernier recours, désinstaller le noyau actuel puis installer le nouveau > noyau. Précisément, c'est un remplacement pour une mise à jour de sécurité du noyau.
