J'arrive pas à vider /lib pour une mise à jour du noyau

Le
kaliderus
Le bonjour,

Je me trouve dans une situation que je n'explique pas.

En stable, amd64 :
Lorsque j'installe les mises à jour de sécurité (ou autre), =
tout se passe bien.
Seulement pour le noyau, impossible, j'ai systématiquement le message =
d'erreur :

dpkg: erreur de traitement de l'archive
/var/cache/apt/archives/linux-image-3.16.0-6-amd64_3.16.56-1+deb8u1_amd64.d=
eb
(--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)
dpkg-deb : erreur : le sous-processus coller a été tué par l=
e signal
(Relais brisé (pipe))
Des erreurs ont été rencontrées pendant l'exécution :
/var/cache/apt/archives/linux-image-3.16.0-6-amd64_3.16.56-1+deb8u1_amd64.=
deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package. Trying to recover:
Appuyez sur Entrée pour continuer.

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=

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% /

J'ai fais un fsck du système de fichier (en fait tous les système
présent sur ma machine) et rien trouvé non plus d'anormal.

J'avoue que je suis un peu perdu.
Si quelqu'un peut me montrer le chemin de l'idée kivabien.
Merci.
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #26475893
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.
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.
Pascal Hambourg
Le #26476006
Le 23/05/2018 à 09:13, kaliderus a écrit :
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.

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.

Qu'est-ce qui n'est pas clair dans ce que j'ai expliqué ci-dessus ?
Pour faire une mise à jour d'un paquet, il faut disposer d'un espace
libre égal à la taille occupée par le paquet. Il faut donc 160 Mio
libres pour mettre à jour le noyau. Cet espace sera occupé
temporairement pendant la mise à jour pour installer les fichiers de la
nouvelle version du paquet puis libéré à la fin de la mise à jour
lorsque les fichiers de l'ancienne version du paquet seront supprimés.
Paul Ezvan
Le #26476123
Le 23/05/2018 14:40, Pascal Hambourg a écrit :
Le 23/05/2018 à 09:13, kaliderus a écrit :
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.

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.

Qu'est-ce qui n'est pas clair dans ce que j'ai expliqué ci-dessus ?
Pour faire une mise à jour d'un paquet, il faut disposer d'un espace
libre égal à la taille occupée par le paquet. Il faut donc 160 Mio
libres pour mettre à jour le noyau. Cet espace sera occupé
temporairement pendant la mise à jour pour installer les fichiers de
la nouvelle version du paquet puis libéré à la fin de la mise à jour
lorsque les fichiers de l'ancienne version du paquet seront supprimés.

À noter qu'une "mise à jour" du noyau est différente d'une mise à jour
d'un paquet standard, puisque généralement c'est un nouveau paquet qui
est installé, et donc le nouveau noyau consomme de la place en plus même
après que apt ait terminé la mise à jour.
Peut-être as-tu des noyaux installés dont tu n'as plus besoin ?
Pour un noyau ce qui prend de la place dans /lib ce sont les modules, le
noyau lui-même étant installé dans /boot (qui est soumis au même
problème en cas de petite partition /boot).
Par exemple sur mon système j'ai pas mal de noyau installés on dirait:
% ls -l /lib/modules
total 24K
drwxr-xr-x 3 root root 4,0K oct. 2 2017 3.16.0-4-amd64/
drwxr-xr-x 2 root root 4,0K oct. 2 2017 3.2.0-4-amd64/
drwxr-xr-x 2 root root 4,0K mars 4 17:56 4.9.0-3-amd64/
drwxr-xr-x 2 root root 4,0K mars 4 17:56 4.9.0-4-amd64/
drwxr-xr-x 3 root root 4,0K janv. 7 02:35 4.9.0-5-amd64/
drwxr-xr-x 3 root root 4,0K mai 6 00:01 4.9.0-6-amd64/
Tu peux trouver la taille occupée par chaque répertoire:
% du -h --max-depth=1 /lib/modules
163M /lib/modules/3.16.0-4-amd64
3,9M /lib/modules/4.9.0-4-amd64
2,9M /lib/modules/3.2.0-4-amd64
185M /lib/modules/4.9.0-5-amd64
188M /lib/modules/4.9.0-6-amd64
3,9M /lib/modules/4.9.0-3-amd64
546M /lib/modules
On remarque que certains prennent peu de place, en fait ces noyaux ont
été désinstallés mais il reste les fichiers générés par la commande
depmod (non contenus dans le paquet, générés par un script
post-install):
% ls /lib/modules/3.2.0-4-amd64
modules.alias modules.alias.bin modules.builtin.bin modules.dep
modules.dep.bin modules.devname modules.softdep modules.symbols
modules.symbols.bin
% uname -r
4.9.0-5-amd64
Le noyau courant est le 4.9.0-5-amd64, donc je peux probablement
désinstaller le noyau 3.16.0-4-amd64 pour faire de la place. Pour cela
je dois spécifier la version à supprimer:
% sudo apt remove linux-image-3.16.0-4-amd64
Paul
Pascal Hambourg
Le #26476159
Inutile de me mettre en copie, je lis la liste.
Le 24/05/2018 à 20:42, Paul Ezvan a écrit :
À noter qu'une "mise à jour" du noyau est différente d'une mise à jour
d'un paquet standard, puisque généralement c'est un nouveau paquet qui
est installé

Généralement une mise à jour du noyau Debian stable est une mise à jour
du paquet linux courant, pas un nouveau paquet. Les exceptions sont une
mise à niveau de la distribution et un changement d'ABI. La situation
actuelle où il y a eu plusieurs changements d'ABI en peu de temps est
exceptionnelle.
Pour un noyau ce qui prend de la place dans /lib ce sont les modules, le
noyau lui-même étant installé dans /boot

Le modules font partie du noyau, ce qui est dans /boot n'est que l'image
du noyau. Le tout est installé par un même paquet.
Paul Ezvan
Le #26476222
Le 24/05/2018 à 15:17, Pascal Hambourg a écrit :
Inutile de me mettre en copie, je lis la liste.

Je n'ai pas fait attention, c'est malheureusement le comportement par
défaut de Roundcube pour répondre à une liste.
Généralement une mise à jour du noyau Debian stable est une mise à
jour du paquet linux courant, pas un nouveau paquet. Les exceptions
sont une mise à niveau de la distribution et un changement d'ABI. La
situation actuelle où il y a eu plusieurs changements d'ABI en peu de
temps est exceptionnelle.

Tu parles d'ABI interne ou externe ? Mon impression est qu'à chaque fois
que le noyau est recompilé il faut aussi recompiler les modules, donc
avoir une ABI interne stable me semble difficile. Pourquoi cette
situation exceptionnelle ?
Mettre à jour le paquet pour le noyau est risqué, car il faut être sûr
que les nouveaux modules peuvent être chargé par le noyau courant, et je
ne suis pas sûr qu'il soit possible de le garantir.
Le modules font partie du noyau, ce qui est dans /boot n'est que
l'image du noyau. Le tout est installé par un même paquet

Bien sûr, mais les modules dans /lib peuvent aussi être fournis par
d'autres paquets (pilotes divers) et même construit à partir de sources
différentes (module nvidia par exemple).
Paul
Pascal Hambourg
Le #26476229
Le 25/05/2018 à 18:30, Paul Ezvan a écrit :
Le 24/05/2018 à 15:17, Pascal Hambourg a écrit :
Généralement une mise à jour du noyau Debian stable est une mise à
jour du paquet linux courant, pas un nouveau paquet. Les exceptions
sont une mise à niveau de la distribution et un changement d'ABI. La
situation actuelle où il y a eu plusieurs changements d'ABI en peu de
temps est exceptionnelle.

Tu parles d'ABI interne ou externe ?

Interne. L'ABI externe du noyau est stable. Le contraire obligerait à
recompiler les binaires exécutables et les bibliothèques à chaque
nouvelle version du noyau.
Mon impression est qu'à chaque fois
que le noyau est recompilé il faut aussi recompiler les modules, donc
avoir une ABI interne stable me semble difficile. Pourquoi cette
situation exceptionnelle ?

C'est un choix de conception.
Bien qu'il puisse être modulaire, Linux est un noyau monolithique
notamment pour des raisons de performance d'après ce que j'ai compris.
Et les developpeurs et mainteneurs du noyau ne veulent probablement pas
être bridés en étant forcés de conserver une compatibilité avec des
modules externes. Leur mot d'ordre a toujours été : si vous écrivez du
code pour le noyau, faites en sorte qu'il soit intégré une fois pour
toutes aux sources officielles du noyau plutôt que de vous embêter à
l'adapter aux changements du noyau.
Mettre à jour le paquet pour le noyau est risqué, car il faut être sûr
que les nouveaux modules peuvent être chargé par le noyau courant, et je
ne suis pas sûr qu'il soit possible de le garantir.

En effet, pas en cas de changement d'ABI (installation d'un nouveau
paquet linux-image). Il faut redémarrer avec la nouvelle image du noyau.
De toute façon il faut toujours le faire au plus vite après une mise à
jour du noyau. Par contre s'il y a mise à jour sans changement d'ABI
(mise à jour du même paquet linux-image), les nouveaux modules devraient
fonctionner avec le noyau actuel.
Le modules font partie du noyau, ce qui est dans /boot n'est que
l'image du noyau. Le tout est installé par un même paquet

Bien sûr, mais les modules dans /lib peuvent aussi être fournis par
d'autres paquets (pilotes divers)

Un exemple de module binaire fourni par un paquet Debian ?
et même construit à partir de sources
différentes (module nvidia par exemple).

Exact, donc /lib peut contenir des modules qui ne viennent pas du paquet
du noyau.
Publicité
Poster une réponse
Anonyme