Bonjour à tous,

ma deuxième tentative d'upgrade est aussi foireuse que la 1ère 🙁

J'ai suivi la méthode en CLI avec dnf, et au rédémarrage Plymouth fini par disparaitre pour me laisser les dernières lignes de démarrage (qui ne contiennent rien de particulier), et c'est tout.

Je peux me logger à la 2ème console (ctrl+alt+f2), et voici ce que j'ai lorsque j'interroge le journal 
lightdm.service : main process exited, code=exited, status=1/FAILURE
voici la photo de mon écran :
journalctl -xe

si je fais un 
# systemctl start lightdm
j'ai le même retour

Une âme généreuse aurait-il une piste de solution ou un lien à suivre qui me sortirait de cette panade ?

Pour info :

spin : Mate-Compiz, 64 bits

Machine: System: Hewlett-Packard product: HP ProBook 650 G1
Mobo: Hewlett-Packard model: 1993 v: KBC Version 16.39
Bios: Hewlett-Packard v: L77 Ver. 01.22 date: 09/26/2014

CPU: Dual core Intel Core i5-4210M (-HT-MCP-) cache: 3072 KB
clock speeds: max: 3200 MHz 1: 2614 MHz 2: 2600 MHz 3: 2675 MHz 4: 2620 MHz

Graphics: Card: Intel 4th Gen Core Processor Integrated Graphics Controller
Display Server: Fedora X.org 118 drivers: intel (unloaded: fbdev,vesa)
Resolution: 1920x1080@60.38hz, 1680x1050@59.88hz, 1680x1050@59.88hz

Audio: Card-1 Intel 8 Series/C220 Series High Definition Audio Controller driver: snd_hda_intel
Card-2 Intel Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller driver: snd_hda_intel
merci pour la suggestion, hélas ça n'a rien changé.
Chose curieuse, quasiment toutes les lignes de démarrage sont doublées, parfois à la suite mais parfois intercalées 2 par 2.... ma bécane chercherait-elle à démarrer deux fois simultanément :roll:
je n'ai pas d'idée pour résoudre ton problème avec lightdm, ceci dit tu peux installer sddm (ou autre dm).
Impeccable, merci !

j'ai viré lightdm, installé sddm, fais un 
#systemctl start sddm
#systemctl enable sddm
et ça fonctionne 🙂

Bon, je préférais lightdm, mais pour l'instant ma machine tourne, ma VM win7 raw aussi, bref tu as fait un heureux !
Encore merci

Question : Est-ce que je passe le fil en résolu, bien que ça ne soit pas vraiment le cas ?
Bonjour:

Essayes de faire

# systemctl stop lightdm au cas où !!!
# systemctl disable lightdm comme cela au prochain redémarage il n'y aura pas de session graphique
# reboot
au login
$ su -
# journalctl -xn
# systemctl start lightdm
Et surtout vérifie bien que c'est la nouvelle version du fichier lightdm.conf qui est utilisée. Par défaut lorsque ce fichier existe déjà, le nouveau est installé en ligthdm.conf.rpmnew.

Je me suis fait avoir.
...and the winner is... nouvo09 !!! 8-)

@antbel : désolé, je n'ai pas testé ta solution, mais vu que c'est en renommant lightdm.conf en lightdm.conf.bak puis lightdm.conf.rpmnew en lightdm.conf que ça a fonctionné, je suppose que ça n'aurait pas changé grand-chose.

Merci à tous pour avoir pris le temps de me répondre, je passe le sujet en résolu 🙂

édit : il a fallu que je réactive numlockx dans lightdm.conf ; 
greeter-setup-script=/usr/bin/numlockx on
Dans la mesure où ça m'est arrivé sur une 2ème machine, j'ai bien envie de le signaler sur bugzilla, mais d'après vous, c'est un bug qui concerne lightdm, dnf ou mate ?
C'est clairement une modification de lightdm
Je ne vois pourquoi rapporter un bug du moment que tout a été fait selon les normes.
Tu te plains que le rpmnew n'a pas remplacé l'ancien fichier de configuration, cela peut être catastrophique dans certains cas. C'est à l'administrateur de faire un diff entre l'ancien et le pacnew et de faire les ajustements nécessaires.
@hechmi50
n'étant pas au fait des normes que tu évoques, j'ai perçu le souci différemment, en tant qu'utilisateur souhaitant juste obtenir une mise à jour de son système, dans un espoir "out of the box".
Certains paquets (très honnêtement je ne sais plus lequel m'y fait penser) préviennent qu'il y a un changement, et qu'il va falloir intervenir sur le différentiel.
Je m'imagine mal sur une mise à jour qui concerne 4190 paquets aller vérifier le diff à faire.
Donc avoir un message prévenant du fait à la fin de la mise à jour, demandant d'intervenir avant que la machine ne redémarre (ou finisse de démarrer) et semble planter ne me semble pas inutile.

Pour le dire autrement, je ne souhaite pas que tout se fasse systématiquement de manière automatique, c'est clairement une gageure qui me fait râler avec bien d'autres OS (du genre "on sait ce qui est mieux pour vous, pas besoin de votre avis"). Toutefois dans ce cas précis l'omission, l'absence d'automatisme, non accompagné d'un message clair mène à ce qui ressemble pour les non-spécialistes à un dysfonctionnement sévère, et c'est dommage.

Du coup merci pour ta remarque, j'ai commenté dans le sens de ma précision le ticket que j'ai ouvert sur bugzilla
Toutefois dans ce cas précis l'omission, l'absence d'automatisme, non accompagné d'un message clair mène à ce qui ressemble pour les non-spécialistes à un dysfonctionnement sévère, et c'est dommage.
La création de *.rpmnew est toujours signalée dans le terminal.
Pour ceux qui font les mises à jour mode graphique, ils pourront consulter les logs de dnf.

Pour l'automatisme que tu souhaites, je le répète ce n'est pas vraiment souhaitable et cela peut être dangereux.
Imagine une mise à jour de setup qui crée un /etc/passwd.rpmnew, si celui-ci écrasait automatiquement /etc/passwd comme tu le souhaites tu perdrais pas mal d'utilisateurs, tu ne pourras plus ouvrir ta session utilisateur.
D'un autre coté l'administrateur n'aura plus de repère pour ajouter les utilisateurs manquants.
Tu vois bien qu'il est logique de laisser /etc/passwd et de créer /etc/passwd.rpmnew à coté et de le signaler à l'administrateur pour qu'il gère le changement.
hecmi50 wrote:La création de *.rpmnew est toujours signalée dans le terminal.
sauf qu'après avoir lancé 
$ sudo dnf system-upgrade reboot
je ne suis plus dans un terminal, le peu qui est affiché est une ligne et une seule en haut à droite dans plymouth. Et ça a duré plus d'une heure... Tu imagines quelqu'un scrutant ce qui y est écrit pendant tout ce temps ?
hecmi50 wrote:Pour ceux qui font les mises à jour mode graphique, ils pourront consulter les logs de dnf.
sauf qu'en suivant la procédure telle que décrite dans les wiki, je me suis retrouvé sans possibilité de lancer une session graphique.
hecmi50 wrote:Pour l'automatisme que tu souhaites,
non, je ne le souhaite pas, relis-moi.

je dis juste que ce qui m'est arrivé (et pas qu'à moi) est dommage, et qu'il devrait y avoir un moyen plus clair de prévenir l'utilisateur qu'il lui faut intervenir sur lightdm.conf (dans ce cas précis) avant de pouvoir récupérer un système qui fonctionne pleinement. C'est à mon sens un défaut (d'ergonomie ?).
Je ne dis pas qu'il y a là une véritable panne, ou bug, je ne dénigre pas pas tout le travail que font les contributeurs à cette distribution, j'essaie juste de signaler qu'il y a là un cas de figure qui est franchement regrettable, et qu'une alerte bien affichée pourrait peut-être suffire à éviter.