T
teutates

  • il y a 12 jours
  • Inscrit 10 mai 2006
  • 0 meilleure réponse
  • Petit nouveau Adepte du forum Rédacteur potentiel
  • 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.

    1. Ainsi, sous Fedora 40 (et précédentes), c’était la ligne de commande suivante pour désactiver : <sudo dnf config-manager –set-disabled depot >
    2. Désormais sous Fedora 41, sous réserve que ce soit temporaire, c’est la ligne de commande (pour désactiver) :<sudo dnf config-manager setopt depot.set=0 > puisque la solution avec config-manager ne fonctionne plus
    3. A noter que ce sera pour activer ce même dépôt : <sudo dnf config-manager setopt depot.set=1 >
    4. A noter aussi que la commande <sudo dnf repolist all > ne fonctionne plus.

    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 😉

    • Nicosss a répondu à ça.
    • teutates En effet, le passage à Fedora Linux 41 a aussi entrainé le passage à DNF5 qui a quelques subtilités d’utilisation -> Voir https://dnf5.readthedocs.io/en/latest/ .

      Pour ton point 4, la commande est désormais
      $ dnf repo list --all

      Concernant plus précisément le cas que tu abordes les détails sont expliqués au lien https://dnf5.readthedocs.io/en/latest/dnf5_plugins/config-manager.8.html .
      En effet, à ce jour tu ne peux pas supprimer un dépôt installé mais seulement l’activer ou désactiver.

      Si tu souhaites retirer définitivement certains dépôts alors il faudra les supprimer manuellement dans /etc/yum.repos.d/ .

    • fgland

      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 !😳

    • fgland

      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 !😄

    • fgland

      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. 😉

        • Nicosss a répondu à ça.
        • teutates il faut désactiver sddm avant d’activer lightdm

          # systemctl disable sddm

          # systemctl enable lightdm

        • Configuration :
          PC monté sur mesure (datant de 2012) :
          * Intel Core i7 2700k
          * Carte graphique Gainward GeForce GTX560 2Go
          * RAM GSkill 2x4Go PC12800
          * Velociraptor
          * Plasma

          Méthode d'installation :
          Mise à jour via la méthode officielle (avec "dnf system upgrade")

          Problèmes majeurs :
          Aucun

          Problèmes mineurs :
          Suite à des sautes d'écran que je ne parvenais jamais à solutionner (dès le lancement de Google Chrome stable), j'avais bloqué les mises à jours du noyau sous Fedora 35 (sans que cela soltionne réellement de fait). Après passage sur Fedora 36, ne voyant toujours pas de noyau F36, je me suis souvenu de mon blocage. J'ai finalement annulé ce bocage de mise à jour pour voir enfin un noyau F36.

          Points positifs :
          La mise à jour s'est effectuée sans problème, très simplement et rapidement.
          Après la mise à niveau, je ne constate plus ces sautes d'écrans. Enfin !

          Points négatifs :

          Aucun

          Grand merci à tout le monde pour ce magnifique travail 8-) 😉
        • Configuration
          PC portable MSI GF75 :
          * Intel Core i7-10750H
          * GeForce GTX 1650 4Go
          * RAM 32Go
          * SSD + NVME
          * Plasma

          Méthode d'installation :
          Mise à jour via la méthode officielle (avec "dnf system upgrade")

          Problèmes majeurs :
          Aucun

          Problèmes mineurs :
          Aucun

          Points positifs :
          La mise à jour s'est effectuée sans problème, très simplement et rapidement.

          Points négatifs :
          Aucun
        • didierg wrote:
          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.
          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.

          Après avoir résolu ce (petit) problème Fedora 34 fonctionne très bien dans une machine VirtualBox.
          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).
        • Bonjour,

          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.
        • Mise à niveau de 2 PC :

          1 - Configuration succincte PC tour :
          Asus P8Z68-V/GEN3
          Intel Core i2700k
          RAM G-Skill 4x4Go PC 12800
          Gainward Geforce GTX 560 - 2 Go
          SSD Samsung 64 Go - Sata 3

          1.1 - Méthode d'installation :
          dnf system-upgrade
          Réseau fibre / cable Ethernet

          1.2 - Problèmes majeurs :
          Aucun

          1.3 - Problèmes mineurs :
          Impossible de démarrer sur Plasma Wayland : perte clavier et souris après connexion session

          1.4 - Points positifs :
          Démarrage possible sur Plasma X11
          Profil Plasma recréé sous F33 directement fonctionnel sous F34
          Tout le reste fonctionne
          Mise à niveau très rapide

          1.5 - Points négatifs :
          Aucun

          2 - Configuration succincte PC portable MSI GF75 Thin 10SCXR-020FR :
          Intel Core i7-10750H
          RAM Ripjaws Series 32 Go (2 x 16 Go) PC4-21300 / DDR4 2666 Mhz
          Gainward Geforce GTX 1650 4 Go
          SSD Samsung 970 EVO PLUS 500 Go M.2 NVMe PCIe 3 x4

          2.1 - Méthode d'installation :
          dnf system-upgrade
          Réseau fibre / WiFi

          2.2 - Problèmes majeurs :
          Aucun

          2.3 - Problèmes mineurs :
          Aucun

          2.4 - Points positifs :
          Démarrage possible sur Plasma Wayland
          Profil Plasma créé sous F33 directement fonctionnel sous F34
          Tout le reste fonctionne
          Mise à niveau très rapide

          2.5 - Points négatifs :
          Aucun

          Grand merci :-D
        • Bonjour,

          Il existe aussi la solution de faire une installation la plus basique possible d'un Windows virtualisé pour travailler ensuite sur des copies jetables. Évidemment, cela suppose de mettre à jour régulièrement la version basique source et ce sera selon les besoins d'utilisations. Cela peut convenir pour faire des tests mais pas dans le cas où certaines applications seraient utilisées régulièrement en production.
        • Configuration :
          PC fixe monté par moi même :
          * CPU Intel i72700k
          * Gainward Geforce GTX 560 2 Go
          * 16Go DDR4
          * SSD 500 Go Sata 3

          Méthode d'installation :

          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 :
          Aucun

          Problèmes mineurs :
          Aucun

          Points positifs :
          Jamais vu une telle rapidité de mise à niveau !

          Points négatifs :
          Jamais vu une telle rapidité de mise à niveau ! Même plus besoin de devoir dépanner :lol:
        • VINDICATORs wrote:Au passage, en plus de la réponse de nouvo09, j'ai eu le cas et un simple :
          sudo touch /.autorelabel && reboot
          A remis tout en ordre.

          Il faut par contre savoir que le prochain boot est très long, donc pas de panique!
          Merci !
          C'était la solution. Je confirme la longueur du redémarrage.
          Problème résolu 8-)
        • Bonjour,

          Suite à la mise à niveau (réussie) de Fedora 32 vers 33, SELinux est devenu pénible avec ses alertes repétées. J'ai bien coché pour ne plus recevoir les alertes. J'ai même redémarré mais ces alertes sont insistantes. Certains diront que ce n'est pas réeelement un problème mais j'aimerais bien ne plus voir ces messages toutes les secondes. Une recherche porte sur des dates trop lointaines. Une idée ?

          Merci par avance 😉

          Edit :
          Cela semble concerner 2 problèmes dont voici les détails :
          *Problème n1 :
          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 :
          Si je suis les consignes : échec :
          [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 ~]$ 
          
        • Bonjour !

          Configuration :
          PC portable MSI GF75 :
          * Intel Core i7-10750H
          * GeForce GTX 1650 4 Go GDDR6
          * 32Go DDR4 (j'ai doublé immédiatement)
          * SSD Samsung 970 Evo Plus 500Go NMVE

          Méthode d'installation :
          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 :
          Aucun

          Problèmes mineurs :
          Aucun

          Points positifs :
          Jamais vu une telle rapidité de mise à niveau ! Même en Wifi !!

          Points négatifs :
          Jamais vu une telle rapidité de mise à niveau ! Même en Wifi !! Même plus besoin de devoir dépanner :lol:

          Prochaine étape :
          Le PC "vieux" portable Asus étant déjà sous Fedora 33) : migrer la tour très prochainement.