Grand merci ! Ce qui signifie aussi que je n’ai pas assez fouillé 🙁
Pour le nettoyage, j’ai procédé avec délicatesse.
Grand merci ! Ce qui signifie aussi que je n’ai pas assez fouillé 🙁
Pour le nettoyage, j’ai procédé avec délicatesse.
Bonjour à tous,
Avant de migrer mes machines physiques vers Fedora 41, j’ai testé la migration sur mes machines virtuelles. Dans l’ensemble tout s’est bien passé et ce n’est pas réellement le sujet ici.
Par contre, dans une machine virtuelle de test, j’avais installé Iridium Browser (par ajout du dépôt correspondant alors). Lors de la mise à niveau, Iridium a posé problème puisque le dépôt a totalement disparu et j’ai du le désinstaller. Pas grave. Par contre, j’ai constaté au niveau de la gestion des dépôts un changement de ligne de commande et l’impossibilité de supprimer les dépôts obsolètes.
Dans les faits, j’ai désactivé le dépôt Iridium pour constater un changement dans la ligne de commande.
D’autre part, si on peut désactiver les dépôts, impossible de supprimer entièrement et définitivement les dépôts obsolètes. Aucune commande ne le permet. Soit j’ai mal cherché, soit il y a un vide à combler. Sauf à tout réinstaller ce qui une solution un peu …. brutale. Et pourtant, si l’installtion initiale date de trop longtemps, on peut avoir des dépôts vraiment inutiles et polluants.
Merci à vous 😉
Je viens de créer une machine virtuelle entièrement neuve pour d’autres besoins (autre que SDDM) enme basant directement sur une image ISO Fedora 38 Plasma/KDE. La suite n’a pas raté au démarrage final : impossible de me connecter. Vu que sous machine virtuelle (VirtualBox), je ne parvenais pas à changer de TTY pour corriger immédiatement, j’ai opté pour la méthode bourrin en réinstallant la version Gnome après formatage.
Le problème persiste donc. (Mais je n’ai pas fait de rapport de bug …. !) Pas bien !😳
Effectivement ! J’aurais du y penser en toute logique, désactiver d’abord l’un pour pouvoir ensuite activer l’autre. Directement en clavier français, sous Wayland, 2 démarrages successifs réussis. Oui, 2 redémarrage pour vérifier que ce n’est pas un coup de chance. Donc un bug sur SDDM.
Grand merci !😄
Du nouveau :
J’ai tenté de changer le DM (SDDM remplacé par LightDM). Mais LightDM (déjà installé) tandis que SDDM est toujours actif alors que j’ai suivi les bonnes commandes données ci dessus.
D’autre part, j’ai brièvement pu me connecter sans difficultés après avoir annulé le renommage de mon dossier utilisateur ((mv /home/toto /home/toto-old) puis (mv /home/toto-old /home/toto)). Mais fausse joie, le problème est revenu au premier redémarrage. Je ne sais même pas quelle leçon tirer de cette courte expérience.
Quand je tente d’activer Lightdm, après la petite fenêtre me demandant le mot de passe, j’obtiens le message suivant : “Failed to enable unit: File /etc/systemd/system/display-manager.service already exists and is a symlink to /usr/lib/systemd/system/sddm.service”
Xorg ou Wayland : situation identique avec mon césame (correct) refusé systématiquement. Je précise que le système est à jour à la date d’aujourd’hui préalablement.
Grand merci Nicoss ! 😀
J’ai pu me connecter avec ta solution (connexion puis startx). Par contre, obligé de me connecter systématiquement ainsi (j’ai redémarré pour vérifier la situation) . Bug en attente de mise à jour ?
Bonjour,
La mise à niveau vers Fedora 38 s’est bien passée. J’ai pu démarré dessus sans problème 1 ou 2 fois. Mais dernièrement, impossible systématiquement !
Je corrige avant de mettre mon mot de passe la version du clavier (qui est bizarrement passée en US (et j’ai bien vu un message récent à ce sujet)) pour pouvoir saisir mon césame correctement. Sauf que c’est systématiquement refusé. Je suis sûr et certain de mes mots de passe. Mais dans le doute, j’ai testé vainement plusieurs combinaison dans le cas (improbable) où il y aurait eu un décalage de lettre. A noter que j’ai 2 sessions et que le problèmes est identique avec ces 2 cessions (“Echec de la connexion”).
A part tout réinstaller bêtement, que faire ? Merci par avance. 😉
Exact : je viens de réussir avec VMSVGA mais en désactivant l'accélération 3D. Avec cette accélération 3D, j'ai pu créer ma machine mais, après m'être connecté sous mon utilisateur lors du premiers redémarrage, impossible d'aller plus loin (écran noir).didierg wrote:Il semble (à confirmer) que ce soit le fait de définir une carte graphique VMSVGA sans activer l'accélération 3D qui cause le problème lors du premier démarrage.teutates wrote:Ma réponse ne va répond pas directement mais de tels problèmes sur une machine virtuelle indiquent probablement un mauvais paramétrage de la machine virtuelle puisque Fedora 34 "passe" très bien sous VBox.
Après avoir résolu ce (petit) problème Fedora 34 fonctionne très bien dans une machine VirtualBox.
sudo dnf install dnf-plugin-system-upgrade
sudo dnf upgrade && dnf clean all
sudo dnf system-upgrade download --releasever=33 --allowerasing
sudo dnf system-upgrade reboot
Problèmes majeurs :Merci !VINDICATORs wrote:Au passage, en plus de la réponse de nouvo09, j'ai eu le cas et un simple :A remis tout en ordre.sudo touch /.autorelabel && reboot
Il faut par contre savoir que le prochain boot est très long, donc pas de panique!
SELinux interdit à abrt-action-lis d'utiliser l'accès setattr sur le fichier rpmdb.sqlite-wal.
***** Le greffon catchall_labels (83.8 de confiance) suggère **************
Si vous souhaitez autoriser abrt-action-lis à accéder à setattr sur rpmdb.sqlite-wal file
Alors l'étiquette sur rpmdb.sqlite-wal doit être modifiée.
Faire
# semanage fcontext -a -t FILE_TYPE 'rpmdb.sqlite-wal'
où FILE_TYPE est l'une des valeurs suivantes : abrt_tmp_t, abrt_upload_watch_tmp_t, abrt_var_cache_t, abrt_var_log_t, abrt_var_run_t, kdump_crash_t, mail_home_rw_t, mock_var_lib_t, rhsmcertd_var_run_t, rpm_log_t, rpm_var_cache_t, rpm_var_run_t, usr_t.
Puis exécutez :
restorecon -v 'rpmdb.sqlite-wal'
***** Le greffon catchall (17.1 de confiance) suggère *********************
Si vous pensez que abrt-action-lis devrait être autorisé à accéder setattr sur rpmdb.sqlite-wal file par défaut.
Alors vous devriez rapporter ceci en tant qu'anomalie.
Vous pouvez générer un module de stratégie local pour autoriser cet accès.
Faire
autoriser cet accès pour le moment en exécutant :
# ausearch -c "abrt-action-lis" --raw | audit2allow -M my-abrtactionlis
# semodule -X 300 -i my-abrtactionlis.pp
Informations complémentaires :
Contexte source system_u:system_r:abrt_t:s0-s0:c0.c1023
Contexte cible system_u:object_r:var_lib_t:s0
Objets du contexte rpmdb.sqlite-wal [ file ]
Source abrt-action-lis
Chemin de la source abrt-action-lis
Port <Inconnu>
Hôte localhost.localdomain
Paquets RPM source
Paquets RPM cible
Stratégie RPM SELinux <Inconnu>
Stratégie locale RPM selinux-policy-targeted-3.14.6-29.fc33.noarch
Selinux activé True
Type de stratégie targeted
Mode strict Enforcing
Nom de l'hôte localhost.localdomain
Plateforme Linux localhost.localdomain 5.8.16-300.fc33.x86_64
#1 SMP Mon Oct 19 13:18:33 UTC 2020 x86_64 x86_64
Compteur d'alertes 126
Première alerte 2020-11-02 21:36:47 CET
Dernière alerte 2020-11-02 21:59:20 CET
ID local 0afb053b-7df4-4e2a-9a52-a37f2b42aa82
Messages d'audit bruts
type=AVC msg=audit(1604350760.575:436): avc: denied { setattr } for pid=2186 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="nvme0n1p3" ino=1967780 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
Hash: abrt-action-lis,abrt_t,var_lib_t,file,setattr
* Problème 2 :
SELinux interdit à abrt-action-lis d'utiliser l'accès write sur le fichier rpmdb.sqlite-wal.
***** Le greffon catchall_labels (83.8 de confiance) suggère **************
Si vous souhaitez autoriser abrt-action-lis à accéder à write sur rpmdb.sqlite-wal file
Alors l'étiquette sur rpmdb.sqlite-wal doit être modifiée.
Faire
# semanage fcontext -a -t FILE_TYPE 'rpmdb.sqlite-wal'
où FILE_TYPE est l'une des valeurs suivantes : abrt_etc_t, abrt_tmp_t, abrt_upload_watch_tmp_t, abrt_var_cache_t, abrt_var_log_t, abrt_var_run_t, afs_cache_t, initrc_tmp_t, kdump_crash_t, mail_home_rw_t, mock_var_lib_t, postfix_postdrop_t, puppet_tmp_t, rhsmcertd_var_run_t, rpm_log_t, rpm_var_cache_t, rpm_var_run_t, sysfs_t, user_cron_spool_t, user_tmp_t, usr_t.
Puis exécutez :
restorecon -v 'rpmdb.sqlite-wal'
***** Le greffon catchall (17.1 de confiance) suggère *********************
Si vous pensez que abrt-action-lis devrait être autorisé à accéder write sur rpmdb.sqlite-wal file par défaut.
Alors vous devriez rapporter ceci en tant qu'anomalie.
Vous pouvez générer un module de stratégie local pour autoriser cet accès.
Faire
autoriser cet accès pour le moment en exécutant :
# ausearch -c "abrt-action-lis" --raw | audit2allow -M my-abrtactionlis
# semodule -X 300 -i my-abrtactionlis.pp
Informations complémentaires :
Contexte source system_u:system_r:abrt_t:s0-s0:c0.c1023
Contexte cible system_u:object_r:var_lib_t:s0
Objets du contexte rpmdb.sqlite-wal [ file ]
Source abrt-action-lis
Chemin de la source abrt-action-lis
Port <Inconnu>
Hôte localhost.localdomain
Paquets RPM source
Paquets RPM cible
Stratégie RPM SELinux <Inconnu>
Stratégie locale RPM selinux-policy-targeted-3.14.6-29.fc33.noarch
Selinux activé True
Type de stratégie targeted
Mode strict Enforcing
Nom de l'hôte localhost.localdomain
Plateforme Linux localhost.localdomain 5.8.16-300.fc33.x86_64
#1 SMP Mon Oct 19 13:18:33 UTC 2020 x86_64 x86_64
Compteur d'alertes 154
Première alerte 2020-11-02 21:36:47 CET
Dernière alerte 2020-11-02 21:59:20 CET
ID local 819bbe21-42a0-4a5b-afea-beef16246b48
Messages d'audit bruts
type=AVC msg=audit(1604350760.624:493): avc: denied { write } for pid=2186 comm="abrt-action-lis" name="rpmdb.sqlite-wal" dev="nvme0n1p3" ino=1967780 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
Hash: abrt-action-lis,abrt_t,var_lib_t,file,write
Edit 2 :[fedora@localhost ~]$ semanage fcontext -a -t FILE_TYPE 'rpmdb.sqlite-wal'
ValueError: La stratégie SELinux n’est pas gérée ou la base n’est pas accessible.
[fedora@localhost ~]$ sudo semanage fcontext -a -t FILE_TYPE 'rpmdb.sqlite-wal'
[sudo] Mot de passe de fedora :
ValueError: Le type FILE_TYPE est invalide, il doit être un type de fichier ou de périphérique
[fedora@localhost ~]$
sudo dnf install dnf-plugin-system-upgrade
sudo dnf upgrade && dnf clean all
sudo dnf system-upgrade download --releasever=33 --allowerasing
sudo dnf system-upgrade reboot
Problèmes majeurs :