Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Suppression rpm impossible!

kwizart

Bonjour!

J'ai un problème pour mettre à jours des rpms en particulier les kernel-devel. Ils sont tous installé depuis le 2.6.16-1.2133_FC5 (avec les variantes) alors que j'ai le plugin yum permettant de ne garder que deux kernels j'ai réussi en desactivant le plugin à mettre à jours vers le kernel de test en 2.6.18 mais pas les kernel-devel... yum update kernel-devel semble marche mais ne se termine pas " transaction check n'est pas dépassé...

Je ne peux pas non plus desinstaller ces paquets par un rpm -e - Pas plus de résulats!

Je me demande ce qui bloque - Est ce que j'aurais pus abimer la base de données des rpms installé - Est ce qu'il est possible de la reconstruire... Est ce qu'il est possible de forcer une desinstallation?

Merci pour vos pistes!

Anvil

Execute "kill -9" sur tous les processus relatifs a rpm (yum, rpm, rpmq, rpmv, etc.. -> man ps). Ensuite efface les fichiers /var/lib/rpm/__db* et dis nous si ca va mieux apres.

cybervirem

Bien vu !!!!!!!!

je me demandais...

Cordialement

kwizart

En fait j'ai essayer de faire un rpm -e kernel-devel-2.6.16-1.2133_FC5.i686.rpm
sauf que apres 5 min, je perd la main (donc impossible de faire un kill -9 sur le pid des process rpm )
rm /var/lib/rpm/___db* n'existe pas (peut être durant la commande rpm ?) , il y a bien des bases de donnés, mais je ne pense pas qu'il faille supprimer ceux là sans dommages!

Le plus génant c'est pas que rpm reste bloqué ( je suis quand même obligé de rebooter au bouton marche/arret )!
Ce qui est délicat c'est que je n'arrive pas à supprimer ces rpm

Anvil

rm /var/lib/rpm/___db* n'existe pas (peut être durant la commande rpm ?) , il y a bien des bases de donnés, mais je ne pense pas qu'il faille supprimer ceux là sans dommages!

Surtout n'efface rien d'autre. (On dirait que tu as rajoute un _ de trop..) les __db* sont des fichiers temporaires qui peuvent subsister sous certaines circonstances et contenir des locks.... Apparemment ca n'est pas le probleme dont je decrivais la solution. Si le systeme se bloque, tu devrais verifier ta ram. Ou rajouter du swap. Tu as peu de ram sur ton systeme ?

kwizart

512Mo sur un portable avec une de mémoire dédié en graphique (128Mo) mais pouvant utilser la mémoire centrale aussi!
J'ai 1024Mo de swap sur LVM / 14Gio en racine dont 3.7Gio de libre...

Je ne sais pas comment controller la ram disponible mais je doute que cela ne viennent de la sinon que lorsque le suis obligé de relancer par marche/arret j'ai parfois un blocage au niveau de l'activation de l'espace swap - parfois longtemps apres avoir éteins! (-> erreur disque - apres un reset !?!)

Est ce qu'il y a des opérations de maintenance possible à faire sur ext3 ? Ou est ce que tout est contrôlé à chaque démrrage?

A l'origine ce sont des opération de maintenance sur la base rpm que j'aurai aimé réaliser. Comme la possibilité de supprimer tout les kernel-*-devel ... Est ce possible?

web123

Le rm -f /var/lib/rpm/__db.* est un "classique".
Mais, il faut bien vérifier qu'aucun processus n'utilise la base :
[c]# lsof /var/lib/rpm/*[/c]
=> ne doit rien retourner

Puis, le mieux est de reconstruire la base rpm :
[c]# rpm --rebuilddb[/c]

kwizart peux-tu dire ce que donne les commandes :
[c]# rpm -q kernel-deve
# rpm -q -a | grep "kernel.*devel"[/c]
C'est à titre informatif.

> Est ce qu'il y a des opérations de maintenance possible à faire sur ext3 ?

Normalement non.
La façon la plus simple de contrôler complètement la partition racine est de faire :
[c]# touch /forcefsck
# reboot[/c]
Il est possible de le faire sans reboot, mais c'est plus compliqué.

Pour les autres partitions (non racines):
# umount /dev/hdc1
# e2fsck -f /dev/hdc1 # le -f force la vérification

> Ou est ce que tout est contrôlé à chaque démrrage?

Tout est "contrôlé" au démarrage. un fsck est fait mais sans l'option "-f".
Fsck vérifie si le système de fichier est indiqué comme "clean" ou "dirty". S'il est clean, rien de particulier est fait. S'il est "dirty" et que c'est ext3, fsck "rejoue" le journal. S'il y a des problèmes alors le système passe en mode single user et demande l'intervention du super-utilisateur pour corriger le problème.

Pour que l'option "-f" soit utilisée au boot (l'option "-f" fait un contrôle complet, mais long), il faut soit que le fichier "/forcefsck" existe soit que l'utilisation du système de fichier est atteint un certain seuil (voir "man tune2fs" options -c -C -T -i). La commande dumpe2fs donne la configuration actuelle du système de fichier.

Ce que je viens de dire ne concerne que la partition racine.

Anvil

Le rm -f /var/lib/rpm/__db.* est un "classique".
Mais, il faut bien vérifier qu'aucun processus n'utilise la base :
# lsof /var/lib/rpm/*
=> ne doit rien retourner

Puis, le mieux est de reconstruire la base rpm :
# rpm --rebuilddb

si c'est une histoire avec les __db*, faire un rebuilddb ne sert a _rien_.
Sur une machine avec peu de ram, les rpms kernel* ont tendance a activer l'OOM-killer (OOM / Out Of Memory), donc ca peut correspondre au probleme...

kwizart

[kwizart@Kwizart ~]$ rpm -qa kernel-*devel
kernel-kdump-devel-2.6.17-1.2187_FC5
kernel-xenU-devel-2.6.17-1.2157_FC5
kernel-xen0-devel-2.6.17-1.2157_FC5
kernel-xen0-devel-2.6.16-1.2133_FC5
kernel-smp-devel-2.6.16-1.2133_FC5
kernel-devel-2.6.17-1.2157_FC5
kernel-xenU-devel-2.6.17-1.2187_FC5
kernel-kdump-devel-2.6.17-1.2174_FC5
kernel-xen0-devel-2.6.17-1.2187_FC5
kernel-smp-devel-2.6.17-1.2157_FC5
kernel-devel-2.6.17-1.2187_FC5
kernel-devel-2.6.17-1.2139_FC5
kernel-xen0-devel-2.6.17-1.2174_FC5
kernel-smp-devel-2.6.17-1.2139_FC5
kernel-devel-2.6.16-1.2133_FC5
kernel-smp-devel-2.6.17-1.2174_FC5
kernel-smp-devel-2.6.17-1.2187_FC5
kernel-devel-2.6.17-1.2174_FC5
kernel-xenU-devel-2.6.17-1.2174_FC5
kernel-xenU-devel-2.6.16-1.2133_FC5
kernel-kdump-devel-2.6.17-1.2157_FC5
kernel-kdump-devel-2.6.16-1.2133_FC5

Mais j'essaie de les desinstalller un par un! Par exemple:
rpm -e kernel-devel-2.6.16-1.2133_FC5

Je pensais pas avoir peu de RAM avec 512Mo, même si je comptais en rajouter dans quelques temps! Le problème c'est que je crois que la RAM a augmenté ces derniers temps!

Est ce qu'il est possible de générer un journal de l'utilisation de la RAM durant la commande et ce jusqu'au plantage probable ?

hum vais essayer quelquechose...

kwizart

Hummm

J'ai essayer de supprimer les rpms en mode init 3 avec le minium de service lancés...

Effectivement passé quelques instants j'ai un affichage sur des stats de mémoire qui se termine par:

Out of Memory: Kill process 13300 (rpm) score 7711 and children.
Out of Memory: Killed process 13300 (rpm).
processur arrêté

Par contre j'avais pas remarqué mais j'ai bien aussi des fichiers __db.00? !

Au pire FC6 n'est pas tres loin!
Par contre j'aimerai bien savoir d'ou cela viens, je pense que j'aurais du desintaller progressivement les kernel-devel - Mais est ce la raison ? Les autres rpms se desinstallent normalement!

grosminet

le controle de la ram peut etre effectuer par la commande suivante
vmstat -ns 5 T > /var/log/montestram
5 represente la frequence en secondes et T ne nombre de fois
il suffit de rediriger vers un fichier /var/log/montestram
supposons que le temps du test va durer

kwizart

effectivement j'ai fait un:
vmstat -ns 5 100 >> /var/log/testram &
puis essayé de retirer un rpm kernel-devel
on voit bien que la colonne free passe de 480228 -> 5044 (pour la mémoire)

C'est énorme comme consommation mémoire... Comment cela se fait? Comment faire le même controle pour l'utilisation du swap?

Anvil

Par contre j'avais pas remarqué mais j'ai bien aussi des fichiers __db.00? !

C'est pas parce que tu as des __db* que c'est derangeant. Pour 512Mo de ram, si tu as trop peu de swap, rpm ne va pas s'en sortir. (soyons lucide.. rpm fume. -_- souvent)
Gonfle ton swap (on peut faire des fichiers de swap, pas besoin d'une partition..), passe en init 1 , et retire les packages. Un par un.

grosminet

le script va realiser ta demande
int=0
finboucle=2
while [ $int -lt $finboucle ]
do
vmstat -s |awk ' {if (($3 ~/swap/)&&($2~/used/)){print $1}}
{if (($3 ~/swap/)&&($2~/free/)){print $1}}
'
sleep 5
let int=$int+1
done
il suffit de regler la valeur de fin de boucle et tu pourras visualiser la charge du swap
si tu desires enregistrer ces valeurs,
il faut remplacer print $1 > total
il faut remplacer print $1 > free
il suffit de faire join total free
sleep 5 est le temps de latence entre passage

kwizart

J'ai trouvé cela pour augmenter le swap:
http://www.linux-nantes.org/spip.php?article87

Par contre la ligne swap de la commande free était à 0 J'ai peut être mal activé ma partition swap 1.5G (elle est sur LVM!)
Apres avoir ajouté 2Gio en fichier swap j'ai pu supprimer un kernel-devel! Je vais en avoir pour la journée à tout supprimer vu le temps que cela prends!

Je pense que c'est Résolu! Merci à toi Anvil!

kwizart

Ok j'ai desinstallé tout les kernel-*devel j'ai récupéré au moins 1,2Gio pour 22 paquets installés!

Par contre il faut vérifier mon swap car je pense qu'il ne semble pas activé correctement!

Je ne comprend pas pouquoi le swap (en LVM) n'est pas monté automatiquement dans le fstab!
A quoi ressemble un swap monté en LVM ???

@grosminet
Merci pour ce script mais je pense que ce n'est pas nécéssaire...

grosminet

pour activer le swap
swapon -s
tu verra comment il est activé
swapon -s
Filename Type Size Used Priority
/dev/mapper/VolGroup00-LogVol01 partition 524280 84 -1
swapon
usage: swapon [-hV]
swapon -a [-e] [-v]
swapon [-v] [-p priority] special|LABEL=volume_name ...
swapon [-s]

kwizart

Hum ça a l'air de marcher!

swapon -s
ne donne rien
free:
Swap: 0 0 0

swapon /dev/VolGroup00/LogVol01

swapon -s
/dev/mapper/VolGroup00-LogVol01 partition 104858 etc...

free
Swap 1048568 0 1048568

Et donc comme ça- je me ballade sans swap!!!

Le problème c'est le configurer au démarrage! (fstab ?)
/dev/VolGroup00/LogVol01 none swap sw ?

web123

Anvil wrote:si c'est une histoire avec les __db*, faire un rebuilddb ne sert a _rien_.

Oui. Mais comme ça me semblait un peu le "bordel" dans la base de kwizart, je pensais qu'un rebuilddb ne pouvait pas faire de mal pour repartir sur une base peut-être plus saine.

grosminet

si tu fais swapon -a, cela devrait l'activer
le fstab devrait etre de ce type
more /etc/fstab
# This file is edited by fstab-sync - see 'man fstab-sync' for details
/dev/VolGroup00/LogVol00 / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
/dev/devpts /dev/pts devpts gid=5,mode=620 0 0
/dev/shm /dev/shm tmpfs defaults 0 0
/dev/VolGroup00/LogVol04 /home ext3 defaults 1 2
/dev/proc /proc proc defaults 0 0
/dev/sys /sys sysfs defaults 0 0
/dev/VolGroup00/LogVol02 /usr ext3 defaults 1 2
/dev/VolGroup00/LogVol03 /var ext3 defaults 1 2
/dev/VolGroup00/LogVol01 swap swap defaults 0 0
/dev/fd0 /media/floppy auto pamconsole,exec,noauto,utf8,managed 0 0
/dev/hdb /media/cdrecorder auto pamconsole,exec,noauto,managed 0 0

Page suivante »