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

2018-05-25 Par sujet 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.

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

2018-05-25 Par sujet Eric Degenetais 
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

2018-05-25 Par sujet 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

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

2018-05-24 Par sujet 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.

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

2018-05-24 Par sujet 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 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

2018-05-24 Par sujet 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 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

2018-05-23 Par sujet 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.

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

2018-05-23 Par sujet kaliderus 
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

2018-05-23 Par sujet kaliderus 
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.