julz
Bonjour,
Voici mon histoire:
Ce matin, je me suis dit que j'allais mettre à jour ma distribution (FC4_64) pour FC5_64. J'insère donc un DVD testé OK de la distro, met le tout en mode upgrade et après une heure (c'est long!), anaconda plante à l'installation d'un rpm (j'ai encore le fichier log). Un redémarrage m'est proposé, ce que je fais et je remet l'upgrade en route, qui se termine en quelques minutes.
Au premier boot, il est impossible de partir X, donc je suis en mode texte uniquement. Selon /var/log/messages, X ne peut partir. En faisant 'which X', X n'est plus disponible. Le lien de /etc/X11/X qui pointait vers /usr/X11R6/bin/X est mort. Plus de X, disparu! J'ai rapidement repartitionné mon disque et installé FC5_64 sur une petite partition d'une façon temporaire. Je m'aperçois que X est maintenant dans /usr/bin/ (tout fonctionne très bien) /usr/X11R6 est presque vide!
Ce que je veux maintenant est de pouvoir faire en sorte que FC5 que j'ai upgradé fonctionne. (j'avais quand même d'autres trucs installés et je ne veux pas les réinstaller). Je me demande quelle stratégie prendre? Copier simplement les binaires et les librairies nécessaires à partir de ma nouvelle installation? Compiler X? J'essaie de l'installer à partir des rpm du disque, mais ce qui est étrange est que n'importe quel rpm xorg-x11 est dépendant de d'autres rpm... Je ne peux utiliser yum, car (autre problème), il semble qu'il manque un module à python quand j'essaie de le partir...
Quelle stratégie prendre pour arriver à mes fins sans trop de problème?
Merci!
Mon ordinateur: shuttle avec Athlon64 (AMD), chipset nforce3, carte graphique nvidia quadro 4 380 xgl.
Julien
julz
J'ai reussi a installer X en faisant
rpm -Uvh --force xorg*
X part bien quand je tape "X" dans le terminal. Aucune erreur dans le X.0.log
Maintenant, si je tombe en init 3 et repars en init 5, X ne pars toujours pas. Un tail sur /var/log/messages
permet de voir:
Apr 13 12:59:36 appart kdm_config[31029]: Unrecognized key 'Xservers' in section [General] at /usr/share/config/kdm/kdmrc:50
Apr 13 12:59:36 appart kdm_config[31029]: Unrecognized key 'SessionTypes' in section [X-*-Greeter] at /usr/share/config/kdm/kdmrc:244
Apr 13 12:59:36 appart kdm_config[31029]: Unrecognized key 'Themes' in section [X-*-Greeter] at /usr/share/config/kdm/kdmrc:336
Apr 13 12:59:36 appart kdm[31030]: X server "/usr/X11R6/bin/X" cannot be executed
Apr 13 12:59:36 appart kdm[31028]: X server for display :0 can't be started, session disabled
Or, mon kdmrc n'a pas change depuis un an! Une nouvelle version de kde serait-il a l'origine de ce probleme?
julz
Bon, c'etait deux problemes distincts...
J'ai juste fait une copie d'un nouveau kdmrc installe sur une autre partition de mon disque.
X ne partait pas, car le lien /usr/X11R6/bin/X -> /usr/bin/X etait mort. Je ne comprends pas pourquoi ce lien doit etre fait, mais bon... Maintenant tout fonctionne... presque
En fait, j'arrive a la fenetre de login et quand j'essaie de me logger, ca ne fonctionne pas (Login failed). Dans tty2, je me loggue parfaitement pourtant! La, je suis vraiment embete, car je ne vois pas de fichier log relatant l'evenement...
Chose etrange: quand X part, je vois d'abord (tres rapidement), le splash screen de Nvidia (normal), puis le nouveau login screen de fedora (bleu pale), puis un autre login screen (bleu fonce)...
Encore: a l'aide!
Julien
grosminet
si la mise à jour a deplacé le fonctionnement de la libairie, il semble qu'il ne faille plusieurs liens symboliques
Pour info sur la FC4 il y avait dans X11R6
ls
bin include lib man share
Regarde ce qui est dans le nouveau repertoire, il faudra créer les liens symboliques vers l'ensemble de bibliothèques
Sur la FC4
whereis startx
startx: /usr/X11R6/bin/startx /usr/bin/X11/startx
Regarde l'appel des comandes shell
more startx
#!/bin/sh
# $Xorg: startx.cpp,v 1.3 2000/08/17 19:54:29 cpqbld Exp $
#
# This is just a sample implementation of a slightly less primitive
# interface than xinit. It looks for user .xinitrc and .xserverrc
# files, then system xinitrc and xserverrc files, else lets xinit choose
# its default. The system xinitrc should probably do things like check
# for .Xresources files and merge them in, startup up a window manager,
# and pop a clock and serveral xterms.
#
# Site administrators are STRONGLY urged to write nicer versions.
#
# $XFree86: xc/programs/xinit/startx.cpp,v 3.16tsi Exp $
userclientrc=$HOME/.xinitrc
userserverrc=$HOME/.xserverrc
sysclientrc=/etc/X11/xinit/xinitrc
sysserverrc=/etc/X11/xinit/xserverrc
defaultclient=/usr/X11R6/bin/xterm
defaultserver=/usr/X11R6/bin/X
defaultclientargs=""
defaultserverargs=""
clientargs=""
serverargs=""
if [ -f $userclientrc ]; then
defaultclientargs=$userclientrc
elif [ -f $sysclientrc ]; then
defaultclientargs=$sysclientrc
fi
if [ -f $userserverrc ]; then
defaultserverargs=$userserverrc
elif [ -f $sysserverrc ]; then
defaultserverargs=$sysserverrc
fi
whoseargs="client"
while [ x"$1" != x ]; do
case "$1" in
# '' required to prevent cpp from treating "/*" as a C comment.
/''*|./''*)
if [ "$whoseargs" = "client" ]; then
if [ x"$clientargs" = x ]; then
client="$1"
else
clientargs="$clientargs $1"
fi
else
if [ x"$serverargs" = x ]; then
server="$1"
else
serverargs="$serverargs $1"
fi
fi
;;
--)
whoseargs="server"
;;
*)
if [ "$whoseargs" = "client" ]; then
clientargs="$clientargs $1"
else
# display must be the FIRST server argument
if [ x"$serverargs" = x ] &&
expr "$1" : ':[0-9][0-9]*$' > /dev/null 2>&1; then
display="$1"
else
serverargs="$serverargs $1"
fi
fi
;;
esac
shift
done
# process client arguments
if [ x"$client" = x ]; then
# if no client arguments either, use rc file instead
if [ x"$clientargs" = x ]; then
client="$defaultclientargs"
else
client=$defaultclient
fi
fi
# process server arguments
if [ x"$server" = x ]; then
# if no server arguments or display either, use rc file instead
if [ x"$serverargs" = x -a x"$display" = x ]; then
server="$defaultserverargs"
else
server=$defaultserver
fi
fi
if [ x"$XAUTHORITY" = x ]; then
XAUTHORITY=$HOME/.Xauthority
export XAUTHORITY
fi
removelist=
# set up default Xauth info for this machine
case `uname` in
Linux*)
if [ -z "`hostname --version 2>&1 | grep GNU`" ]; then
hostname=`hostname -f`
else
hostname=`hostname`
fi
;;
*)
hostname=`hostname`
;;
esac
authdisplay=${display:-:0}
mcookie=`mcookie`
for displayname in $authdisplay $hostname$authdisplay; do
if ! xauth list "$displayname" | grep "$displayname " >/dev/null 2>&1; then
xauth -q << EOF
add $displayname . $mcookie
EOF
removelist="$displayname $removelist"
fi
done
xinit $client $clientargs -- $server $display $serverargs
if [ x"$removelist" != x ]; then
xauth remove $removelist
fi
if command -v deallocvt > /dev/null 2>&1; then
deallocvt
fi
julz
Merci grosminet, mais ma strategie a ete tout autre: reinstallation!
Pour info, maintenant, dans FC5:
[julien@appart ~]# whereis startx
startx: /usr/bin/startx /usr/share/man/man1/startx.1x.gz
Bref, apres reinstallation, a apartir du DVD de tous les rpm xorg*, de kde, de gdm, il me reste encore plusieurs bugs (dont gnome, yum, pirut, firefox), bref, c'est la catastrophe!
Donc, conclusion: c'est l'upgrade qui a mal fonctionne (et qui ne fonctionne toujours pas!).
Ma question maintenant: Est-il possible de faire un rpm -Uvh uniquement sur les paquetages deja installes sous FC4, a partir du DVD de FC5
J'ai esssaye:
- pirut: ne fonctionne pas (Unable to retrieve software information)
- rpm -F * dans /mnt/cd/Fedora/RPMS du dvd de FC5: ne fonctionne pas
julz
Bon, j'ai toujours pas réglé tous mes problèmes, mais au moins je peux utiliser les applications dont j'ai besoin. D'ailleurs, l'origine du problème se trouve ailleurs sur ce forum!:
http://www.fedora-france.org/modules/newbb/viewtopic.php?topic_id=10920&forum=22&post_id=67535
http://www.fedora-france.org/modules/newbb/viewtopic.php?topic_id=10564&forum=22&post_id=66374
Bref, morales de l'histoire
1. Si FC4 (ou autre disto) fonctionne bien, ne rien faire!
2. Regarder ce qui se passe sur le net avant de faire quoi que ce soit!
