L'upgrade via fedup ne se termine pas : le processus reste bloqué sur le message 
finding updates 100% [=========================================================]
Par acquit de conscience, je l'ai laissé tourné toute la nuit, et je me retrouve avec plus de 5,6 millions de ligne dans /rout/fedupdebug.log !

A la lecture de ce fil, j'ai pensé qu'un noyau de F18 trop récent pouvait poser problème, et j'ai déinstallé le dernier, avant de faire un 
fedup --clean
comme indiqué ici, mais ça n'a rien changé.

Pour mémoire, les ennuis ont commencé depuis que j'ai voulu abandonner XFCE pour Gnome, de manière à pouvoir gérer les profils colorimétriques de mes écrans. F18 n'a jamais voulu se lancer correctement, je suis obligée de démarrer en mode 3 pour lancer manuellement startx à la main, et je me retrouve systématiquement sous XFCE. 🙁

La situation actuelle :
- impossible de démarrer la machine autrement qu'en mode 3, ce qui me permet de fonctionner en mode dégradé (sous XFCE et sans gestion de profils)
- je ne réussis pas à avoir un F18 fonctionnel
- l'upgrade vers F19 ne peut pas se faire.

Merci beaucoup pour vos suggestions, j'ai vraiment besoin de retrouver un usage normal de ma machine au plus vite.
1 - Tu as lancé quelle commande ?
2 - As-tu des dépôts tiers activés (yum repolist) ?
3 - Quel est le contenu de ton fichier /root/fedupdebug.log (sans les lignes redondantes à la fin) ?
Merci pour ta réponse. Je commençais à me sentir très seule, il doit y avoir pas mal de monde en vacances. 😉
Nicosss wrote:1 - Tu as lancé quelle commande ?
fedup-cli --network 19 --debuglog=fedupdebug.log
Nicosss wrote:2 - As-tu des dépôts tiers activés (yum repolist) ?
Pas grand chose d'exotique : 
Modules complémentaires chargés : langpacks, presto, refresh-packagekit
id du dépôt                         nom du dépôt                          statut
Dropbox/18                          Dropbox Repository                         4
fedora/18/x86_64                    Fedora 18 - x86_64                    33 868
fedora-chromium-stable/18/x86_64    Builds of the "stable" tag of the Chr     28
google-chrome                       google-chrome                              3
rpmfusion-free/18/x86_64            RPM Fusion for Fedora 18 - Free          469
rpmfusion-free-updates/18/x86_64    RPM Fusion for Fedora 18 - Free - Upd    606
rpmfusion-nonfree/18/x86_64         RPM Fusion for Fedora 18 - Nonfree       214
rpmfusion-nonfree-updates/18/x86_64 RPM Fusion for Fedora 18 - Nonfree -     506
updates/18/x86_64                   Fedora 18 - x86_64 - Updates          16 935
repolist: 52 633
Nicosss wrote:3 - Quel est le contenu de ton fichier /root/fedupdebug.log (sans les lignes redondantes à la fin) ?
Vu la taille du fichier, j'ai énormément de mal à l'ouvrir, tous les programmes en cours s'arrêtent un bon moment ... D'après ce que j'ai vu, il n'y avait pas de lignes redondantes à la fin, juste des messages "ordinaires".
La précédente version - qui fait tout de même près de 112.000 lignes - se termine par les lignes suivantes : 
[   890.821] (DD) fedup.depsolve:pkgAdded() added python-django.noarch for ud
[   890.824] (DD) fedup.depsolve:pkgAdded() added python-django.noarch for ud
[   890.826] (DD) fedup.depsolve:pkgAdded() added sssd.x86_64 for ud
[   890.829] (DD) fedup.depsolve:procReqPo() req po:   sssd = 1.9.5-2.fc18 → libsss_sudo-1.9.5-2.fc18.x86_64
[   890.829] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: libsss_sudo-1.9.5-2.fc18.x86_64 requires sssd
[   890.829] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: libsss_sudo-1.9.5-2.fc18.x86_64 requires sssd
[   890.829] (DD) fedup.depsolve:pkgAdded() added systemd.x86_64 for ud
[   890.841] (DD) fedup.depsolve:procReqPo() req po:   systemd = 201-2.fc18.7 → systemd-python-201-2.fc18.7.x86_64
[   890.842] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: systemd-python-201-2.fc18.7.x86_64 requires systemd
[   890.842] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: systemd-python-201-2.fc18.7.x86_64 requires systemd
[   890.842] (DD) fedup.depsolve:procReqPo() req po:   systemd = 201-2.fc18.7 → libgudev1-201-2.fc18.7.x86_64
[   890.842] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: libgudev1-201-2.fc18.7.x86_64 requires systemd
[   890.842] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: libgudev1-201-2.fc18.7.x86_64 requires systemd
[   890.842] (DD) fedup.depsolve:procReqPo() req po:   systemd = 201-2.fc18.7 → systemd-sysv-201-2.fc18.7.x86_64
[   890.843] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: systemd-sysv-201-2.fc18.7.x86_64 requires systemd
[   890.843] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: systemd-sysv-201-2.fc18.7.x86_64 requires systemd
Essaye de faire le fedup sans les dépôts tiers.
# fedup-cli --clean
# fedup-cli --disablerepo Dropbox --disablerepo google-chrome --disablerepo fedora-chromium-stable --network 19 --debuglog=fedupdebug.log
Ca a été hyper-rapide cette fois : 
[root@toshiba4 ~]# fedup-cli --disablerepo Dropbox --disablerepo google-chrome --disablerepo fedora-chromium-stable --network 19 --debuglog=fedupdebug.log
setting up repos...
default-installrepo/metalink                             |  31 kB     00:00     
fedora/19/x86_64/metalink                                |  32 kB     00:00     
fedora/19/x86_64                                         | 4.2 kB     00:00     
fedora/19/x86_64/primary_db                              |  17 MB     01:16     
rpmfusion-free/19/x86_64                                 | 3.3 kB     00:00     
rpmfusion-free/19/x86_64/primary_db                      | 440 kB     00:01     
rpmfusion-free-updates/19/x86_64                         | 3.3 kB     00:00     
rpmfusion-free-updates/19/x86_64/primary_db              |  87 kB     00:00     
rpmfusion-nonfree/19/x86_64                              | 3.3 kB     00:00     
rpmfusion-nonfree/19/x86_64/primary_db                   | 149 kB     00:00     
rpmfusion-nonfree-updates/19/x86_64                      | 3.3 kB     00:00     
rpmfusion-nonfree-updates/19/x86_64/primary_db           |  48 kB     00:00     
updates/19/x86_64/metalink                               |  30 kB     00:00     
updates/19/x86_64                                        | 4.6 kB     00:00     
updates/19/x86_64                                        | 4.6 kB     00:00     
updates/19/x86_64/primary_db                             | 6.8 MB     00:30     
Error: can't get boot images.
The installation repo isn't available.
You need to specify one with --instrepo.
Est-ce simplement une indisponibilité momentanée du dépôt, et je dois attendre un peu avant de relancer ?
Ou y a-t-il un problème dans ma configuration ?
Nicosss wrote: Quel est le contenu de ton fichier /root/fedupdebug.log ?
Absolument inchargeable : il fait plus de 600Mo !
Est-ce qu'il ne repart pas à chaque fois sur un fichier neuf ? Il faut alors que je le vire, ou que je le renomme ?
Nicosss wrote:Possible que ce soit une indispo momentanée, essaye de retenter dans un moment.
Il est reparti, sans le message d'erreur sur le dépôt d'installation cette fois ; mais il est de nouveau bloqué sur finding updates 100%.
Est-ce normal qu'il ne "dise" plus rien ? Dans mes souvenirs, il "causait" quasiment sans arrêt jusqu'à donner l'ordre de rebooter. :-?
Je ne sais pas s'il est écrasé mais tu peux l'effacer sans problème, il sera recréé.
Nicosss wrote:Je ne sais pas s'il est écrasé mais tu peux l'effacer sans problème, il sera recréé.
C'est fait.
Maintenant, je me demande si j'attends encore, ou si je "tue" le process pour aller voir ce qu'il y a dans le fichier.
Tu veux tuer quoi et pourquoi ?

Il faut laisser Fedup bosser sinon tu risques avoir des problèmes, tu peux toujours consulter le fichier.
Nicosss wrote:Tu veux tuer quoi et pourquoi ?

Il faut laisser Fedup bosser sinon tu risques avoir des problèmes, tu peux toujours consulter le fichier.
La dernière fois que j'ai laissé tourner fedup, ça a duré toute cette nuit avec pour seul résultat un fichier log monstrueux et inexploitable. :-?
Je ne comprends pas qu'il ne donne plus aucun message à la console : lorsque j'avais upgradé vers F18, le déroulement était clairement visible ; là, je ne vois rien !
Ca tourne toujours, et le fichier log a dépassé les 350Mo : 
[root@toshiba4 ~]# ls -l /root/fedupdebug.log
-rw-r--r-- 1 root root 352700100 12 août  14:13 /root/fedupdebug.log
Est-ce bien normal ?
Non pas bien, fedup-cli est verbeux donc tu devrais voir à minima l'avancement du téléchargement des paquets.

Tu peux consulter le fichier pendant qu'il travaille, tu verras sur quoi il bloque, je pensais que c'était ce que tu avais fait. Il faut déterminer ce qui l'empêche d'aller plus loin.
Nicosss wrote:Non pas bien, fedup-cli est verbeux donc tu devrais voir à minima l'avancement du téléchargement des paquets.
C'était bien ce qu'il me semblait. 😉
Nicosss wrote:Tu peux consulter le fichier pendant qu'il travaille ...
Je fais ça comment ?
J'ai essayé par tail : 
[root@toshiba4 ~]# tail /root/fedupdebug.log
[ 18288.316] (DD) fedup.depsolve:pkgAdded() added systemd.x86_64 for ud
[ 18288.326] (DD) fedup.depsolve:procReqPo() req po:   systemd = 201-2.fc18.7 → systemd-python-201-2.fc18.7.x86_64
[ 18288.326] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: systemd-python-201-2.fc18.7.x86_64 requires systemd
[ 18288.327] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: systemd-python-201-2.fc18.7.x86_64 requires systemd
[ 18288.327] (DD) fedup.depsolve:procReqPo() req po:   systemd = 201-2.fc18.7 → libgudev1-201-2.fc18.7.x86_64
[ 18288.327] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: libgudev1-201-2.fc18.7.x86_64 requires systemd
[ 18288.327] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: libgudev1-201-2.fc18.7.x86_64 requires systemd
[ 18288.327] (DD) fedup.depsolve:procReqPo() req po:   systemd = 201-2.fc18.7 → systemd-sysv-201-2.fc18.7.x86_64
[ 18288.327] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: systemd-sysv-201-2.fc18.7.x86_64 requires systemd
[ 18288.327] (DD) fedup.depsolve:format_missing_requires() MISSING REQ: systemd-sysv-201-2.fc18.7.x86_64 requires systemd
EDIT : et en répétant la commande, j'ai l'impression qu'il boucle toujours sur la même chose.
Tu peux faire un cat ou tac ou more ou less ou ... bref si tu fais tail tu peux aussi ajouter l'option -f comme ça tu verras le défilement au fur et à mesure.

Etrange on dirait que tu n'as pas systemd ?
Nicosss wrote: Etrange on dirait que tu n'as pas systemd ?
Je ne sais pas à quoi ça sert, mais j'en ai 2 : 
yum info systemd
Modules complémentaires chargés : langpacks, presto, refresh-packagekit
Paquets installés
Nom                 : systemd
Architecture        : x86_64
Version             : 201
Révision            : 2.fc18.7
Taille              : 10 M
Dépôt               : installed
Résumé              : A System and Service Manager
URL                 : http://www.freedesktop.org/wiki/Software/systemd
Licence             : LGPLv2+ and MIT and GPLv2+
Description         : systemd is a system and service manager for Linux,
                    : compatible with SysV and LSB init scripts. systemd
                    : provides aggressive parallelization capabilities, uses
                    : socket and D-Bus activation for starting services, offers
                    : on-demand starting of daemons, keeps track of processes
                    : using Linux cgroups, supports snapshotting and restoring
                    : of the system state, maintains mount and automount points
                    : and implements an elaborate transactional dependency-based
                    : service control logic. It can work as a drop-in
                    : replacement for sysvinit.

Nom                 : systemd
Architecture        : x86_64
Version             : 204
Révision            : 9.fc19
Taille              : 10 M
Dépôt               : installed
Résumé              : A System and Service Manager
URL                 : http://www.freedesktop.org/wiki/Software/systemd
Licence             : LGPLv2+ and MIT and GPLv2+
Description         : systemd is a system and service manager for Linux,
                    : compatible with SysV and LSB init scripts. systemd
                    : provides aggressive parallelization capabilities, uses
                    : socket and D-Bus activation for starting services, offers
                    : on-demand starting of daemons, keeps track of processes
                    : using Linux cgroups, supports snapshotting and restoring
                    : of the system state, maintains mount and automount points
                    : and implements an elaborate transactional dependency-based
                    : service control logic. It can work as a drop-in
                    : replacement for sysvinit.
Si je vire celui de F19, ça peut arranger les choses ?
En fait tu as une version fc19 et supérieure de systemd d'installée qui du coup pose problème.

Peux-tu donner le retour de 
$ rpm -qa | grep fc19
Il faudrait les logs pour comprendre ce qui se passe.
Nicosss wrote:En fait tu as une version fc19 et supérieure de systemd d'installée qui du coup pose problème.

Peux-tu donner le retour de 
$ rpm -qa | grep fc19
Y a des tonnes de trucs, je fais un fichier sur Dropbox.
Nicosss wrote:Il faudrait les logs pour comprendre ce qui se passe.
Je peux faire la même chose mais il faudrait que j'arrête le process qui continue à tourner, non ? Sinon, je ne pourrai pas faire la copie.
Tu as redémarré entre temps ? Tu n'as appliqué par hasard la migration depuis le GRUB ?

Si tu sembles avoir autant de paquets fc19 installés il y a un hic.

Que retourne 
$ cat /etc/fedora-release
Nicosss wrote:Tu as redémarré entre temps ?
Oui, j'ai redémarré plusieurs fois. Mais pas depuis que je l'ai lancé ce matin ... et qu'il tourne toujours
Nicosss wrote:Tu n'as appliqué par hasard la migration depuis le GRUB ?
??? Je ne comprends pas la question.
Nicosss wrote:Si tu sembles avoir autant de paquets fc19 installés il y a un hic.

Que retourne 
$ cat /etc/fedora-release
Fedora release 19 (Schrödinger’s Cat)
Je "kill" fedup car je ne peux pas accéder aux fichiers, et ça ne paraît de toute manière mener à rien.
Lien vers le dossier Dropbox.
La sortie du rpm -qa est disponible ; la log de fedup fait 859Mo et est plus longue à synchroniser.
En fait tu as redémarré après le premier fedup et tu avais une entrée Fedup dans ton Grub que tu as sélectionnée.

La migration a été effectuée mais pas complètement... il y a des chance que l'opération au début ait été interrompue.

Ce n'est plus la peine de lancer un fedup.

Il va falloir comparer les fichiers fc18 et fc19 pour voir si tu as tout et auquel cas retirer ceux en fc18.

Cette partie t'aidera après http://doc.fedora-fr.org/wiki/FedUp_:_Passer_%C3%A0_la_version_sup%C3%A9rieure_de_Fedora#Finalisation
Nicosss wrote: Il va falloir comparer les fichiers fc18 et fc19 pour voir si tu as tout et auquel cas retirer ceux en fc18.
Il y a une commande qui peut faire ça ?
Tu as quel kernel actuellement 
$ uname -a
Que retourne 
# grep "Fedora " /boot/grub2/grub.cfg
Normalement si tu es en Fedora 19 la commande suivante devrait faire un état des lieux 
# package-cleanup --dupes
Pour faire le ménage ce sera l'option --cleandupes .
Nicosss wrote:Tu as quel kernel actuellement 
$ uname -a
# uname -a
Linux toshiba4.mna 3.9.11-200.fc18.x86_64 #1 SMP Mon Jul 22 21:04:50 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Nicosss wrote:Que retourne 
# grep "Fedora " /boot/grub2/grub.cfg
Là, je n'ai rien.
Mais en retirant l'espace après Fedora : 
# grep "Fedora" /boot/grub2/grub.cfg 
menuentry 'Fedora' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-d8ca625b-8c13-475b-80ce-97b8c32f4f9a' {
submenu 'Options avancées pour Fedora' $menuentry_id_option 'gnulinux-advanced-d8ca625b-8c13-475b-80ce-97b8c32f4f9a' {
	menuentry 'Fedora, avec Linux 3.9.11-200.fc18.x86_64' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.9.11-200.fc18.x86_64-advanced-d8ca625b-8c13-475b-80ce-97b8c32f4f9a' {
	menuentry 'Fedora, avec Linux 3.9.11-200.fc18.x86_64 (mode de dépannage)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.9.11-200.fc18.x86_64-recovery-d8ca625b-8c13-475b-80ce-97b8c32f4f9a' {
	menuentry 'Fedora, avec Linux 3.9.10-100.fc17.x86_64' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.9.10-100.fc17.x86_64-advanced-d8ca625b-8c13-475b-80ce-97b8c32f4f9a' {
	menuentry 'Fedora, avec Linux 3.9.10-100.fc17.x86_64 (mode de dépannage)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.9.10-100.fc17.x86_64-recovery-d8ca625b-8c13-475b-80ce-97b8c32f4f9a' {
Pas beaucoup de F19, là-dedans ! :-?
Nicosss wrote:Normalement si tu es en Fedora 19 la commande suivante devrait faire un état des lieux 
# package-cleanup --dupes
Pour faire le ménage ce sera l'option --cleandupes .
Je lance ... ou pas ?
Bon effectivement ce n'est pas super confortable comme situation...

Oui tu peux lancer avec --dupes il n'y aura pas d'action.

Par contre je suis étonné de ne voir que 2 kernels, 1 en fc18 et l'autre en fc17 dans ton Grub. Tu as une explication ?
Nicosss wrote: Par contre je suis étonné de ne voir que 2 kernels, 1 en fc18 et l'autre en fc17 dans ton Grub. Tu as une explication ?
Je ne sais pas si ça répond à ta question, mais :
- ça ne fait que quelques jours que j'étais passée en F18
- j'étais effectivement étonnée d'avoir très peu de mises à jour, notamment pour le kernel (mais peut-être que fedup charge directement les paquets les plus récents ?)
- j'ai viré le kernel F18 le plus récent lorsque j'ai vu qu'il pouvait poser problème dans le fedup vers F19.
Nicosss wrote: Oui tu peux lancer avec --dupes il n'y aura pas d'action.
Apparemment, tous les paquets sont en double selon --dupes ... mais --cleandupes ne fonctionne pas : l'écran défilait à la vitesse grand V, sans que les choses ne paraissent progresser. Au Ctrl-C, je récupère ceci à la console : 
--> Lancement de la transaction de test
---> Le paquet GConf2-gtk.x86_64 0:3.2.6-2.fc18 sera effacé
--> Traitement de la dépendance : GConf2 = 3.2.6-2.fc18 pour le paquet : GConf2-gtk-3.2.6-2.fc18.x86_64
---> Le paquet libsss_sudo.x86_64 0:1.9.5-2.fc18 sera effacé
--> Traitement de la dépendance : sssd = 1.9.5-2.fc18 pour le paquet : libsss_sudo-1.9.5-2.fc18.x86_64
---> Le paquet php-mysql.x86_64 0:5.4.17-2.fc18 sera effacé
--> Traitement de la dépendance : php-pdo(x86-64) = 5.4.17-2.fc18 pour le paquet : php-mysql-5.4.17-2.fc18.x86_64
---> Le paquet pulseaudio-utils.x86_64 0:2.1-6.fc18 sera effacé
--> Traitement de la dépendance : pulseaudio-libs(x86-64) = 2.1-6.fc18 pour le paquet : pulseaudio-utils-2.1-6.fc18.x86_64
--> Traitement de la dépendance : libpulsecommon-2.1.so()(64bit) pour le paquet : pulseaudio-utils-2.1-6.fc18.x86_64
---> Le paquet setools-libs-python.x86_64 0:3.3.7-34.fc18 sera effacé
--> Traitement de la dépendance : setools-libs = 3.3.7-34.fc18 pour le paquet : setools-libs-python-3.3.7-34.fc18.x86_64
---> Le paquet xorg-x11-drv-ast.x86_64 0:0.97.0-2.fc18 sera effacé
--> Traitement de la dépendance : xserver-abi(videodrv-13) >= 0 pour le paquet : xorg-x11-drv-ast-0.97.0-2.fc18.x86_64
--> Lancement de la transaction de test
---> Le paquet GConf2-gtk.x86_64 0:3.2.6-2.fc18 sera effacé
---> Le paquet libsss_sudo.x86_64 0:1.9.5-2.fc18 sera effacé
---> Le paquet php-mysql.x86_64 0:5.4.17-2.fc18 sera effacé
---> Le paquet pulseaudio-utils.x86_64 0:2.1-6.fc18 sera effacé
---> Le paquet setools-libs-python.x86_64 0:3.3.7-34.fc18 sera effacé
---> Le paquet xorg-x11-drv-ast.x86_64 0:0.97.0-2.fc18 sera effacé
--> Redémarrage de la résolution des dépendances avec les nouveaux changements.
--> Lancement de la transaction de test
---> Le paquet GConf2-gtk.x86_64 0:3.2.6-2.fc18 sera effacé
--> Traitement de la dépendance : GConf2 = 3.2.6-2.fc18 pour le paquet : GConf2-gtk-3.2.6-2.fc18.x86_64
---> Le paquet libsss_sudo.x86_64 0:1.9.5-2.fc18 sera effacé
--> Traitement de la dépendance : sssd = 1.9.5-2.fc18 pour le paquet : libsss_sudo-1.9.5-2.fc18.x86_64
---> Le paquet php-mysql.x86_64 0:5.4.17-2.fc18 sera effacé
--> Traitement de la dépendance : php-pdo(x86-64) = 5.4.17-2.fc18 pour le paquet : php-mysql-5.4.17-2.fc18.x86_64
---> Le paquet pulseaudio-utils.x86_64 0:2.1-6.fc18 sera effacé
--> Traitement de la dépendance : pulseaudio-libs(x86-64) = 2.1-6.fc18 pour le paquet : pulseaudio-utils-2.1-6.fc18.x86_64
--> Traitement de la dépendance : libpulsecommon-2.1.so()(64bit) pour le paquet : pulseaudio-utils-2.1-6.fc18.x86_64
---> Le paquet setools-libs-python.x86_64 0:3.3.7-34.fc18 sera effacé
--> Traitement de la dépendance : setools-libs = 3.3.7-34.fc18 pour le paquet : setools-libs-python-3.3.7-34.fc18.x86_64
---> Le paquet xorg-x11-drv-ast.x86_64 0:0.97.0-2.fc18 sera effacé
--> Traitement de la dépendance : xserver-abi(videodrv-13) >= 0 pour le paquet : xorg-x11-drv-ast-0.97.0-2.fc18.x86_64
--> Lancement de la transaction de test
---> Le paquet GConf2-gtk.x86_64 0:3.2.6-2.fc18 sera effacé
---> Le paquet libsss_sudo.x86_64 0:1.9.5-2.fc18 sera effacé
---> Le paquet php-mysql.x86_64 0:5.4.17-2.fc18 sera effacé
---> Le paquet pulseaudio-utils.x86_64 0:2.1-6.fc18 sera effacé
---> Le paquet setools-libs-python.x86_64 0:3.3.7-34.fc18 sera effacé
---> Le paquet xorg-x11-drv-ast.x86_64 0:0.97.0-2.fc18 sera effacé
--> Redémarrage de la résolution des dépendances avec les nouveaux changements.
--> Lancement de la transaction de test
---> Le paquet GConf2-gtk.x86_64 0:3.2.6-2.fc18 sera effacé
--> Traitement de la dépendance : GConf2 = 3.2.6-2.fc18 pour le paquet : GConf2-gtk-3.2.6-2.fc18.x86_64
---> Le paquet libsss_sudo.x86_64 0:1.9.5-2.fc18 sera effacé
--> Traitement de la dépendance : sssd = 1.9.5-2.fc18 pour le paquet : libsss_sudo-1.9.5-2.fc18.x86_64
---> Le paquet php-mysql.x86_64 0:5.4.17-2.fc18 sera effacé
--> Traitement de la dépendance : php-pdo(x86-64) = 5.4.17-2.fc18 pour le paquet : php-mysql-5.4.17-2.fc18.x86_64
---> Le paquet pulseaudio-utils.x86_64 0:2.1-6.fc18 sera effacé
--> Traitement de la dépendance : pulseaudio-libs(x86-64) = 2.1-6.fc18 pour le paquet : pulseaudio-utils-2.1-6.fc18.x86_64
--> Traitement de la dépendance : libpulsecommon-2.1.so()(64bit) pour le paquet : pulseaudio-utils-2.1-6.fc18.x86_64
---> Le paquet setools-libs-python.x86_64 0:3.3.7-34.fc18 sera effacé
--> Traitement de la dépendance : setools-libs = 3.3.7-34.fc18 pour le paquet : setools-libs-python-3.3.7-34.fc18.x86_64
---> Le paquet xorg-x11-drv-ast.x86_64 0:0.97.0-2.fc18 sera effacé
--> Traitement de la dépendance : xserver-abi(videodrv-13) >= 0 pour le paquet : xorg-x11-drv-ast-0.97.0-2.fc18.x86_64
--> Lancement de la transaction de test
---> Le paquet GConf2-gtk.x86_64 0:3.2.6-2.fc18 sera effacé
---> Le paquet libsss_sudo.x86_64 0:1.9.5-2.fc18 sera effacé
---> Le paquet php-mysql.x86_64 0:5.4.17-2.fc18 sera effacé
---> Le paquet pulseaudio-utils.x86_64 0:2.1-6.fc18 sera effacé
---> Le paquet setools-libs-python.x86_64 0:3.3.7-34.fc18 sera effacé
---> Le paquet xorg-x11-drv-ast.x86_64 0:0.97.0-2.fc18 sera effacé
^C--> Redémarrage de la résolution des dépendances avec les nouveaux changements.
--> Lancement de la transaction de test
---> Le paquet GConf2-gtk.x86_64 0:3.2.6-2.fc18 sera effacé
--> Traitement de la dépendance : GConf2 = 3.2.6-2.fc18 pour le paquet : GConf2-gtk-3.2.6-2.fc18.x86_64
Ca me semble boucler grave ! 🙁
Pinaise c'est le chantier ton install...

Essaye de faire 
# yum clean all && yum distribution-synchronization --disablepresto
Sinon faudra essayer de virer tous ceux en fc18 avec une commande du genre 
#yum remove "*fc18*" --exclude=kernel\*
Nicosss wrote:Pinaise c'est le chantier ton install...
Ca l'était déjà avant, puisque je ne pouvais plus booter autrement qu'en mode 3, ni accéder à Gnome. 🙁
Nicosss wrote:Essaye de faire 
# yum clean all && yum distribution-synchronization --disablepresto
Ca mouline à grande vitesse. J'ai réussi à choper ça au passage : 
---> Le paquet gettext.x86_64 0:0.18.1.1-17.fc18 sera une rétrogradation
---> Le paquet gettext.x86_64 0:0.18.2.1-1.fc19 sera effacé
---> Le paquet gettext-common-devel.noarch 0:0.18.1.1-17.fc18 sera une rétrogradation
---> Le paquet gettext-common-devel.noarch 0:0.18.2.1-1.fc19 sera effacé
---> Le paquet gettext-devel.x86_64 0:0.18.1.1-17.fc18 sera une rétrogradation
---> Le paquet gettext-devel.x86_64 0:0.18.2.1-1.fc19 sera effacé
---> Le paquet gettext-libs.x86_64 0:0.18.1.1-17.fc18 sera une rétrogradation
---> Le paquet gettext-libs.x86_64 0:0.18.2.1-1.fc19 sera effacé
---> Le paquet ghostscript.x86_64 0:9.06-4.fc18 sera une rétrogradation
---> Le paquet ghostscript.x86_64 0:9.07-10.fc19 sera effacé
---> Le paquet ghostscript-cups.x86_64 0:9.06-4.fc18 sera une rétrogradation
---> Le paquet ghostscript-cups.x86_64 0:9.07-10.fc19 sera effacé
---> Le paquet ghostscript-fonts.noarch 0:5.50-29.fc18 sera une rétrogradation
---> Le paquet ghostscript-fonts.noarch 0:5.50-30.fc19 sera effacé
---> Le paquet giflib.x86_64 0:4.1.6-6.fc18 sera une rétrogradation
---> Le paquet giflib.x86_64 0:4.1.6-7.fc19 sera effacé
---> Le paquet gimp.x86_64 2:2.8.6-3.fc18 sera une rétrogradation
---> Le paquet gimp.x86_64 2:2.8.6-3.fc19 sera effacé
---> Le paquet gimp-libs.x86_64 2:2.8.6-3.fc18 sera une rétrogradation
---> Le paquet gimp-libs.x86_64 2:2.8.6-3.fc19 sera effacé
---> Le paquet git.x86_64 0:1.8.1.4-2.fc18 sera une rétrogradation
---> Le paquet git.x86_64 0:1.8.3.1-1.fc19 sera effacé
---> Le paquet gjs.x86_64 0:1.34.0-1.fc18 sera une rétrogradation
---> Le paquet gjs.x86_64 0:1.36.1-1.fc19 sera effacé
---> Le paquet gl-manpages.noarch 0:1.1-5.20130122.fc18 sera une rétrogradation
---> Le paquet gl-manpages.noarch 0:1.1-6.20130122.fc19 sera effacé
---> Le paquet glade-libs.x86_64 0:3.14.2-2.fc18 sera une rétrogradation
---> Le paquet glade-libs.x86_64 0:3.15.0-1.fc19 sera effacé
---> Le paquet glib.x86_64 1:1.2.10-37.fc18 sera une rétrogradation
---> Le paquet glib.x86_64 1:1.2.10-39.fc19 sera effacé
---> Le paquet glib-devel.x86_64 1:1.2.10-37.fc18 sera une rétrogradation
---> Le paquet glib-devel.x86_64 1:1.2.10-39.fc19 sera effacé
---> Le paquet glib-networking.x86_64 0:2.34.2-1.fc18 sera une rétrogradation
---> Le paquet glib-networking.x86_64 0:2.36.2-1.fc19 sera effacé
---> Le paquet glib2.x86_64 0:2.34.2-2.fc18 sera une rétrogradation
---> Le paquet glib2.x86_64 0:2.36.3-3.fc19 sera effacé
---> Le paquet glib2-devel.x86_64 0:2.34.2-2.fc18 sera une rétrogradation
---> Le paquet glib2-devel.x86_64 0:2.36.3-3.fc19 sera effacé
---> Le paquet glibc.x86_64 0:2.16-33.fc18 sera une rétrogradation
---> Le paquet glibc.x86_64 0:2.17-11.fc19 sera effacé
et je comprends qu'il va garder les versions F18 et virer les F19 !

Et ça se termine comme ça : 
xulrunner-23.0-2.fc19.x86_64 est un doublon de xulrunner-22.0-4.fc18.x86_64
xvidcore-1.3.2-5.fc19.x86_64 est un doublon de xvidcore-1.3.2-3.fc17.x86_64
xz-5.1.2-4alpha.fc19.x86_64 est un doublon de xz-5.1.2-2alpha.fc18.x86_64
xz-devel-5.1.2-4alpha.fc19.x86_64 est un doublon de xz-devel-5.1.2-2alpha.fc18.x86_64
xz-libs-5.1.2-4alpha.fc19.x86_64 est un doublon de xz-libs-5.1.2-2alpha.fc18.x86_64
yajl-2.0.4-2.fc19.x86_64 est un doublon de yajl-2.0.4-1.fc18.x86_64
1:yelp-3.8.1-5.fc19.x86_64 est un doublon de 1:yelp-3.6.2-1.fc18.x86_64
1:yelp-libs-3.8.1-5.fc19.x86_64 est un doublon de 1:yelp-libs-3.6.2-1.fc18.x86_64
yelp-xsl-3.8.1-1.fc19.noarch est un doublon de yelp-xsl-3.6.1-1.fc18.noarch
yp-tools-2.14-1.fc19.x86_64 est un doublon de yp-tools-2.12-11.fc18.x86_64
3:ypbind-1.37.1-3.fc19.x86_64 est un doublon de 3:ypbind-1.36-7.fc18.x86_64
yum-3.4.3-105.fc19.noarch est un doublon de yum-3.4.3-54.fc18.noarch
yum-metadata-parser-1.1.4-8.fc19.x86_64 est un doublon de yum-metadata-parser-1.1.4-7.fc18.x86_64
yum-utils-1.1.31-17.fc19.noarch est un doublon de yum-utils-1.1.31-10.fc18.noarch
zbar-0.10-15.fc19.x86_64 est un doublon de zbar-0.10-11.fc18.x86_64
zenity-3.8.0-2.fc19.x86_64 est un doublon de zenity-3.6.0-1.fc18.x86_64
zeromq3-3.2.3-1.fc19.x86_64 est un doublon de zeromq3-3.2.3-1.fc18.x86_64
zip-3.0-7.fc19.x86_64 est un doublon de zip-3.0-5.fc18.x86_64
zlib-1.2.7-10.fc19.x86_64 est un doublon de zlib-1.2.7-9.fc18.x86_64
zlib-devel-1.2.7-10.fc19.x86_64 est un doublon de zlib-devel-1.2.7-9.fc18.x86_64
zvbi-0.2.33-15.fc19.x86_64 est un doublon de zvbi-0.2.33-14.fc18.x86_64
C'est grave, docteur ?
J'ai tenté ce qui était indiqué tout à la fin de cette page cette page, et voilà le résultat : 
# package-cleanup --problems
Modules complémentaires chargés : langpacks, presto, refresh-packagekit
Package avahi-autoipd-0.6.31-6.fc18.x86_64 des conflits sont installés avahi > ('0', '0.6.31', '6.fc18'): avahi-0.6.31-11.fc19.x86_64
Package avahi-autoipd-0.6.31-11.fc19.x86_64 des conflits sont installés avahi < ('0', '0.6.31', '11.fc19'): avahi-0.6.31-6.fc18.x86_64
Package avahi-glib-0.6.31-6.fc18.x86_64 des conflits sont installés avahi > ('0', '0.6.31', '6.fc18'): avahi-0.6.31-11.fc19.x86_64
Package avahi-glib-0.6.31-11.fc19.x86_64 des conflits sont installés avahi < ('0', '0.6.31', '11.fc19'): avahi-0.6.31-6.fc18.x86_64
Package avahi-gobject-0.6.31-6.fc18.x86_64 des conflits sont installés avahi > ('0', '0.6.31', '6.fc18'): avahi-0.6.31-11.fc19.x86_64
Package avahi-gobject-0.6.31-11.fc19.x86_64 des conflits sont installés avahi < ('0', '0.6.31', '11.fc19'): avahi-0.6.31-6.fc18.x86_64
Package avahi-libs-0.6.31-6.fc18.i686 des conflits sont installés avahi > ('0', '0.6.31', '6.fc18'): avahi-0.6.31-11.fc19.x86_64
Package avahi-libs-0.6.31-6.fc18.x86_64 des conflits sont installés avahi > ('0', '0.6.31', '6.fc18'): avahi-0.6.31-11.fc19.x86_64
Package avahi-libs-0.6.31-11.fc19.x86_64 des conflits sont installés avahi < ('0', '0.6.31', '11.fc19'): avahi-0.6.31-6.fc18.x86_64
Package avahi-ui-0.6.31-6.fc18.x86_64 des conflits sont installés avahi > ('0', '0.6.31', '6.fc18'): avahi-0.6.31-11.fc19.x86_64
Package avahi-ui-gtk3-0.6.31-6.fc18.x86_64 des conflits sont installés avahi > ('0', '0.6.31', '6.fc18'): avahi-0.6.31-11.fc19.x86_64
Package avahi-ui-gtk3-0.6.31-11.fc19.x86_64 des conflits sont installés avahi < ('0', '0.6.31', '11.fc19'): avahi-0.6.31-6.fc18.x86_64
Package dracut-029-2.fc19.x86_64 des conflits sont installés grubby < ('0', '8.23', None): grubby-8.22-1.fc18.x86_64
Package firefox-22.0-1.fc18.x86_64 des conflits sont installés xulrunner(x86-64) > ('0', '22.1', None): xulrunner-23.0-2.fc19.x86_64
Package gnome-desktop3-3.8.2-2.fc19.x86_64 des conflits sont installés gnome-shell < ('0', '3.7.90', None): gnome-shell-3.6.3.1-2.fc18.x86_64
Package mutter-3.8.4-1.fc19.x86_64 des conflits sont installés gnome-shell < ('0', '3.7.2', None): gnome-shell-3.6.3.1-2.fc18.x86_64
Package php-mysql-5.4.17-2.fc18.x86_64 des conflits sont installés php-mysqlnd: php-mysqlnd-5.5.1-1.fc19.x86_64
Package rubygems-2.0.5-100.fc19.noarch a des dépendances manquantes de rubygem(psych) >= ('0', '2.0.0', None)
Package spax-1.5.2-5.fc19.x86_64 des conflits sont installés pax < ('0', '3.4', '16'): pax-3.4-14.fc18.x86_64
Package sssd-ad-1.10.1-1.fc19.x86_64 des conflits sont installés sssd < ('0', '1.10.0', '8.beta2'): sssd-1.9.5-2.fc18.x86_64
Package sssd-common-1.10.1-1.fc19.x86_64 des conflits sont installés sssd < ('0', '1.10.0', '8.fc19.beta2'): sssd-1.9.5-2.fc18.x86_64
Package sssd-ipa-1.10.1-1.fc19.x86_64 des conflits sont installés sssd < ('0', '1.10.0', '8.beta2'): sssd-1.9.5-2.fc18.x86_64
Package sssd-krb5-1.10.1-1.fc19.x86_64 des conflits sont installés sssd < ('0', '1.10.0', '8.beta2'): sssd-1.9.5-2.fc18.x86_64
Package sssd-krb5-common-1.10.1-1.fc19.x86_64 des conflits sont installés sssd < ('0', '1.10.0', '8.beta2'): sssd-1.9.5-2.fc18.x86_64
Package sssd-ldap-1.10.1-1.fc19.x86_64 des conflits sont installés sssd < ('0', '1.10.0', '8.beta2'): sssd-1.9.5-2.fc18.x86_64
Package sssd-proxy-1.10.1-1.fc19.x86_64 des conflits sont installés sssd < ('0', '1.10.0', '8.beta2'): sssd-1.9.5-2.fc18.x86_64
Package systemd-204-9.fc19.x86_64 des conflits sont installés dracut < ('0', '027', None): dracut-024-25.git20130205.fc18.x86_64
Package util-linux-2.23.2-2.fc19.x86_64 des conflits sont installés coreutils < ('0', '8.20', None): coreutils-8.17-8.fc18.x86_64
Je comprends qu'il y a des problèmes, mais je ne sais pas comment les résoudre ...
Nicosss wrote: Sinon faudra essayer de virer tous ceux en fc18 avec une commande du genre 
#yum remove "*fc18*" --exclude=kernel\*
Est-ce qu'il ne vaudrait pas mieux virer les paquets F19 pour repartir sur une bonne base ?
Parce que j'ai l'impression qu'il aurait tendance à vouloir privilégier F18 ...

La situation est franchement critique : certains programmes ne se lancent plus (Digikam, pourquoi ?) et je n'ose pas redémarrer ! :-?
Heureusement, pas d'orage annoncé aujourd'hui, ni de vent => a priori, pas trop de risque de coupure de courant inopinée.

Quelqu'un pour me donner une petite piste pour sortir de cette impasse ?
Merci. 🙂
Bonjour,

Je ne sais pas si ça peut t'aider mais as-tu (re)essayer fedup avec un noyau inférieur ou égal à celui-ci (mon noyau de F19) ? 
$ uname -a
Linux localhost.localdomain 3.9.9-302.fc19.x86_64 #1 SMP Sat Jul 6 13:41:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
D'après ce que tu indiques plus haut, ton noyau F18 me semble supérieur.

Fedup n'apparaissait pas dans grub quand je faisais la mise à jour du système avec un noyau de F18 supérieur à 3.9.9-302xxx.
Did wrote:Bonjour,

Je ne sais pas si ça peut t'aider mais as-tu (re)essayer fedup avec un noyau inférieur ou égal à celui-ci (mon noyau de F19) ?
Bonjour,
Je ne sais pas s'il est possible de faire un fedup "en marche arrière", ni ce que ça risque de générer ; il me semble que, lorsqu'il a le choix, le système privilégie toujours la version la prlus récente.
Did wrote:
$ uname -a
Linux localhost.localdomain 3.9.9-302.fc19.x86_64 #1 SMP Sat Jul 6 13:41:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Chez moi, ça retourne ceci : 
$ uname -a
Linux toshiba4.mna 3.9.11-200.fc18.x86_64 #1 SMP Mon Jul 22 21:04:50 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Mais ça dit quoi exactement ? Que c'est F18 sur laquelle j'ai bootée ? ou que c'est la seule version susceptible d'être opérationnelle ?
Did wrote:D'après ce que tu indiques plus haut, ton noyau F18 me semble supérieur.
Que veux-tu dire au juste ?
Did wrote:Fedup n'apparaissait pas dans grub quand je faisais la mise à jour du système avec un noyau de F18 supérieur à 3.9.9-302xxx.
Dans Grub ? A quel endroit ? Je ne comprends pas ce que ça veut dire, ni ce qu'il faut en déduire.
tosca wrote: Est-ce qu'il ne vaudrait pas mieux virer les paquets F19 pour repartir sur une bonne base ?
Salut,

Ce qui est ennuyeux, c'est que justement tu ne disposais pas d'une bonne base avec ta Fedora 18, d'après tes propres déclarations. Un preupgrade ou un fedup ne peut aboutir que si la base est bonne.

Je suis ton sujet depuis le début, au stade où tu en es, et après les tentatives infructueuses de remettre de l'ordre, à moins qu'on ne te trouve une solution miracle, je ne vois d'autre issue que de récupérer tes fichiers persos importants, et de recommencer une installation propre de Fedora 19.
paradise wrote: Ce qui est ennuyeux, c'est que justement tu ne disposais pas d'une bonne base avec ta Fedora 18, d'après tes propres déclarations. Un preupgrade ou un fedup ne peut aboutir que si la base est bonne.
Il n'y a pas moyen de remettre en ordre un F18, ou même un F17 ?
paradise wrote: Je suis ton sujet depuis le début, au stade où tu en es, et après les tentatives infructueuses de remettre de l'ordre, à moins qu'on ne te trouve une solution miracle, je ne vois d'autre issue que de récupérer tes fichiers persos importants, et de recommencer une installation propre de Fedora 19.
Le problème n'est pas tant ce que j'ai dans /home pour lequel j'ai une sauvegarde ; mais tout ce qui est mis ailleurs, je ne sais où ... en particulier le paramétrage Apache, les bases MySQL, etc. Il y a sûrement plein de choses dont je n'ai pas connaissance, et que je risque de perdre sans pouvoir récupérer. 🙁
tosca wrote:
Nicosss wrote: Sinon faudra essayer de virer tous ceux en fc18 avec une commande du genre 
#yum remove "*fc18*" --exclude=kernel\*
Est-ce qu'il ne vaudrait pas mieux virer les paquets F19 pour repartir sur une bonne base ?
Parce que j'ai l'impression qu'il aurait tendance à vouloir privilégier F18 ...

La situation est franchement critique : certains programmes ne se lancent plus (Digikam, pourquoi ?) et je n'ose pas redémarrer ! :-?
Heureusement, pas d'orage annoncé aujourd'hui, ni de vent => a priori, pas trop de risque de coupure de courant inopinée.

Quelqu'un pour me donner une petite piste pour sortir de cette impasse ?
Merci. 🙂
Effectivement à ce niveau là et avec les réponses de tes posts précédents il vaut mieux tenter de retirer les paquets fc19. Par contre comme c'est précisé dans les posts après il va falloir sérieusement te pencher sur tes sauvegardes car si avant c'était déjà bancal là ce n'est pas parti pour s'améliorer.

Si yum ne veut pas retirer les paquets fc19, il faudra passer par rpm -e mais là c'est du violent... Après peut-être que quelqu'un aura une autre idée mais pour le moment avec les éléments actuels je ne vois que ça.
Nicosss wrote: Effectivement à ce niveau là et avec les réponses de tes posts précédents il vaut mieux tenter de retirer les paquets fc19.
En faisant ça ? 
#yum remove "*fc19*"
Nicosss wrote: Par contre comme c'est précisé dans les posts après il va falloir sérieusement te pencher sur tes sauvegardes car si avant c'était déjà bancal là ce n'est pas parti pour s'améliorer.

Si yum ne veut pas retirer les paquets fc19, il faudra passer par rpm -e mais là c'est du violent...
Au cas où, j'ai chargé un DVD F19 cette nuit ... mais ça fait un sacré bail que je n'ai pas fait d'installation "from scratch" ! :-?

Je n'ai d'ailleurs jamais utilisé de DVD ; est-ce qu'on boote dessus comme sur un Live-CD ?
Et puis le partitionnement semble avoir beaucoup changé (et pas en mieux !) depuis la dernière fois que je m'y suis frottée !

Reste le problème de tout ce qui n'est pas dans mon /home, et que je ne sais pas comment identifier/sauvegarder ... :-?