Re: Fwd: J'arrive pas à vider /lib pour une mise à jour du 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.

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

[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

[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.

Re: Retour d'expérience avec un clavier Qwerty International

[Daniel Caillibaud]

Le 22/05/18 à 14:30, Olivier  a écrit :
O> Des expériences ici relatées, faut-il retenir que:
O> - la disposition matricielle des touches d'un clavier (par opposition à une
O> disposition en quinconce où les touches d'une rangée sont en décalage d'une
O> demie-unité des rangées adjacentes) est moins importante qu'un
O> positionnement linguistique naturel (voyelles d'un côté, consonnes de
O> l'autre, lettre positionnées selon leur fréquence d'utilisation) ?

N'ayant jamais testé bépo sur du "quinconce" je sais pas trop, mais je pense 
que oui (les
doigts doivent apprendre assez vite le décalage d'une ligne à l'autre), le gros 
plus du bépo
est que tu as les lettres les plus utilisées (auietsrn) sur la position "au 
repos" des doigts
qui n'ont donc pas de mouvement à faire pour les taper, et les autres 
relativement fréquentes
juste à coté (donc si tu cumules les déplacements de cases que doivent faire 
les doigts y'a un
très net avantage au bépo).

O> - passe-t-on sans trop de mal d'un Bepo-matrice à une Bepo-quinconce ou
O> réciproquement ?

Pas testé, mais j'imagine que ça occasionne des fautes de frappe après chaque 
changement, je
sais pas pendant combien de temps (et ça c'est idem bépo/azerty).

À ce sujet, j'ai l'impression que c'est le petit creux de la touche qui oriente 
le doigt vers
la touche d'à coté, et c'est étonnant que les claviers quinconce n'aient pas 
cette "gouttière"
dans la diagonale de la touche (car avoir la voisine dans le coin avec une 
gouttière qui
t'oriente au milieu entre les deux touches du dessus c'est vicieux).

-- 
Daniel

Plus les galets ont roulés, plus ils sont polis. 
Pour les cochers, c'est le contraire.
Alphonse Allais