J'arrive pas à vider /lib pour une mise à jour du noyau
6 réponses
kaliderus
Le bonjour,
Je me trouve dans une situation que je n'explique pas.
En stable, amd64 :
Lorsque j'installe les mises =C3=A0 jour de s=C3=A9curit=C3=A9 (ou autre), =
tout se passe bien.
Seulement pour le noyau, impossible, j'ai syst=C3=A9matiquement 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=C3=A9es extraites pour =C2=AB
./lib/modules/3.16.0-6-amd64/kernel/fs/ext4/ext4.ko =C2=BB vers =C2=AB
/lib/modules/3.16.0-6-amd64/kernel/fs/ext4/ext4.ko.dpkg-new =C2=BB : =C3=A9=
chec
d'=C3=A9criture (Aucun espace disponible sur le p=C3=A9riph=C3=A9rique)
dpkg-deb : erreur : le sous-processus coller a =C3=A9t=C3=A9 tu=C3=A9 par l=
e signal
(Relais bris=C3=A9 (pipe))
Des erreurs ont =C3=A9t=C3=A9 rencontr=C3=A9es pendant l'ex=C3=A9cution :
/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=C3=A9e pour continuer.
J'ai supprimer un maximum de paquets/applis qui ne me servent
qu'occasionnellement (soit =C3=A0 la main, soit avec deborphan) en esp=C3=
=A9rant
faire de la place dans /lib mais rien n'y fait, c'est comme si le
syst=C3=A8me de fichier refusait de r=C3=A9-allouer l'espace lib=C3=A9r=C3=
=A9...
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=C3=A9 Dispo Uti% Mont=C3=A9 sur
/dev/dm-1 453M 415M 11M 98% /
J'ai fais un fsck du syst=C3=A8me de fichier (en fait tous les syst=C3=A8me
pr=C3=A9sent sur ma machine) et rien trouv=C3=A9 non plus d'anormal.
J'avoue que je suis un peu perdu.
Si quelqu'un peut me montrer le chemin de l'id=C3=A9e kivabien.
Merci.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
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.
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.
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 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.
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.
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 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
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:
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):
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:
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
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.
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.
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 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
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).
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 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.
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.
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.
