problème résolu, l'upgrade est finie, maintenant c'est autre chose qui merde
Cet après-midi j'avais décidé d'upgrader ma mdk 9.2 en 10.0 via urpmi. Donc je configure les sources, urpmi --auto-select, tout part bien. Evidemment c'est à ce moment là que le disjoncteur décide de sauter. Et là tou part en couille.
Mon serveur X ne veut plus démarrer, je démarre donc en init 3.
Quand je veux relancer urpmi, il me dit :

J'ai essayé rpm --rebuilddb, mais ça me sort le même genre de messages. Visiblement mon rpm est salement amoché ; comment je peux récupérer ça ?

tu peux me montrer la lsite des fichiers dans /var/lib/rpm ?

Je suis pas sur mon PC donc c'est pas évident mais je n'ai pas de __db*, si c'est ce à quoi tu penses.

tu es dans la merde.
il y a une solution mais ce n'est même pas sûr de marcher ...

C'est le premier message qui m'inquiètes : ce truc de DB_PRIVATE veut dire que la Berkeley BD est configurée pour être accédée par un seul processus à la fois. Hors aucun processus n'est sensé y accéder en même temps que moi ; ça pourrait pas être un pauvre fichier lock à la con qui est resté qqpart ?

 
D'ailleurs, question: avec la Mandrake 10 community, les upgrade (quand il y aura la 11 par exemple) se font elles directement par urpmi, sans qu'il faille tout réinstaller.
PS: je débute avec Linux, donc je pose probablement des questions connes où sans queue ni tête

oui

 
Oui à quoi? Question conne où ma question sur les sources?

oui tu peux mettre à jour 9.2 vers 10.0 (par exemple) via urpmi.

sinon dark c'est quoi ta solution ? j'ai trouvé une piste avec une bidouille sur /etc/rpm/macros, mais ça ne m'inspire pas vraiment.

décompacter les anciens rpms relatif à rpm avec rpm2cpio

je propose comme ça, mais c'est peut-être dû au fait qu'une partie de l'update a été faite, à la rigueur la solution au bug de la fedora pourrait peut-être fonctionner :
 

 
j'avais eu le même problème en quelque sorte et ça été la solution

effectivement cette commande marche sans erreur. Mias après urpmi me met toujours le même message.
par contre en rebootant sur un ancien kernel urpmi se lance. Tu crois que si je fais l'update sous mon ancien kernel ça va résoudre le problème ?

le pb vient de NPTL ( New posix Thread Library ).
 
Botte sur un noyau 2.4, continues l'update et vois ce que cela donne à la fin

bon je vais tenter ça. a dans quelques heures

il y a 2 solutions proposée sur la ML de redhat :
 
- recompiler db4 avec --disable-posixmutexes
 
- supprimer purement et simplement /usr/lib/tls et /lib/tls puis relancer ldconfig
 
la 2ème solution est celle que j'ai adopté après avoir recompilé db4 avec --disable-posixmutexes et désactivé le support NPTL (ce qui n'avait pas réparé le problème en fait)

si la mise à jour se poursuit bien, le pb devrait être réglé

jusqu'ici tout va bien, 250 packages d'installés

bon ça y est tout s'est bien passé ou presque, en tout cas rpm remarche. Maintenant j'ai deux problèmes qui restent :
1/ X refuse de se lancer avec l'extension glx. Il reste bloqué sur "intializing extension GLX"
2/ le service hotplug refuse de s'arrêter. j'ai dans mon /var/log/messages  :

Et ça reste bloqué là. le gros problème c'est que ça empêche l'arrêt normal de la machine et que je suis obligé de l'arrêter au bouton
 
voila, si vous avez des pistes...
 
EDIT :
ah et puis 3/ mes fontes ont une sale gueule, genre trop fines ; surement un pb d'antialiasing mais j'y connais rien.

Alors pour ceux que ça intéresse :
1/ la réinstallation du pilote nvidia a réglé le problème
2/ c'était un problème de fichiers de configuration. urpmi n'a pas remplacé les fichiers dans /etc/hotplug, mais les a laissé en place et ajouté les nouveaux fichiers sous la forme nomdefichier.rpmnew. J'ai tout remplacé à la main et ça marche.
 
reste plus que les fonts qui font mal aux yeux.

active l'AA ou check le rafraichissement ( lance l'application krandrtray ) et si tu as le package libfreetype6 de plf installé, vire le et met celui de la mdk à la place