Re: Mise à jour du noyau et pilotes réseau Intel compilés

[Étienne Mollier]

Olivier, au 2019-09-24 :
> Je serai très curieux de recueillir ici des retours
> d'expérience sur l'utilisation de DKMS en production.

Bonjour,

Je ne sais pas si ça compte comme un « usage en production »,
mais un certain nombre de paquets Debian fournissent des pilotes
tiers non disponibles directement dans Linux, mais qui
s'installent justement via DKMS.  Ces paquets ont en général un
nom qui termine en "-dkms", quelques exemples au hasard tirés de
la commande "apt search '.*-dkms$'" :
- aufs-dkms,
- nvidia-kernel-dkms,
- virtualbox-dkms,
- zfs-dkms,
- etc.

Pour les configurations qui ne dévient pas de Debian, il n'y a
pas de problèmes particuliers à noter.  Mais s'il y en a, alors
ça vaut le coup de les rapporter dans le système de suivi de
bogues.

Pour les configurations un peu plus sioux, ou de test et
développement, ou quand quelque chose plante lors d'une mise à
jour du pilote ou du noyau, le comportement de DKMS peut parfois
être assez opaque.  Les journaux de compilation, nécessaires à
la phase de débogue, sont cachés au fin fond d'une arborescence
de fichiers qui, malgré la convention de nommage, peuvent être
écrasés par la compilation suivante, notamment en tentant de
construire un pilote donné sur plusieurs noyaux différents.

D'autre part, la commande "dkms status" a une sortie qui n'est
pas forcément très claire sur le statut des pilotes en fonction
des noyaux, pour indiquer les combinaisons qui marchent, et
celles qui ne marchent pas.  De mémoire, il me semble que sont
indiqués: (1) les pilotes qui se sont proprement installés, et
(2) ceux qui ont été proprement compilés sans être installés.
Les pilotes qui n'ont pas passé l'étape de la compilation ne
sont pas indiqués, et les pilotes qui ne sont que compilés ne
sont pas pour autant utilisables: il faut parfois bricoler un
peu avec la commande "dkms install" pour pousser le tout.

Enfin, dernier point, le pilote doit supporter d'être installé
via DKMS, ce qui consiste à minima en un fichier dkms.conf avec
les méta-informations nécessaires à la compilation du paquets,
sa version, sa compatibilité avec les différents niveaux de
noyau, etc.

Pour mes machines personnelles, je n'ai pas eu besoin de pilotes
DKMS jusqu'à présent, du coup je suis un peu en mal d'être plus
précis ; mais c'est ce dont je me souviens de mes petits travaux
antérieurs.

L'outil n'a pas forcément très bonne réputation, mais c'est l'un
des seuls disponibles, avec "module-assistant" si j'en croie le
cahier des administrateurs Debian section 8.10.5 [1], pour
empaqueter les pilotes tiers.  DKMS a le mérite d'exister donc.

[1] 
https://www.debian.org/doc/manuals/debian-handbook/sect.kernel-compilation.en.html

La « bonne méthode » consisterait a porter le pilote directement
dans le code source du noyau (drivers/) afin qu'il puisse
bénéficier automatiquement des mises à jour rendues nécessaires
par la façon dont le code source de Linux lui-même évolue ; les
développeurs noyaux passent des scripts quand l'API change, ce
qui peut arriver à chaque nouvelle version stable.

Amicalement,
-- 
Étienne Mollier 
Empreinte :   5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d



signature.asc
Description: OpenPGP digital signature

Re: Mise à jour du noyau et pilotes réseau Intel compilés

[Olivier]

Hello,

Le lien [2] donne des infos qui me semblent bien correspondre à ce que je
recherche.
Cela repose sur DKMS.

Je serai très curieux de recueillir ici des retours d'expérience sur
l'utilisation de DKMS en production.

[2] https://vincent.bernat.ch/fr/blog/2018-empaquetage-pilote-debian-dkms

Le ven. 20 sept. 2019 à 14:12, Olivier  a écrit :

> Bonjour,
>
> Il y a quelques semaines, j'ai installé une nouvelle machine sous Debian
> Stretch.
> Cette machine utilisait une interface Ethernet Intel I219-V.
>
> Cette interface est supportée dans Buster mais pas dans Stretch.
>
> Pour pouvoir utiliser cette interface dans Stretch j'ai téléchargé les
> sources du pilote avant de les compiler sur la machine cible (cf [1]).
> L'opération m'a permis d'utiliser la carte réseau normalement.
>
> Quelques jours plus tard, après un apt-get dist-upgrade, la carte a cessé
> de fonctionner.
> J'ai ré-installé les paquets nécessaires à la compilation (je les avais
> enlevés), j'ai recompilé et ça a re-fonctionné.
>
> Depuis, je me suis interdit de mettre à jour le noyau et me suis juré
> d'éclaircir ce mystère.
>
> 1. Comment revenir de façon fiable au dernier état précédent une commande
> "apt-get dist-upgrade" ?
>
> 2. Est-il possible d'automatiser la re-compilation d'un logiciel après
> chaque mise-à-jour du noyau ?
>
> 3. Existe-t-il un dépôt Debian binaire suivant d'un peu plus près les
> pilotes réseau d'Intel ?
>
> 4. Conseils ? Suggestions ?
>
> Slts
>
> [1]
> https://www.intel.fr/content/www/fr/fr/support/articles/05480/network-and-i-o/ethernet-products.html
>

Re: Mise à jour du noyau et pilotes réseau Intel compilés

[Christophe]

Hello,

Le 20/09/2019 à 14:12, Olivier a écrit :


J'ai ré-installé les paquets nécessaires à la compilation (je les avais 
enlevés), j'ai recompilé et ça a re-fonctionné.


2. Est-il possible d'automatiser la re-compilation d'un logiciel après 
chaque mise-à-jour du noyau ?



Ca s'appelle DKMS.
Un exemple (Ubuntu mais s'applique à Debian également) ici avec l'e1000e :
https://nileshgr.com/2019/05/25/ubuntu-18-04-add-e1000e-intel-driver-to-dkms

Bonne lecture,
Christophe.

Mise à jour du noyau et pilotes réseau Intel compilés

[Olivier]

Bonjour,

Il y a quelques semaines, j'ai installé une nouvelle machine sous Debian
Stretch.
Cette machine utilisait une interface Ethernet Intel I219-V.

Cette interface est supportée dans Buster mais pas dans Stretch.

Pour pouvoir utiliser cette interface dans Stretch j'ai téléchargé les
sources du pilote avant de les compiler sur la machine cible (cf [1]).
L'opération m'a permis d'utiliser la carte réseau normalement.

Quelques jours plus tard, après un apt-get dist-upgrade, la carte a cessé
de fonctionner.
J'ai ré-installé les paquets nécessaires à la compilation (je les avais
enlevés), j'ai recompilé et ça a re-fonctionné.

Depuis, je me suis interdit de mettre à jour le noyau et me suis juré
d'éclaircir ce mystère.

1. Comment revenir de façon fiable au dernier état précédent une commande
"apt-get dist-upgrade" ?

2. Est-il possible d'automatiser la re-compilation d'un logiciel après
chaque mise-à-jour du noyau ?

3. Existe-t-il un dépôt Debian binaire suivant d'un peu plus près les
pilotes réseau d'Intel ?

4. Conseils ? Suggestions ?

Slts

[1]
https://www.intel.fr/content/www/fr/fr/support/articles/05480/network-and-i-o/ethernet-products.html

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

[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

[Eric Degenetais]

Le 25 mai 2018 6:31 PM, "Paul Ezvan" <p...@ezvan.fr> 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

[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

[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

[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

[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

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

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


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.

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

[Raphaël POITEVIN]

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 ?
>
> 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

> 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.
>
> 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
-- 
Raphaël

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

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

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  453M415M   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.

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [RESOLU][Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Jean-Marc]

Fri, 17 Mar 2017 15:16:15 +0100
Olivier  écrivait :

> Dois-je retenir qu'un dist-upgrade est nécessaire à chaque changement de
> version du noyau ?
> Ai-je raté une alerte me signalant qu'un changement de noyau est possible
> ou recommandé ?
> Que risque-ton avec un dist-upgrade (si on n'a pas changé les données de
> /etc/apt) ?


Pas d'alerte en Stretch.  C'est la version de test.

Comme je l'ai dit, un (apt upgrade> n'installe pas de nouveau paquets.
Or dans ton cas, tu voulais installer un nouveau paquet avec un noyau 4.9.

Seul un  staisfait ta demande.

Plus généralement, je n'utilise que .

Et aucun cas, un  dans une version de test.

Ce qui me permet de vérifier ce qui sera mis à jour, enlever ou ajouter avant 
de le faire.

> 
> En tout cas, merci pour le tuyau !

De rien.

Et j'ai une question : pourquoi le noyau linux-image-686-pae ?

Tu as une machine particulière qui le demande ?

Jean-Marc 


pgpqFCAJQU3ID.pgp
Description: PGP signature

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [RESOLU][Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Olivier]

Le 17 mars 2017 à 10:34, Jean-Marc  a écrit :

> Fri, 17 Mar 2017 10:26:49 +0100
> Olivier  écrivait :
>
> salut,
>
> > $ sudo apt-get -s dist-upgrade
> > Lecture des listes de paquets... Fait
> > Construction de l'arbre des dépendances
> > Lecture des informations d'état... Fait
> > Calcul de la mise à jour... Fait
> > Les paquets suivants ont été installés automatiquement et ne sont plus
> > nécessaires :
> >   bijiben libsofia-sip-ua-glib3 libsofia-sip-ua0 telepathy-rakia
> > Veuillez utiliser « sudo apt autoremove » pour les supprimer.
> > Les NOUVEAUX paquets suivants seront installés :
> >   firmware-linux-free gnome-calendar irqbalance libopenmpt0 libpgm-5.2-0
> > libproxy1-plugin-gsettings
> >   libproxy1-plugin-networkmanager libsaxonhe-java
> > linux-image-4.9.0-2-686-pae
> > Les paquets suivants seront mis à jour :
> >   gnome gnome-core gstreamer1.0-libav libavdevice57 libavfilter6
> > libavformat57 libgegl-0.3-0 libopencv-calib3d2.4v5
> >   libopencv-core2.4v5 libopencv-features2d2.4v5 libopencv-flann2.4v5
> > libopencv-highgui2.4-deb0 libopencv-imgproc2.4v5
> >   libopencv-objdetect2.4v5 libopencv-video2.4v5 libxmlbeans-java libzmq5
> > linux-image-686-pae
> > 18 mis à jour, 9 nouvellement installés, 0 à enlever et 0 non mis à jour.
> >
> >
> > Si j'en crois ce qui précède, linux-image n'est pas mis à jour par
> > dist-upgrade.
>
> Si tu regardes attentivement, tu verras linux-image-686-pae dans la liste
> des paquets qui seront mis à jour et linux-image-4.9.0-2-686-pae dans la
> liste des nouveaux paquets.
>
> Je pensais que c'est ce que tu voulais.
>
>
> Jean-Marc 
>

En effet, je suis complètement miro !
J'arrête de boire de l'eau ;-))


Dois-je retenir qu'un dist-upgrade est nécessaire à chaque changement de
version du noyau ?
Ai-je raté une alerte me signalant qu'un changement de noyau est possible
ou recommandé ?
Que risque-ton avec un dist-upgrade (si on n'a pas changé les données de
/etc/apt) ?

En tout cas, merci pour le tuyau !

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Jean-Marc]

Fri, 17 Mar 2017 10:26:49 +0100
Olivier  écrivait :

salut,

> $ sudo apt-get -s dist-upgrade
> Lecture des listes de paquets... Fait
> Construction de l'arbre des dépendances
> Lecture des informations d'état... Fait
> Calcul de la mise à jour... Fait
> Les paquets suivants ont été installés automatiquement et ne sont plus
> nécessaires :
>   bijiben libsofia-sip-ua-glib3 libsofia-sip-ua0 telepathy-rakia
> Veuillez utiliser « sudo apt autoremove » pour les supprimer.
> Les NOUVEAUX paquets suivants seront installés :
>   firmware-linux-free gnome-calendar irqbalance libopenmpt0 libpgm-5.2-0
> libproxy1-plugin-gsettings
>   libproxy1-plugin-networkmanager libsaxonhe-java
> linux-image-4.9.0-2-686-pae
> Les paquets suivants seront mis à jour :
>   gnome gnome-core gstreamer1.0-libav libavdevice57 libavfilter6
> libavformat57 libgegl-0.3-0 libopencv-calib3d2.4v5
>   libopencv-core2.4v5 libopencv-features2d2.4v5 libopencv-flann2.4v5
> libopencv-highgui2.4-deb0 libopencv-imgproc2.4v5
>   libopencv-objdetect2.4v5 libopencv-video2.4v5 libxmlbeans-java libzmq5
> linux-image-686-pae
> 18 mis à jour, 9 nouvellement installés, 0 à enlever et 0 non mis à jour.
> 
> 
> Si j'en crois ce qui précède, linux-image n'est pas mis à jour par
> dist-upgrade.

Si tu regardes attentivement, tu verras linux-image-686-pae dans la liste des 
paquets qui seront mis à jour et linux-image-4.9.0-2-686-pae dans la liste des 
nouveaux paquets.

Je pensais que c'est ce que tu voulais.


Jean-Marc 


pgphvUbXuTHry.pgp
Description: PGP signature

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Olivier]

Le 16 mars 2017 à 19:13, Francois Lafont  a écrit :

> On 03/16/2017 05:21 PM, Olivier wrote:
>
> > Ce que j'ai du mal à comprendre, c'est pourquoi le passage de 4.8 en 4.9
> ne
> > s'opère pas automatiquement : je n'ai jamais spécifié la version 4.8,
> j'ai
> > à l'époque spécifié la version courante qui était la 4.8.
> > Si la version courante change, je m'attends à ce que mon noyau suive, ni
> > plus ni moins, ne serait-ce que justement, pour garder la possibilité des
> > en-têtes si j'en ai envie..
>
> Que donne « dpkg -l | grep linux-image » sur ta machine ?
>
> Normalement, c'est le principe du métapackage linux-image-amd64 de faire
> ce que tu dis.
>
> --
> François Lafont
>
>

$ dpkg -l | grep linux-image
ii  linux-image-4.8.0-2-686-pae
4.8.15-2 i386 Linux 4.8 for modern PCs
(signed)
ii  linux-image-686-pae
4.8+77   i386 Linux for modern PCs
(meta-package)


cf aussi mon post précédent avec apt policy.

Existe-t-il une commande qui permet à oeil exercé de comprendre pourquoi un
paquet figure explicitement dans la liste des paquets conservés et pourquoi
un autre figure dans la liste de ceux mis à jour ?

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Eric Degenetais]

Le 17 mars 2017 10:27, "Olivier"  a écrit :



Le 16 mars 2017 à 17:42, Jean-Marc  a écrit :

> Thu, 16 Mar 2017 17:21:45 +0100
> Olivier  écrivait :
>
> > En d'autres termes, que font les utilisateurs de Stretch, qui comme moi
> > veulent simplement rester synchrone avec la distribution ?
>
> Tu as essayé :
>  ?
>

$ sudo apt-get -s dist-upgrade

Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus
nécessaires :
  bijiben libsofia-sip-ua-glib3 libsofia-sip-ua0 telepathy-rakia

Veuillez utiliser « sudo apt autoremove » pour les supprimer.
Les NOUVEAUX paquets suivants seront installés :
  firmware-linux-free gnome-calendar irqbalance libopenmpt0 libpgm-5.2-0
libproxy1-plugin-gsettings
  libproxy1-plugin-networkmanager libsaxonhe-java
linux-image-4.9.0-2-686-pae
Les paquets suivants seront mis à jour :

  gnome gnome-core gstreamer1.0-libav libavdevice57 libavfilter6
libavformat57 libgegl-0.3-0 libopencv-calib3d2.4v5
  libopencv-core2.4v5 libopencv-features2d2.4v5 libopencv-flann2.4v5
libopencv-highgui2.4-deb0 libopencv-imgproc2.4v5
  libopencv-objdetect2.4v5 libopencv-video2.4v5 libxmlbeans-java libzmq5
linux-image-686-pae
18 mis à jour, 9 nouvellement installés, 0 à enlever et 0 non mis à jour.


Si j'en crois ce qui précède, linux-image n'est pas mis à jour par
dist-upgrade


Bonjour, de ce que j'en comprends, ce qui porte la version du noyau et est
effectivement mis à jour est le paquet spécifique de la plate-forme (ici
linux-image-686-pae, qui figure bel et bien dans la liste des paquets mis à
jour). Ce paquet de plate-forme a avec linux-image une relation de type
"provide"



Jean-Marc 
>

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Olivier]

Le 16 mars 2017 à 17:42, Jean-Marc  a écrit :

> Thu, 16 Mar 2017 17:21:45 +0100
> Olivier  écrivait :
>
> > En d'autres termes, que font les utilisateurs de Stretch, qui comme moi
> > veulent simplement rester synchrone avec la distribution ?
>
> Tu as essayé :
>  ?
>

$ sudo apt-get -s dist-upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus
nécessaires :
  bijiben libsofia-sip-ua-glib3 libsofia-sip-ua0 telepathy-rakia
Veuillez utiliser « sudo apt autoremove » pour les supprimer.
Les NOUVEAUX paquets suivants seront installés :
  firmware-linux-free gnome-calendar irqbalance libopenmpt0 libpgm-5.2-0
libproxy1-plugin-gsettings
  libproxy1-plugin-networkmanager libsaxonhe-java
linux-image-4.9.0-2-686-pae
Les paquets suivants seront mis à jour :
  gnome gnome-core gstreamer1.0-libav libavdevice57 libavfilter6
libavformat57 libgegl-0.3-0 libopencv-calib3d2.4v5
  libopencv-core2.4v5 libopencv-features2d2.4v5 libopencv-flann2.4v5
libopencv-highgui2.4-deb0 libopencv-imgproc2.4v5
  libopencv-objdetect2.4v5 libopencv-video2.4v5 libxmlbeans-java libzmq5
linux-image-686-pae
18 mis à jour, 9 nouvellement installés, 0 à enlever et 0 non mis à jour.


Si j'en crois ce qui précède, linux-image n'est pas mis à jour par
dist-upgrade.


>
> Jean-Marc 
>

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Francois Lafont]

Bonsoir,

On 03/16/2017 07:55 PM, maderios wrote:

> Il faut quand même admettre que chez Debian, la manière de nommer les
> noyaux n'est pas claire et même trompeuse. Sur Stretch dpkg -l | grep
> linux-image ii  linux-image-4.9.0-2-amd64
> 4.9.13-1   amd64Linux 4.9 for
> 64-bit PCs (signed) ii  linux-image-amd64
> 4.9+79   amd64Linux for 64-bit
> PCs (meta-package)

Voilà et moi par exemple sur ma Jessie j'ai ça :

ii  linux-image-3.16.0-4-amd64  3.16.39-1+deb8u2  amd64
ii  linux-image-amd64   3.16+63   amd64

linux-image-amd64 est un métapackage, ie il ne contient pour ainsi dire
rien ou presque comme on peut le voir avec « dpkg -L linux-image-amd64 ».
Son rôle est d'avoir une dépendance d'un paquet linux-image-W.X.Y-Z-amd64
qui lui contiendra bien un noyau Linux.

Quand le paquet linux-image-amd64 est mis à jour, c'est en fait juste
sa dépendance qui va changer et tirer avec lui l'installation d'une
nouvelle version du noyau Linux.

Si on désinstalle le package linux-image-amd64, globalement on ne
supprime rien mais on risque de passer à côté d'un changement de
numéro de version du noyau. Perso, je verrais bien le PO se trouver
dans cette situation où le paquet linux-image-amd64 n'est pas
installé.

> Que vient faire ce '4.9+79' concernant le '4.9.13'? Mystère... Avec
> d'autres distributions, tout ce qui concerne le même noyau porte le
> même numéro. Le pire, ce sont les entrées de Grub où ne sont pas
> mentionnées les versions de noyaux... On ne sait jamais où on en est
> mais bon, c'est Debian... :)

Faut reconnaître que la nomenclature des numéros de version, c'est
un peu compliqué parfois, même si dans les grandes lignes ça correspond
souvent à quelque chose de simple comme (c'est le premier exemple que
m'est venu sous ma Jessie) :

python3-minimal => 3.4.2-2

qui signifie que le paquet est basé sur la version 3.4.2 du programme
upstream (ie Python3 en l'occurrence ici) et "-2" correspond au numéro
de révision du paquet. Après, ça peut être plus compliqué que ça et il
y a de la doc ici par exemple :

https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

Après, pour le « 4.9+79 » du package linux-image-amd64, c'est vrai
que c'est pas super clair. On peut imaginer que le 4.9 correspond
à la version du noyau qui se cache derrière le métapackage (jusque
là je me mouille pas trop). Quant au "+79", j'ai bien l'impression
qui'l est incrémenté tout simplement à chaque mise à jour du paquet
linux-image-amd64. On peut s'en rendre compte en parcourant son
changelog :

zcat /usr/share/doc/linux-image-amd64/changelog.gz | less

Par exemple lors du passage du noyau 3.13 à 3.14, ce numéro est
tout simplement passé de 56 à 57. Mais oui, dans le détail, la
nomenclature des numéros de version c'est un peu compliqué.

-- 
François Lafont

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[maderios]

On 03/16/2017 07:13 PM, Francois Lafont wrote:

On 03/16/2017 05:21 PM, Olivier wrote:


Ce que j'ai du mal à comprendre, c'est pourquoi le passage de 4.8 en 4.9 ne
s'opère pas automatiquement : je n'ai jamais spécifié la version 4.8, j'ai
à l'époque spécifié la version courante qui était la 4.8.
Si la version courante change, je m'attends à ce que mon noyau suive, ni
plus ni moins, ne serait-ce que justement, pour garder la possibilité des
en-têtes si j'en ai envie..


Que donne « dpkg -l | grep linux-image » sur ta machine ?

Normalement, c'est le principe du métapackage linux-image-amd64 de faire
ce que tu dis.


Bonjour
Il faut quand même admettre que chez Debian, la manière de nommer les 
noyaux n'est pas claire et même trompeuse.

Sur Stretch
dpkg -l | grep linux-image
ii  linux-image-4.9.0-2-amd64   4.9.13-1 
  amd64Linux 4.9 for 64-bit PCs 
(signed)
ii  linux-image-amd64   4.9+79 
  amd64Linux for 64-bit PCs 
(meta-package)


Que vient faire ce '4.9+79' concernant le '4.9.13'? Mystère...
Avec d'autres distributions, tout ce qui concerne le même noyau porte le 
même numéro. Le pire, ce sont les entrées de Grub où ne sont pas 
mentionnées les versions de noyaux... On ne sait jamais où on en est 
mais bon, c'est Debian... :)

--
Maderios

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Francois Lafont]

On 03/16/2017 05:21 PM, Olivier wrote:

> Ce que j'ai du mal à comprendre, c'est pourquoi le passage de 4.8 en 4.9 ne
> s'opère pas automatiquement : je n'ai jamais spécifié la version 4.8, j'ai
> à l'époque spécifié la version courante qui était la 4.8.
> Si la version courante change, je m'attends à ce que mon noyau suive, ni
> plus ni moins, ne serait-ce que justement, pour garder la possibilité des
> en-têtes si j'en ai envie..

Que donne « dpkg -l | grep linux-image » sur ta machine ?

Normalement, c'est le principe du métapackage linux-image-amd64 de faire
ce que tu dis.

-- 
François Lafont

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Jean-Marc]

Thu, 16 Mar 2017 17:21:45 +0100
Olivier  écrivait :

> En d'autres termes, que font les utilisateurs de Stretch, qui comme moi
> veulent simplement rester synchrone avec la distribution ?

Tu as essayé :
 ?

Jean-Marc 


pgpHVs0OmdTsm.pgp
Description: PGP signature

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Olivier]

Le 16 mars 2017 à 16:01, Jean-Marc  a écrit :

> Thu, 16 Mar 2017 14:44:02 +0100
> Olivier  écrivait :
>
> > [...]
> > Si j'ai bien compris:
> > - c'est le (meta-)paquet linux-image-686-pae qui est installé,
>
> Effectivement.  C'est ce paquet contenant un kernel 32bit qui est installé.
>
> > - pour une raison à découvrir, apt-get refuse de le mettre à jour, ce qui
> > bloque l'installation de paquets comme linux-headers-* qui dans le dépôt
> > sont déjà "en version 4.9"
>
> Comme dit dans ma première réponse, la raison est simple :
> -  n'installe pas de nouveau paquets ; cette commande
> n'installera pas de noyau 4.9.
> -  fait les mises à jour y compris s'il faut installer
> un nouveau paquet.
>
> Concernant les entêtes, la version 4.8 n'existant plus dans les dépôts, tu
> ne peux pas les installer.  Après une mise à jour et l'install' d'un 4.9


En effet, j'ai bien compris qu'il m'est pour l'instant impossible en l'état
d'installer les en-têtes de la version 4.9 du noyau.

Je n'utilise que des versions stable de Debian et donc, je suis
particulièrement novice avec les versions futures de Debian.
Ce que j'ai du mal à comprendre, c'est pourquoi le passage de 4.8 en 4.9 ne
s'opère pas automatiquement : je n'ai jamais spécifié la version 4.8, j'ai
à l'époque
spécifié la version courante qui était la 4.8.
Si la version courante change, je m'attends à ce que mon noyau suive, ni
plus ni moins, ne serait-ce que justement, pour garder la possibilité des
en-têtes si j'en ai envie..

D'ailleurs, a commande "apt-get install linux-image-686-pae" n'est-elle
théoriquement pas nécessaire et suffisante (comme le montre apt policy)
pour installer aujourd'hui un
tel noyau 4.9 ?

En d'autres termes, que font les utilisateurs de Stretch, qui comme moi
veulent simplement rester synchrone avec la distribution ?




> et d'un reboot, tu pourras lancer la commande du début.
>
>
> Jean-Marc 
>
> P.S. pas besoin de droits root pour faire un dpkg --list.
>

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Jean-Marc]

Thu, 16 Mar 2017 14:44:02 +0100
Olivier  écrivait :

> [...]
> Si j'ai bien compris:
> - c'est le (meta-)paquet linux-image-686-pae qui est installé,

Effectivement.  C'est ce paquet contenant un kernel 32bit qui est installé.

> - pour une raison à découvrir, apt-get refuse de le mettre à jour, ce qui
> bloque l'installation de paquets comme linux-headers-* qui dans le dépôt
> sont déjà "en version 4.9"

Comme dit dans ma première réponse, la raison est simple :
-  n'installe pas de nouveau paquets ; cette commande n'installera 
pas de noyau 4.9.
-  fait les mises à jour y compris s'il faut installer un 
nouveau paquet.

Concernant les entêtes, la version 4.8 n'existant plus dans les dépôts, tu ne 
peux pas les installer.  Après une mise à jour et l'install' d'un 4.9 et d'un 
reboot, tu pourras lancer la commande du début.


Jean-Marc 

P.S. pas besoin de droits root pour faire un dpkg --list.


pgpVykbya6NbN.pgp
Description: PGP signature

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Olivier]

Le 16 mars 2017 à 13:13, Jean-Marc  a écrit :

> Thu, 16 Mar 2017 09:30:05 +0100
> Olivier  écrivait :
>
> > Bonjour,
>
> salut Olivier,
>
> >
> > J'ai installé il y a quelques semaines deux machines  sous Stretch avec
> > l'installeur en vigueur à l'époque. Régulièrement, j'opère sur ces
> machines
> > une séquence "apt-get update; apt-get -y upgrade".
>
> Remarque perso : je déconseille fortement les mises à jour avec -y sur une
> version de test.
>
> Même si un upgrade ne fera pas de remove automatique.
>
> Et tu peux utiliser && entre les deux commandes à la place du ;
> cela ne démarrera l'upgrade que si l'update s'est bien passé et a retourné
> un code de sortie 0;
>
> >
> > Sur chaque machine, j'observe que le noyau est en version 4.8.
> >
> > J'ai installé ce matin 2 VM (1 en i386, 1 en amd64) à partir de la
> version
> > rc2 de l'installeur .
> > Sur chacune, le noyau est en 4.9.
>
> Merci de préciser la situation.
> 1. dpkg --list linux-image*
>

sudo dpkg --list linux-image*
[sudo] Mot de passe de  :
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
|
État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom VersionArchitecture
Description
+++-===-==-==-===
ii  linux-image-4.8.0-2-686-pae 4.8.15-2   i386   Linux
4.8 for modern PCs (signed)
un  linux-image-4.8.0-2-686-pae
(aucune description n'est disponible)
ii  linux-image-686-pae 4.8+77 i386   Linux
for modern PCs (meta-package)



> 2. apt policy 
>

apt policy linux-image-686-pae
linux-image-686-pae:
  Installé : 4.8+77
  Candidat : 4.9+79
 Table de version :
 4.9+79 500
500 http://ftp.fr.debian.org/debian stretch/main i386 Packages
 *** 4.8+77 100
100 /var/lib/dpkg/status


udo apt-get upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus
nécessaires :
  gnome-mime-data libbonobo2-0 libbonobo2-common libgnome-2-0
libgnome2-common libgnomevfs2-0 libgnomevfs2-common
  libgnomevfs2-extra liborbit-2-0
Veuillez utiliser « sudo apt autoremove » pour les supprimer.
Les paquets suivants ont été conservés :
  gnome gnome-core gstreamer1.0-libav libavdevice57 libavfilter6
libavformat57 libgegl-0.3-0 libopencv-calib3d2.4v5
  libopencv-core2.4v5 libopencv-features2d2.4v5 libopencv-flann2.4v5
libopencv-highgui2.4-deb0 libopencv-imgproc2.4v5
  libopencv-objdetect2.4v5 libopencv-video2.4v5 libxmlbeans-java libzmq5
linux-image-686-pae


Si j'ai bien compris:
- c'est le (meta-)paquet linux-image-686-pae qui est installé,
- pour une raison à découvrir, apt-get refuse de le mettre à jour, ce qui
bloque l'installation de paquets comme linux-headers-* qui dans le dépôt
sont déjà "en version 4.9"



>
> >
> >
> > 1. J'imaginai que sur Stretch, une séquence "apt-get update; apt-get -y
> > upgrade" change automatiquement la version du noyau, s'il y a lieu.
> > En d'autres termes, j'imaginai qu'une machine installée en Janvier, mise
> à
> > jour avec "apt-get update; apt-get -y upgrade" aurait exactement les
> mêmes
> > versions de logiciel qu'une nouvelle machine installée le jour même.
> > Est-il exact d'imaginer cela ?
>
> D'après ce que je sais, un upgrade met uniquement à jour les paquets
> installés.
>
> Si c'est correct, il n'installera jamais un nouveau paquet avec un nouveau
> noyau.
>
>
> >
> > 2. Si non, existe-t-il une commande "idempotente" (ie qui ne fait rien si
> > la version du noyau n'a pas changé mais qui fait la mise à jour quand le
> > noyau a changé) qui apporte ce changement de version ?
>
> Perso, un  maintient mes systèmes à jour y
> compris les noyaux.
>
> Ne pas oublier d'installer  qui permet de vérifier s'il
> existe des bugs critiques ouverts avant de faire les mises à jour.
>
> >
> > Slts
>
>
> Jean-Marc 
>

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Jean-Marc]

Thu, 16 Mar 2017 09:30:05 +0100
Olivier  écrivait :

> Bonjour,

salut Olivier,

> 
> J'ai installé il y a quelques semaines deux machines  sous Stretch avec
> l'installeur en vigueur à l'époque. Régulièrement, j'opère sur ces machines
> une séquence "apt-get update; apt-get -y upgrade".

Remarque perso : je déconseille fortement les mises à jour avec -y sur une 
version de test.

Même si un upgrade ne fera pas de remove automatique.

Et tu peux utiliser && entre les deux commandes à la place du ;
cela ne démarrera l'upgrade que si l'update s'est bien passé et a retourné un 
code de sortie 0;

> 
> Sur chaque machine, j'observe que le noyau est en version 4.8.
> 
> J'ai installé ce matin 2 VM (1 en i386, 1 en amd64) à partir de la version
> rc2 de l'installeur .
> Sur chacune, le noyau est en 4.9.

Merci de préciser la situation.
1. dpkg --list linux-image*
2. apt policy 

> 
> 
> 1. J'imaginai que sur Stretch, une séquence "apt-get update; apt-get -y
> upgrade" change automatiquement la version du noyau, s'il y a lieu.
> En d'autres termes, j'imaginai qu'une machine installée en Janvier, mise à
> jour avec "apt-get update; apt-get -y upgrade" aurait exactement les mêmes
> versions de logiciel qu'une nouvelle machine installée le jour même.
> Est-il exact d'imaginer cela ?

D'après ce que je sais, un upgrade met uniquement à jour les paquets installés.

Si c'est correct, il n'installera jamais un nouveau paquet avec un nouveau 
noyau.


> 
> 2. Si non, existe-t-il une commande "idempotente" (ie qui ne fait rien si
> la version du noyau n'a pas changé mais qui fait la mise à jour quand le
> noyau a changé) qui apporte ce changement de version ?

Perso, un  maintient mes systèmes à jour y 
compris les noyaux.

Ne pas oublier d'installer  qui permet de vérifier s'il existe 
des bugs critiques ouverts avant de faire les mises à jour.

> 
> Slts


Jean-Marc 


pgpEG7EaHEvAh.pgp
Description: PGP signature

Re: Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[daniel huhardeaux]

Le 16/03/2017 à 09:30, Olivier a écrit :

Bonjour,

J'ai installé il y a quelques semaines deux machines  sous Stretch 
avec l'installeur en vigueur à l'époque. Régulièrement, j'opère sur 
ces machines une séquence "apt-get update; apt-get -y upgrade".


Sur chaque machine, j'observe que le noyau est en version 4.8.

J'ai installé ce matin 2 VM (1 en i386, 1 en amd64) à partir de la 
version rc2 de l'installeur .

Sur chacune, le noyau est en 4.9.


1. J'imaginai que sur Stretch, une séquence "apt-get update; apt-get 
-y upgrade" change automatiquement la version du noyau, s'il y a lieu.
En d'autres termes, j'imaginai qu'une machine installée en Janvier, 
mise à jour avec "apt-get update; apt-get -y upgrade" aurait 
exactement les mêmes versions de logiciel qu'une nouvelle machine 
installée le jour même.

Est-il exact d'imaginer cela ?

2. Si non, existe-t-il une commande "idempotente" (ie qui ne fait rien 
si la version du noyau n'a pas changé mais qui fait la mise à jour 
quand le noyau a changé) qui apporte ce changement de version ?


C'est le paquet linux-image-[amd64|i386] qui gère. Soit il n'est pas 
installé sur les 2 "anciennes" machines, soit il pointe sur le noyau 4.8




Slts

Le 14 mars 2017 à 15:36, Jean-Marc > a écrit :


Tue, 14 Mar 2017 14:29:57 +0100
Olivier > écrivait :

> # uname -r
> 4.8.0-2-686-pae
>
> # apt-get install linux-headers-`uname -r`
> Lecture des listes de paquets... Fait
> Construction de l'arbre des dépendances
> Lecture des informations d'état... Fait
> E: Impossible de trouver le paquet linux-headers-4.8.0-2-686-pae
> E: Couldn't find any package by glob 'linux-headers-4.8.0-2-686-pae'
> E: Impossible de trouver de paquet correspondant à l'expression
rationnelle
> « linux-headers-4.8.0-2-686-pae »

Je viens de faire une recherche sur le site de Debian et il
n'existe plus que 2 ou 3 paquets pour la version 4.8 et uniquement
dans les backports de Jessie.

Donc, je pense que c'est normal que apt-get ne puisse pas
installer un paquet qui n'existe plus.


Bien à toi,


Jean-Marc >

Comment s'opère la mise à jour du noyau dans Stretch ? [Etait: Pourquoi linux-headers-`uname r` échoue sur Stretch et pas sur Jessie ?]

[Olivier]

Bonjour,

J'ai installé il y a quelques semaines deux machines  sous Stretch avec
l'installeur en vigueur à l'époque. Régulièrement, j'opère sur ces machines
une séquence "apt-get update; apt-get -y upgrade".

Sur chaque machine, j'observe que le noyau est en version 4.8.

J'ai installé ce matin 2 VM (1 en i386, 1 en amd64) à partir de la version
rc2 de l'installeur .
Sur chacune, le noyau est en 4.9.


1. J'imaginai que sur Stretch, une séquence "apt-get update; apt-get -y
upgrade" change automatiquement la version du noyau, s'il y a lieu.
En d'autres termes, j'imaginai qu'une machine installée en Janvier, mise à
jour avec "apt-get update; apt-get -y upgrade" aurait exactement les mêmes
versions de logiciel qu'une nouvelle machine installée le jour même.
Est-il exact d'imaginer cela ?

2. Si non, existe-t-il une commande "idempotente" (ie qui ne fait rien si
la version du noyau n'a pas changé mais qui fait la mise à jour quand le
noyau a changé) qui apporte ce changement de version ?

Slts

Le 14 mars 2017 à 15:36, Jean-Marc  a écrit :

> Tue, 14 Mar 2017 14:29:57 +0100
> Olivier  écrivait :
>
> > # uname -r
> > 4.8.0-2-686-pae
> >
> > # apt-get install linux-headers-`uname -r`
> > Lecture des listes de paquets... Fait
> > Construction de l'arbre des dépendances
> > Lecture des informations d'état... Fait
> > E: Impossible de trouver le paquet linux-headers-4.8.0-2-686-pae
> > E: Couldn't find any package by glob 'linux-headers-4.8.0-2-686-pae'
> > E: Impossible de trouver de paquet correspondant à l'expression
> rationnelle
> > « linux-headers-4.8.0-2-686-pae »
>
> Je viens de faire une recherche sur le site de Debian et il n'existe plus
> que 2 ou 3 paquets pour la version 4.8 et uniquement dans les backports de
> Jessie.
>
> Donc, je pense que c'est normal que apt-get ne puisse pas installer un
> paquet qui n'existe plus.
>
>
> Bien à toi,
>
>
> Jean-Marc 
>

Soucis avec Boinc Manager après la dernière mise à jour du noyau

[Nicolas FRANCOIS]

Salut.

J'utilise une Debian Wheezy stable, avec quelques backports.

Lors de la dernière mise à jour du noyau (3.2.65-1 x86_64), j'ai
remarqué que boincmgr ne se lançait plus automatiquement après reboot.

Un lancement manuel me donne ce message d'erreur :

nico@gaston:~$ boincmgr 
boincmgr: symbol lookup error: boincmgr: undefined symbol:
_ZN6CONFIG8defaultsEv

Je n'ai rien trouvé sur ce symbole sur Google...

Any help on this ?

\bye

-- 

Nicolas FRANCOIS  |  /\ 
http://nicolas.francois.free.fr   | |__|
  X--/\\
We are the Micro$oft.   _\_V
Resistance is futile.   
You will be assimilated. darthvader penguin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150104145229.436b6...@gaston.baronie.vez

problème de mise à jour du noyau

[steve]

Salut la liste,

le 'aptitude safe-upgrade' matinal me retourne une erreur :

Paramétrage de linux-image-2.6.26-1-amd64 (2.6.26-8) ...
Running depmod.
Running mkinitramfs-kpkg.
Not updating initrd symbolic links since we are being
updated/reinstalled
(2.6.26-5 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled
(2.6.26-5 was configured last, according to dpkg)
Running postinst hook script /usr/sbin/update-grub.
Searching for GRUB installation directory ... found: /boot/grub
User postinst hook script [/usr/sbin/update-grub] exited with value 1
dpkg : erreur de traitement de linux-image-2.6.26-1-amd64
(--configure) :
 le sous-processus post-installation script a retourné une erreur de
 sortie d'état 1


Impossible de passer outre. 

Une idée ?

Merci d'avance
Steve

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

mise à jour du noyau

[fully_associative-debian]

Bonjour,

J'ai remarqué que lorsque je fais aptitude ces
dernier temps, il me propose systématiquement
une mise à jour du noyau.
Si j'ai bien compris ce sont des mises à jour
de sécurité.
À la fin du processus, il affiche, toujours
ceci : qui est un peu surprenant

The kernel version running is the same as the one
being installed

You are attempting to install a kernel version that is
the same as the version you are
currently running (version 2.6.18-4-686). The modules
list is quite likely to have been
changed, and the modules dependency file
/lib/modules/2.6.18-4-686/modules.dep needs to be
re-built. It can not be built correctly right now,
since the module list for the running
kernel are likely to be different from the kernel
installed. I am creating a new
modules.dep file, but that may not be correct. It
shall be regenerated correctly at next
reboot.

I repeat: you have to reboot in order for the modules
file to be created correctly. Until
you reboot, it may be impossible to load some modules.
Reboot as soon as this install is
finished (Do not reboot right now, since you may not
be able to boot back up until
installation is over, but boot immediately after). I
can not stress that too much. You
need to reboot soon.

Je trouve juste ça un peu surprenant
Merci

FA.








___ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur 
Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: mise à jour du noyau

[Jean-Yves F. Barbier]

[EMAIL PROTECTED] a écrit :
 Bonjour,
 
 J'ai remarqué que lorsque je fais aptitude ces
 dernier temps, il me propose systématiquement
 une mise à jour du noyau.
 Si j'ai bien compris ce sont des mises à jour
 de sécurité.
 À la fin du processus, il affiche, toujours
 ceci : qui est un peu surprenant
 
 The kernel version running is the same as the one
 being installed
 ..

C'est normal, n'importe quelle installation d'un nouveau kernel packagé
alors que la même version est déjà lancée sur le micro provoque cela.
(détection de /lib/modules/version.de.kernel.installé)

JY
-- 
A pushy romeo asked a gorgeous elevator operator, Don't all these
stops and starts get you pretty worn out?  It isn't the stops and starts
that get on my nerves, it's the jerks.

Re : mise à jour du noyau

[fully_associative-debian]

--- [EMAIL PROTECTED] a écrit :

 Bonjour,
 
 J'ai remarqué que lorsque je fais aptitude ces
 dernier temps, il me propose systématiquement
 une mise à jour du noyau.
 Si j'ai bien compris ce sont des mises à jour
 de sécurité.
 À la fin du processus, il affiche, toujours
 ceci : qui est un peu surprenant
 
 The kernel version running is the same as the one
 being installed
 
 You are attempting to install a kernel version that
 is
 the same as the version you are
 currently running (version 2.6.18-4-686). The
 modules
 list is quite likely to have been
 changed, and the modules dependency file
 /lib/modules/2.6.18-4-686/modules.dep needs to be
 re-built. It can not be built correctly right now,
 since the module list for the running
 kernel are likely to be different from the kernel
 installed. I am creating a new
 modules.dep file, but that may not be correct. It
 shall be regenerated correctly at next
 reboot.
 
 I repeat: you have to reboot in order for the
 modules
 file to be created correctly. Until
 you reboot, it may be impossible to load some
 modules.
 Reboot as soon as this install is
 finished (Do not reboot right now, since you may not
 be able to boot back up until
 installation is over, but boot immediately after). I
 can not stress that too much. You
 need to reboot soon.
 
 Je trouve juste ça un peu surprenant
 Merci
 
 FA.
 
 
En fait il affiche ça aussi après l'installation:
il y a des erreurs :

Préconfiguration des paquets...
(Lecture de la base de données... 172100 fichiers et
répertoires déjà installés.)
Préparation du remplacement de
linux-image-2.6.18-4-486 2.6.18.dfsg.1-11 (en
utilisant
.../linux-image-2.6.18-4-486_2.6.18.dfsg.1-12etch1_i386.deb)
...
The directory /lib/modules/2.6.18-4-486 still exists.
Continuing as directed.
Done.
Dépaquetage de la mise à jour de
linux-image-2.6.18-4-486 ...
dpkg : erreur de traitement de
/var/cache/apt/archives/linux-image-2.6.18-4-486_2.6.18.dfsg.1-12etch1_i386.deb
(--unpack) :
 échec dans « buffer_write(fd) » (9, ret=-1) : backend
dpkg-deb pendant «
./lib/modules/2.6.18-4-486/kernel/drivers/pci/hotplug/pci_hotplug.ko
»: Aucun espace disponible sur le périphérique
dpkg-deb: sous-processus paste tué par le signal
(Relais brisé (pipe))
Running postrm hook script /sbin/update-grub.
Your /etc/kernel-img.conf needs to be updated. Read
grub's NEWS.Debian[1]
file and follow its instructions.

 1. /usr/share/doc/grub/NEWS.Debian.gz


You shouldn't call /sbin/update-grub. Please call
/usr/sbin/update-grub instead!

Searching for GRUB installation directory ... found:
/boot/grub
Searching for default file ... found:
/boot/grub/default
Testing for an existing GRUB menu.lst file ... found:
/boot/grub/menu.lst
Searching for splash image ... none found, skipping
...
Found kernel: /boot/vmlinuz-2.6.18-4-486
Found kernel: /boot/vmlinuz-2.6.18-3-486
Found kernel: /boot/vmlinuz-2.6.16-2-486
Updating /boot/grub/menu.lst ... done

Des erreurs ont été rencontrées pendant l'exécution :

/var/cache/apt/archives/linux-image-2.6.18-4-486_2.6.18.dfsg.1-12etch1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code
(1)
Échec de l'installation d'un paquet. Tentative de
réparation :
Appuyez sur Entrée pour continuer.


FA.


 
 
   
 
   
   

___
 
 Découvrez une nouvelle façon d'obtenir des réponses
 à toutes vos questions ! 
 Profitez des connaissances, des opinions et des
 expériences des internautes sur Yahoo!
 Questions/Réponses 
 http://fr.answers.yahoo.com
 
 
 -- 
 Lisez la FAQ de la liste avant de poser une question
 :
 http://wiki.debian.net/?DebianFrench   
 Vous pouvez aussi ajouter le mot ``spam'' dans vos
 champs From et
 Reply-To:
 
 To UNSUBSCRIBE, email to
 [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact
 [EMAIL PROTECTED]
 
 



  
___ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur 
Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Re : mise à jour du noyau

[Jean-Yves F. Barbier]

[EMAIL PROTECTED] a écrit :
 --- [EMAIL PROTECTED] a écrit :
.
 En fait il affiche ça aussi après l'installation:
 il y a des erreurs :
 
 Préconfiguration des paquets...
 (Lecture de la base de données... 172100 fichiers et
 répertoires déjà installés.)
 Préparation du remplacement de
 linux-image-2.6.18-4-486 2.6.18.dfsg.1-11 (en
 utilisant
 .../linux-image-2.6.18-4-486_2.6.18.dfsg.1-12etch1_i386.deb)
 ...
 The directory /lib/modules/2.6.18-4-486 still exists.
 Continuing as directed.
 Done.
 Dépaquetage de la mise à jour de
 linux-image-2.6.18-4-486 ...
 dpkg : erreur de traitement de
 /var/cache/apt/archives/linux-image-2.6.18-4-486_2.6.18.dfsg.1-12etch1_i386.deb
 (--unpack) :
  échec dans « buffer_write(fd) » (9, ret=-1) : backend
 dpkg-deb pendant «
 ./lib/modules/2.6.18-4-486/kernel/drivers/pci/hotplug/pci_hotplug.ko
 »: Aucun espace disponible sur le périphérique

hoho: ça ressemblre fortement à une partition pleine (t'as vérifié ton
/boot?)
Ca m'est déjà arrivé avec un /boot un peu trop petit (20M) et un tas de
kernels qui n'avaient pas été enlevés parce que j'avais installé le 1,
le 2, le 3... sans jamais enlever les premiers avec dselect.

C'est du FIFO: le nouveau repousse l'actuel en 2nde position et le 2nd
dans le limbes, sauf que s'il disparaît, il n'est pas enlevé

 dpkg-deb: sous-processus paste tué par le signal
 (Relais brisé (pipe))
 Running postrm hook script /sbin/update-grub.
 Your /etc/kernel-img.conf needs to be updated. Read
 grub's NEWS.Debian[1]

oops j'avions point lu jusqu'au bout vot'diatribe 'mon princ'
je n'utilise pas grub (j'ai horreur de sa manière de compter les
disques et les partitions: ça m'a fait perdre des tas de données)

j'ai vraiment dû lire trop en biais :) je viens de voir:
échec dans « buffer_write(fd) » (9, ret=-1) : backend
  ^^
T'es sûr que tu n'a pas écris sur une diskette??

JY
-- 
God is really only another artist.  He invented the giraffe, the
elephant and the cat.  He has no real style, He just goes on trying
other things.
-- Pablo Picasso

Re: mise à jour du noyau

[fully_associative-debian]

--- Jean-Yves F. Barbier [EMAIL PROTECTED] a écrit :

 C'est normal, n'importe quelle installation d'un
 nouveau kernel packagé
 alors que la même version est déjà lancée sur le
 micro provoque cela.
 (détection de
 /lib/modules/version.de.kernel.installé)

Oui, mais la chose suivante ne l'est pas :
Il affiche les message suivant (coupé) :
sudo aptitude
...
dpkg : erreur de traitement de
/var/cache/apt/archives/linux-image-2.6.18-4-486_2.6.18.dfsg.1-12etch1_i386.deb
(--unpack) :
 échec dans « buffer_write(fd) » (9, ret=-1) : backend
dpkg-deb pendant «
./lib/modules/2.6.18-4-486/kernel/drivers/pci/hotplug/pci_hotplug.ko
»: Aucun espace disponible sur le périphérique
...
Des erreurs ont été rencontrées pendant l'exécution :
...
Il semble qu'il n'arrive pas à installer le
packet par manque de place sur un périphérique.
Voici un df, qui ne me dit
pas grand chose.
Il y a deux 0% mais ça ne correspond pas
à des partitions (?).

Sys. de fich.  1K-blocs   Occupé Disponible
Capacité...
/dev/hda1273008248932 24076  92% /
tmpfs128564 0128564   0%
/lib/init/rw
udev  1024076 10164   1% /dev
tmpfs128564 0128564   0%
/dev/shm
/dev/hda9  39647168  28378936  11268232  72% /home
/dev/hda8393516 32852360664   9% /tmp
/dev/hda5   4883556   2857612   2025944  59% /usr
/dev/hda6   2931680265432   2666248  10% /var

FA.




 
 JY
 -- 
   A pushy romeo asked a gorgeous elevator operator,
 Don't all these
 stops and starts get you pretty worn out?  It
 isn't the stops and starts
 that get on my nerves, it's the jerks.
 
 



  
___ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur 
Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: mise à jour du noyau

[Jean-Yves F. Barbier]

[EMAIL PROTECTED] a écrit :
...
 Oui, mais la chose suivante ne l'est pas :
 Il affiche les message suivant (coupé) :
 sudo aptitude
 ...
 dpkg : erreur de traitement de
 /var/cache/apt/archives/linux-image-2.6.18-4-486_2.6.18.dfsg.1-12etch1_i386.deb
 (--unpack) :
  échec dans « buffer_write(fd) » (9, ret=-1) : backend
 dpkg-deb pendant «
 ./lib/modules/2.6.18-4-486/kernel/drivers/pci/hotplug/pci_hotplug.ko
 »: Aucun espace disponible sur le périphérique
 ...
 Des erreurs ont été rencontrées pendant l'exécution :
 ...
 Il semble qu'il n'arrive pas à installer le
 packet par manque de place sur un périphérique.
 Voici un df, qui ne me dit
 pas grand chose.
 Il y a deux 0% mais ça ne correspond pas
 à des partitions (?).

vi, est c'est l'occupation qui est à 0, donc pas de PB

tu n'as pas de /boot séparé, donc c'est pas ça.

Que donne: mount ?
-- 
This is a scsi driver, scraes the shit out of me, therefore I tapdanced
and wrote a unix clone around it (C) by linus
-- Somewhere in the kernel tree

Re : mise à jour du noyau

[fully_associative-debian]

--- Jean-Yves F. Barbier [EMAIL PROTECTED] a écrit :

 »: Aucun espace disponible sur le périphérique
 hoho: ça ressemblre fortement à une partition pleine
 (t'as vérifié ton
 /boot?)

J'ai pas de partition boot, c'est bien la seule
que je n'ai pas. J'ai mis un df dans un précédent
post, le revoici :
/dev/hda1273008248932 24076  92% /
tmpfs128564 0128564   0%
/lib/init/rw
udev  1024076 10164   1% /dev
tmpfs128564 0128564   0%
/dev/shm
/dev/hda9  39647168  28378936  11268232  72% /home
/dev/hda8393516 32852360664   9% /tmp
/dev/hda5   4883556   2857612   2025944  59% /usr
/dev/hda6   2931680265432   2666248  10% /var

 Ca m'est déjà arrivé avec un /boot un peu trop petit
 (20M) et un tas de
 kernels qui n'avaient pas été enlevés parce que
 j'avais installé le 1,
 le 2, le 3... sans jamais enlever les premiers
 avec dselect.
 
 C'est du FIFO: le nouveau repousse l'actuel en 2nde
 position et le 2nd
 dans le limbes, sauf que s'il disparaît, il n'est
 pas enlevé
 
 oops j'avions point lu jusqu'au bout vot'diatribe
 'mon princ'
 je n'utilise pas grub

Je ne crois pas que ce soit grub qui soit
fautif,
mais c'est vrai que j'ai au moins quatre
ou cinq noyaux d'installés.
Mais j'ai pas de partition /boot
juste 
/; /tmp; /var; /dev; /usr;

Sur / il me reste 24076 blocs 24Mo,
c'est peut être pas assez ??

Ha, j'ai fait des partitions trop petites.
 
 j'ai vraiment dû lire trop en biais :) je viens de
 voir:
 échec dans « buffer_write(fd) » (9, ret=-1) :
 backend
   ^^
 T'es sûr que tu n'a pas écris sur une diskette??

Il y a des araignées qui ont élu domicile
dans le lecteur de disquette :
je ne pense pas qu'elles auraient permis ça.
Sérieusement, non, je ne sais pas ce qu'il veut dire
par là.

FA.

 
 JY
 -- 
 God is really only another artist.  He invented the
 giraffe, the
 elephant and the cat.  He has no real style, He just
 goes on trying
 other things.
   -- Pablo Picasso
 
 



  
___ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur 
Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Re : mise à jour du noyau

[Jean-Yves F. Barbier]

[EMAIL PROTECTED] a écrit :
 --- Jean-Yves F. Barbier [EMAIL PROTECTED] a écrit :
 
 »: Aucun espace disponible sur le périphérique
 hoho: ça ressemblre fortement à une partition pleine
 (t'as vérifié ton
 /boot?)
 
 J'ai pas de partition boot, c'est bien la seule
 que je n'ai pas. J'ai mis un df dans un précédent
 post, le revoici :

c'est pas ça que je t'avais demandé: c'est le résultat de la Cde
mount
-- 
bfextu oh n, Knghtbrd's got a gun :)
doogie ^^insert music^^
Knghtbrd bfextu - o/~ everybody is on the run o/~
bfextu o/~ run away, run away from the pay-ay-ain o/~

Re: Re : mise à jour du noyau

[François TOURDE]

Le 13643ième jour après Epoch,
fully associative-debian écrivait:

 j'ai vraiment dû lire trop en biais :) je viens de
 voir:
 échec dans « buffer_write(fd) » (9, ret=-1) :
 backend
   ^^
 T'es sûr que tu n'a pas écris sur une diskette??

 Il y a des araignées qui ont élu domicile
 dans le lecteur de disquette :
 je ne pense pas qu'elles auraient permis ça.
 Sérieusement, non, je ne sais pas ce qu'il veut dire
 par là.

Probablement : File Descriptor (fd)

Sinon, tu n'as peut-être plus d'inodes dispos. Regarde ce qu'il te
reste sur les disques où tu fais l'install.

Et me demande pas comment on fait, je sais plus et j'ai la flemme de
chercher là ;)

Re : mise à jour du noyau

[fully_associative-debian]

Désolé pour le message envoyé à domicile
j'ai fais trop vite

--- Jean-Yves F. Barbier [EMAIL PROTECTED] a écrit :

 [EMAIL PROTECTED] a écrit :
  --- Jean-Yves F. Barbier [EMAIL PROTECTED] a écrit
 :
  
  »: Aucun espace disponible sur le périphérique
  hoho: ça ressemblre fortement à une partition
 pleine
  (t'as vérifié ton
  /boot?)
  
  J'ai pas de partition boot, c'est bien la seule
  que je n'ai pas. J'ai mis un df dans un précédent
  post, le revoici :
 
 c'est pas ça que je t'avais demandé: 
Désolé, les posts se sont croisés.

 c'est le
 résultat de la Cde
 mount

sudo mount
/dev/hda1 on / type reiserfs (rw,notail)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts
(rw,noexec,nosuid,gid=5,mode=620)
/dev/hda9 on /home type reiserfs (rw)
/dev/hda8 on /tmp type reiserfs (rw)
/dev/hda5 on /usr type reiserfs (rw)
/dev/hda6 on /var type reiserfs (rw)


 -- 
 bfextu oh n, Knghtbrd's got a gun :)
 doogie ^^insert music^^
 Knghtbrd bfextu - o/~ everybody is on the run o/~
 bfextu o/~ run away, run away from the
 pay-ay-ain o/~
 
 



  
___ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur 
Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re : mise à jour du noyau

[fully_associative-debian]

--- [EMAIL PROTECTED] a écrit :
  Sinon, tu n'as peut-être plus d'inodes dispos.
  Regarde ce qu'il te
  reste sur les disques où tu fais l'install.
 Il doit faire l'install sur '/'
 et il me reste 24Mo 24073 blocs
 La taille du paquet est de 16Mo
 S'il le décompresse en place,
 ?? il n'a peut être pas assez de place ??
 
 
J'ai trois noyau différent sur une partition
racine '/' qui fait en tout
248Mo
Actuellement il reste 24Mo
Le répertoire /boot est sur cette partition
Il faut peut être que je suprime un noyau
ou autre chose
+Je vois ça demain+

FA
  
  Et me demande pas comment on fait, je sais plus et
  j'ai la flemme de
  chercher là ;)
  

  
 
 
 
 
 
   
   
   

___
 
 Découvrez une nouvelle façon d'obtenir des réponses
 à toutes vos questions ! 
 Profitez des connaissances, des opinions et des
 expériences des internautes sur Yahoo!
 Questions/Réponses 
 http://fr.answers.yahoo.com
 
 
 -- 
 Lisez la FAQ de la liste avant de poser une question
 :
 http://wiki.debian.net/?DebianFrench   
 Vous pouvez aussi ajouter le mot ``spam'' dans vos
 champs From et
 Reply-To:
 
 To UNSUBSCRIBE, email to
 [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact
 [EMAIL PROTECTED]
 
 



  
___ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur 
Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Re : mise à jour du noyau

[Pascal Hambourg]

Salut,

[EMAIL PROTECTED] a écrit :

et il me reste 24Mo 24073 blocs
La taille du paquet est de 16Mo
S'il le décompresse en place,
?? il n'a peut être pas assez de place ??


Si je regarde mes paquets noyaux perso, l'espace occupé est un peu plus 
du double de la taille du paquet.



J'ai trois noyau différent sur une partition
racine '/' qui fait en tout
248Mo
Actuellement il reste 24Mo
Le répertoire /boot est sur cette partition
Il faut peut être que je suprime un noyau


P'têt ben qu'oui. Ceci dit, si le nouveau noyau remplace un ancien, ça 
ne devrait pas prendre plus de place, non ?



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et

Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

RE : Re: Re : mise à jour du noyau

[fully_associative-debian]

--- Pascal Hambourg [EMAIL PROTECTED] a
écrit :

 Salut,
 
 [EMAIL PROTECTED] a écrit :
 et il me reste 24Mo 24073 blocs
 La taille du paquet est de 16Mo
 S'il le décompresse en place,
 ?? il n'a peut être pas assez de place ??
 
 Si je regarde mes paquets noyaux perso, l'espace
 occupé est un peu plus 
 du double de la taille du paquet.
 
  J'ai trois noyau différent sur une partition
  racine '/' qui fait en tout
  248Mo
  Actuellement il reste 24Mo
  Le répertoire /boot est sur cette partition
  Il faut peut être que je suprime un noyau
 
 P'têt ben qu'oui. Ceci dit, si le nouveau noyau
 remplace un ancien, ça 
 ne devrait pas prendre plus de place, non ?

Oui, mais peut être faut il qu'il le décompresse
quelque part avant de faire le remplacement.
Donc, peut être a-t-il besoin de 30Mo
Je verrai ça demain

FA.
 
 
 -- 
 Lisez la FAQ de la liste avant de poser une question
 :
 http://wiki.debian.net/?DebianFrench   
 Vous pouvez aussi ajouter le mot ``spam'' dans vos
 champs From et
 Reply-To:
 
 To UNSUBSCRIBE, email to
 [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact
 [EMAIL PROTECTED]
 
 



  
___ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur 
Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Mise à jour du noyau problématique et de Icedove

[Claude Bobey]

Bonjour,
Hier, j'ai fais la mise à jour de Debian Testing (Aptitude update et 
aptitude upgrade) comme d'habitude. Cela faisait une semaine que je ne 
l'avais fait.
Voyant qu'il me mettait à jour une 30 de paquets, j'ai dit oui assez 
vite (peut-être trop)!
De fait, il m'a remis à jour le kernel (2.6.18.4.686) avec le même ! Je 
n'ai pas bien compris pourquoi. Il m'a quand même alarmé par une fenêtre 
me disant de rebooter dès la fin de la mise à jour, ce que j'ai fait. 
Depuis, je n'ai rien remarqué d'étrange. J'ai toujours mon accélération 
3D (carte ATI), donc à priori tout fonctionne.


Par contre, un petit soucis avec Icedove (1.5.0.10). Il s'est remis en 
anglais, et toutes mes extensions ont disparu ! Elles sont toujours dans 
/home/--/.mozilla-thunderbird/6acwjn73.default/extensions/
Quel lien symbolique dois-je faire ou le problème vient-il d'ailleurs ? 
N'étant pas un informaticien, je m'en remets à vos lumières ou si 
quelqu'un à eu le même soucis et qu'il l'a résolu.


A bientôt, amicalement, Claude.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et

Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Mise à jour du noyau pr oblématique et de Icedove

[Pierre THIERRY]

Scribit Claude Bobey dies 01/04/2007 hora 13:38:
 De fait, il m'a remis à jour le kernel (2.6.18.4.686) avec le même !

Selon toute vraisemblance, il t'a mis à jour le paquet. Par exemple, moi
j'ai installé le paquet linux-image-2.6.18-4-k7, et apt-cache policy
m'en donne deux versions:

- 2.6.18.dfsg.1-12, dans etch et sid
- 2.6.18.dfsg.1-11, installée chez moi

Donc je peux mettre à jour ce noyau.

 Je n'ai pas bien compris pourquoi.

Tu peux voir le changelog pour voir qu'il y a eu des modifs entre les
différentes révisions du paquet. N'importe quel paquet a un tel fichier,
présent à :

/usr/share/doc/$PAQUET/changelog.Debian.gz

Donc par exemple, dans mon cas, je peux voir celui de mon noyau dans le
fichier :

/usr/share/doc/linux-image-2.6.18-4-k7/changelog.Debian.gz

 Il m'a quand même alarmé par une fenêtre me disant de rebooter dès la
 fin de la mise à jour, ce que j'ai fait.

Oui, parce que les fichiers utilisés potentiellement par le noyau en
cours (des modules qu'il pourrait vouloir charger, entre autres) ont été
modifiés.

 Depuis, je n'ai rien remarqué d'étrange. J'ai toujours mon
 accélération 3D (carte ATI), donc à priori tout fonctionne.

C'était une opération parfaitement normale, pas d'inquiétude à avoir.

 Par contre, un petit soucis avec Icedove (1.5.0.10). Il s'est remis en
 anglais

Cela arrive quand le paquet qui contient la traduc française n'est pas
compatible avec le nouveau paquet...

Brièvement,
Pierre
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature

Re: Mise à jour du noyau problématique et de Icedove

[HEHO]

Claude Bobey a écrit, le 01.04.2007 13:38 :
 Par contre, un petit soucis avec Icedove (1.5.0.10). Il s'est remis en 
 anglais, et toutes mes extensions ont disparu ! Elles sont toujours dans 
 /home/--/.mozilla-thunderbird/6acwjn73.default/extensions/
bonjour,
pour le  français si tu es impatient tu peux en attendant :
wget
http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/1.5.0.10/linux-i686/xpi/fr.xpi
et l'installer. (tu pourra adapter avec le numéro de version pour la
prochaine fois)
pour les extensions je ne sais pas.
à plus.
hého
ps.pas la tête ;)


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

[résolu] re: Mise à jour du noyau probl ématique et de Icedove

[Claude Bobey]

Bonsoir à tous,
Pour le noyau, comme le disais Pierre, c'est la mise à jour normal du 
paquet linux-image. Pour les extensions, je les ai tout bêtement 
réinstallées et tout marche.

Merci à toute la liste! Claude.

HEHO a écrit :

Claude Bobey a écrit, le 01.04.2007 13:38 :
  
Par contre, un petit soucis avec Icedove (1.5.0.10). Il s'est remis en 
anglais, et toutes mes extensions ont disparu ! Elles sont toujours dans 
/home/--/.mozilla-thunderbird/6acwjn73.default/extensions/


bonjour,
pour le  français si tu es impatient tu peux en attendant :
wget
http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/1.5.0.10/linux-i686/xpi/fr.xpi
et l'installer. (tu pourra adapter avec le numéro de version pour la
prochaine fois)
pour les extensions je ne sais pas.
à plus.
hého
ps.pas la tête ;)


  

Re: Mise à jour du noyau

[Rémi]

On Wed, 24 Oct 2001 10:12:24 +0200
LUTHIER Olivier [EMAIL PROTECTED] wrote:

 Qui veux bien me faire un petit topo sur comment mettre à jour son noyau
 pour aider un bleu ?
 
Voir aussi:
  -  http://www.parinux.org/mini-howtos/noyau.html

-- 
Remi COLETTA