Vous en avez assez que sddm (écran de connexion graphique pour kde) ressemble à ceci:
Vous préférez plutôt y voir figurer les images (ou les avatars) des utilisateurs.
Cela nécessite une action de chaque utilisateur.
Pour kubuntu, pas de problèmes: il suffit de procéder via Configuration du système -> Détails du compte-> Gestionnaire des utilisateurs.
Pour Fedora kde (ou d'autres distributions), rien n'est prévu à ce niveau.
Mais on peut agir dans un émulateur de terminal, avec la commande kcmshell114.
Pour l’utilisateur toto:
toto@rigel:~$ kcmshell4 kcm_useraccount
jeudi 4 août 2016
mercredi 3 août 2016
Mise à niveau vers Fedora 24
J'ai hésité longtemps avant d'écrire cet article puisque tout était déjà dit dans cet article concernant le passage à Fedora 23. Je rappelle donc les commandes qu'il convient d'exécuter (en tant que root):
[root@rigel ~]# dnf update --refresh
pour mettre à jour le système existant
[root@rigel ~]# dnf install dnf-plugin-system-upgrade
pour installer le programme qui convient
[root@rigel ~]# dnf system-upgrade download --releasever=24
pour télécharger les paquets de la nouvelle version
[root@rigel ~]# dnf system-upgrade reboot
pour procéder à la mise à niveau proprement dite.
Toutefois si l'étape 3 se termine par une erreur du genre:
Erreur : Erreur du contrôle de transaction
le fichier /usr/bin de l'installation de google-earth-stable-7.1.4.1529-0.x86_64 entre en conflit avec le fichier du paquet filesystem-3.2-37.fc24.x86_64
(ceci suppose que la variable d'environnement PGDATA existe et contient /var/lib/pgsql/data)
[root@rigel ~]# dnf update --refresh
pour mettre à jour le système existant
[root@rigel ~]# dnf install dnf-plugin-system-upgrade
pour installer le programme qui convient
[root@rigel ~]# dnf system-upgrade download --releasever=24
pour télécharger les paquets de la nouvelle version
[root@rigel ~]# dnf system-upgrade reboot
pour procéder à la mise à niveau proprement dite.
Toutefois si l'étape 3 se termine par une erreur du genre:
Erreur : Erreur du contrôle de transaction
le fichier /usr/bin de l'installation de google-earth-stable-7.1.4.1529-0.x86_64 entre en conflit avec le fichier du paquet filesystem-3.2-37.fc24.x86_64
cela signifie qu'un dépôt actif fournit un paquet non installable (google-earth-stable-7.1.4.1529-0.x86_64 dans notre exemple).
Il n'est pas trop tard pour supprimer ce dépôt.
Par exemple:
[root@rigel ~]# rm /etc/yum.repos.d/google-earth.repo
L'étape 3 relancée se termine alors rapidement sans aucune erreur (tous les téléchargements ont déjà été effectués).
Toutefois la dernière étape malgré un début prometteur se plante sans aucun message d'erreur.
En fait le paquet litigieux est toujours dans le cache.
il faut le supprimer avant de poursuivre:
[root@rigel ~]# rm /var/lib/dnf/system-upgrade/google-earth-stable-6.0.3.2197-0.x86_64.rpm
En ce qui concerne la migration des données postgresql, j'ai déjà tout expliqué ici.
Toutefois j'ajouterai qu'il convient en tant que postgres de se placer là où postgres peut écrire (ou sinon le programme pg_upgrade se plante).
La séquence est donc:
[toto@rigel ~]$ su -
Mot de passe :
[root@rigel ~]# su - postgres
Mot de passe :
[root@rigel ~]# su - postgres
bash-4.3$ cd /var/lib/pgsql
bash-4.3$ mv data data_9.4
Ensuite:
[root@rigel ~]# postgresql-setup initdb
Puis:
bash-4.3$ pg_upgrade -b /usr/lib64/pgsql/postgresql-9.4/bin/ -B /usr/bin/ -d data_9.4/ -D data
(ceci suppose que la variable d'environnement PGDATA existe et contient /var/lib/pgsql/data)
Je récupère ensuite l'ancien pg_hba.conf
bash-4.3$ cp /var/lib/pgsql/data_9.4/pg_hba.conf /var/lib/pgsql/data/
En effet si je le récupère d'abord comme indiqué dans l'article précédent et qu'il contient des éléments empêchant le démarrage du nouveau serveur, pg_upgrade va se planter.
L'erreur fatale dont il est question précédemment ne se produit plus.
Ne pas oublier de récupérer pg_ident.conf et d'adapter postgresql.conf
Inscription à :
Articles (Atom)