Re: Fwd: J'arrive pas à vider /lib pour une mise à jour 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.
Re: Fwd: J'arrive pas à vider /lib pour une mise à jour du noyau
Le 25 mai 2018 6:31 PM, "Paul Ezvan" a écrit : 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 Les dépendances sont normalement gérées en cohérence. construit à partir de sources différentes (module nvidia par exemple). Utiliser un module tiers augmente le risque, mais là encore le système de packaging veille au grain. Par exemple, le module gpu de nvidia est automatiquement mis à jour via des scripts de gestion (aka "hooks") déclenchés lors de la mise à jour. Paul Éric Dégenètais
Re: Fwd: J'arrive pas à vider /lib pour une mise à jour du noyau
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
Re: Fwd: J'arrive pas à vider /lib pour une mise à jour du noyau
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.
Re: Fwd: J'arrive pas à vider /lib pour une mise à jour du noyau
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 mai6 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
Re: Fwd: J'arrive pas à vider /lib pour une mise à jour du noyau
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 mai6 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
Re: Fwd: J'arrive pas à vider /lib pour une mise à jour du noyau
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.
Fwd: J'arrive pas à vider /lib pour une mise à jour du noyau
Oups... désolé les gars, j'aurai du répondre à la liste et pas en privé Le 23 mai 2018 à 07:40, Pascal Hambourg 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 453M415M 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-1453M415M 11M 98% / udev 10M 0 10M 0% /dev tmpfs3,2G9,4M 3,1G 1% /run /dev/dm-26,3G5,2G 782M 88% /usr tmpfs7,8G167M 7,7G 3% /dev/shm tmpfs5,0M8,0K 5,0M 1% /run/lock tmpfs7,8G 0 7,8G 0% /sys/fs/cgroup /dev/mapper/think-var2,7G910M 1,7G 36% /var /dev/mapper/think-tmp360M2,1M 335M 1% /tmp /dev/mapper/think-home 197G186G 1,6G 100% /home /dev/sda2229M 58M 160M 27% /boot /dev/sda1487M132K 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.
Fwd: J'arrive pas à vider /lib pour une mise à jour du noyau
Oups... désolé les gars, j'aurai du répondre à la liste et pas en privé (bis) Re, Le 23 mai 2018 à 02:01, Raphaël POITEVIN a écrit : > kaliderus writes: >> 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.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) >> dpkg-deb : erreur : le sous-processus coller a été tué par le 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. > > Quelle taille est annoncée après décompression ? Rien de rien, Les paquets suivants seront mis à jour : linux-image-3.16.0-6-amd64 1 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour. Il est nécessaire de prendre 0 o/34,5 Mo dans les archives. Après cette opération, 0 o d'espace disque supplémentaires seront utilisés. >> >> 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é... > > Ça n’aura pas d’impact. Les lib se mettent dans /usr/lib Mais pas que :-) /lib n'est pas vide, et le message est clair, apt veut coller le fichier dans cet emplacement. > >> 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 453M415M 11M 98% / > > 11Mo c’est pas beaucoup. Peut-être a-t-il besoin de décompresser > d’autres fichiers. Peut être, je ne connais pas assez bien le fonctionnement interne de dpkg >> >> 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. > > Essaie de faire avant un apt-get clean C'est fait (depuis un moment). Merci.
