• Actualités
  • Venez tester Fedora Linux 41 dès maintenant !

En ce mardi 17 septembre, la communauté du Projet Fedora sera ravie d’apprendre la disponibilité de la version Beta de Fedora Linux 41.

Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora Linux 41 et réduisant du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

La version finale est pour le moment fixée pour le 22 octobre ou 5 novembre.

Expérience utilisateur

  • Passage à GNOME 47 ;
  • L’environnement de bureau léger LXQt passe à la version 2.0 ;
  • L’éditeur d’image GIMP utilise la branche de développement qui deviendra la version 3 ;
  • Le gestionnaire de listes de tâches Taskwarrior évolue à la version 3 ;
  • La mise à jour du cœur des systèmes atomiques de bureau peut se faire sans droits administrateurs, mais pas les mises à niveau de celui-ci à savoir passer d’une version Fedora Linux Silverblue 40 à Fedora Linux Silverblue 41 ;
  • Mise à disposition des images Spin KDE Plasma Mobile et Fedora Kinoite Mobile ;
  • De même le gestionnaire de fenêtres Miracle exploitant Wayland est proposé dans Fedora et bénéficie de son propre Spin ;
  • L’installation de Fedora Workstation se fera avec le protocole d’affichage Wayland uniquement, X11 reste disponible et installable après.

Gestion du matériel

  • L’installation du pilote propriétaire de Nvidia via GNOME Logiciels est compatible avec les systèmes utilisant l’option Secure Boot ;
  • Prise en charge des caméras MIPI pour les systèmes utilisant Intel IPU6 qui concerne de nombreux ordinateurs portables actuels ;
  • L’installateur Anaconda prend en charge le chiffrement matériel des disques via le standard TCG OPAL2, mais cela nécessite de passer via un fichier kickstart pour personnaliser l’installation ;
  • Utilisation par défaut de l’outil tuned au lieu de power-profiles-daemon pour la gestion de l’énergie de la machine ;
  • Mise à jour de ROCm 6.2 pour améliorer la prise en charge de l’IA et le calcul haute performance pour les cartes graphiques ou accélérateurs d’AMD ;
  • L’outil de débogue des tables ACPI nommé acpica-tools ne prend plus en charge les architectures gros boutistes tels que s390x ;
  • PHP ne prend plus en charge les processeurs x86 32 bits.

Internationalisation

  • Le gestionnaire d’entrées IBus par défaut pour la langue traditionnelle chinoise de Taiwan passe de ibus-libzhuyin à ibus-chewing.

Administration système

  • Le gestionnaire de paquet dnf est mis à jour vers sa 5e version ;
  • Tandis que la commande rpm utilise la version 4.20 ;
  • Les systèmes Fedora atomiques de bureau et Fedora IoT disposent de bootupd pour la mise à jour du chargeur de démarrage ;
  • Les images atomiques de Fedora proposent les outils dnf et bootc, ce premier est utilisable dans un contexte de développement pour l’instant mais le second peut commencer à servir à déployer des images du système qui sont bootables ;
  • La bibliothèque de sécurité OpenSSL n’accepte plus les signatures cryptographiques avec l’algorithme SHA-1 ;
  • Stabilisation de la fonctionnalité de Fedora Linux 36 où ostree prenait en charge les formats OCI/Docker pour le transport et le mécanisme de déploiement des conteneurs ;
  • Le gestionnaire de réseaux NetworkManager ne prend plus en charge la configuration dans le format ifcfg qui était déjà désuet depuis des années ;
  • Dans la même veine, le paquet network-scripts a été retiré, mettant fin à la gestion du réseau via les scripts ifup et ifdown ;
  • Les interfaces réseaux pour les éditions Cloud vont utiliser les nouveaux noms par défaut comme adoptés par les autres éditions il y a des années au lieu de conserver les noms traditionnels tels que eth0 ;
  • Le gestionnaire de virtualisation libvirt utilise maintenant par défaut le pare-feu nftables au lieu de iptables pour son interface réseau vibr0 ;
  • L’outil Netavark pour gérer la pile réseau des conteneurs, notamment avec podman, utilise également par défaut le pare-feu nftables au lieu de iptables ;
  • Les unités système de systemd vont utiliser par défaut beaucoup d’options pour améliorer la sécurité des services ;
  • Introduction de l’outil fedora-repoquery pour faire des requêtes sur les dépôts comme savoir la version exacte d’un paquet spécifique dans une autre version de Fedora, la date de mise à jour d’un dépôt, ou connaître les paquets qui dépendent d’un paquet spécifique (dépendance inverse donc), etc. ;
  • Le gestionnaire de conteneurs Kubernetes a des nouveaux paquets versionnés, permettant d’avoir plusieurs versions en parallèle. Ici les versions 1.29, 1.30 et 1.31 sont proposées avec des noms comme kubernetes1.31 ;
  • L’implémentation des interfaces de Kubernetes fait par l’OCI a ses propres paquets cri-o et cri-tools qui sont également versionnés pour pouvoir suivre les versions de Kubernetes.

Développement

  • Mise à jour de la suite de compilation GNU : binutils 2.42, glibc 2.40 et gdb 15 ;
  • Mise à niveau de la suite de compilateurs LLVM vers la version 19 ;
  • Retrait de Python 2.7 dans les dépôts, seule la branche 3 est maintenue dorénavant ;
  • D’ailleurs Python bénéficie de la version 3.13 ;
  • Python est aussi compilé avec l’optimisation -O3 activée, en ligne avec la manière de faire par le projet officiel et améliorant les performances ;
  • Le framework d’écriture de tests en Python, Pytest se teste avec sa version 8 ;
  • Mise à jour du langage Go vers la version 1.23 ;
  • Mise à jour dans l’écosystème Haskell GHC 9.6 et Stackage LTS 22 ;
  • Le langage Perl passe à la version 5.40 ;
  • Node.js 22 devient la version de référence, tandis que la version 20 et 18 restent disponibles en parallèle ;
  • Pour des raisons de changement de licence, le gestionnaire de bases de données clé-valeur Redis est remplacé par Valkey ;
  • La bibliothèque Python d’apprentissage profond Pytorch est éclairée avec sa version 2.4 ;
  • L’API engine de la bibliothèque OpenSSL est désactivée car non maintenue tout en gardant une ABI stable.

Projet Fedora

  • L’édition de Fedora KDE pour l’architecture AArch64 est maintenant bloquante pour les sorties d’une nouvelle version. L’édition doit être suffisamment stable pour qu’une nouvelle version de Fedora Linux voit le jour ;
  • Ultime phase 4 de l’usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora ;
  • Les bibliothèques Java n’ont plus une dépendance explicite envers le runtime de Java pour simplifier la maintenance, rien ne change concernant les applications ;
  • Le paquet systemtap-sdt-devel n’a plus l’outil dtrace qui a été mis dans le paquet systemtap-sdt-dtrace ;
  • Ajout d’une tâche de nettoyage lors de la génération des paquets RPM pour améliorer la reproductibilité des paquets ;
  • Changement dans les métadonnées des dépôts de Fedora, avec l’usage de l’algorithme de compression zstd et l’abandon des bases de données sqlite pour diminuer la taille des données à télécharger ou à stocker.

Tester

Durant le développement d’une nouvelle version de Fedora Linux, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est de tester pendant une journée une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, l’internationalisation, etc. L’équipe d’assurance qualité élabore et propose une série de tests en général simples à exécuter. Suffit de les suivre et indiquer si le résultat est celui attendu. Dans le cas contraire, un rapport de bogue devra être ouvert pour permettre l’élaboration d’un correctif.

C’est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une Beta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. J’annonce régulièrement sur mon blog quand une journée de tests est planifiée.

Si l’aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

Si vous avez déjà Fedora Linux 40 ou 39 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

En cas de bogue, n’oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate. N’oubliez pas de consulter les bogues déjà connus pour Fedora 41.

Bons tests à tous !

Je vais me tester cela.

Ce sera l’occasion de préparer des machines virtuels en F41 pour les démos du capitole du libre 😛.

Je viens d’essayer avec la version server. Ça m’a saoûlé elle démarre pas, j’ai tout viré. On verra.

    nouvo09

    En test physique pas de souci, en test virtuel non plus de mon coté.

    Je test les autres éditions en VM.

    Je viens de mettre à niveau ma workstation vers Fedora 41 Beta pas de soucis 👍 . Nb j’ai une installation toute simple je rencontre des problèmes normalement en faisant une mise à jour totale avec les codec vidéo Microsoft.

    Là pas de soucis pour un fonctionnement basique avec la mise à jour par dnf .

    sudo dnf upgrade --refresh

    sudo dnf system-upgrade download --releasever=41

    Voir le lien suivant : https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/#sect-performing-system-upgrade .

    Merci à vous tous

    Didier

      nouvo09

      J’ai réussi à installer, j’avais mal fait la première fois. Mais les groupes ne sont pas prêts, impossible d’installer x11, et les dm.

        VINDICATORs Merci, pour le lien de la doc dnf upgrade c’est sympathique 👍 😉

        Installé à l’instant sur une de mes deux machines physiques (upgrade par dnf depuis F40) et tout ce que j’ai contrôlé fonctionne. Il n’y a plus qu’à attendre les prochains tests days.

        winmandrake

        Je n’ai pas dit que j’avais installé la version Workstation, relis.

        6 jours plus tard

        PC principal migré, reste quelques soucis avec dnf5 et des dépendances, mais cela semble stable pour le moment. Par contre j’avais un petit souci avec une des prises RJ45 de mon réseau qui faisait que la connexion ne dépassé pas les 100Mb/s … Une fois rebranché retour au 1Gb/s, ce qui est plus rapide pour les mises à jours (300Mb/s en téléchargement de moyenne au lieu de 25Mb/s…)

        A voir si il n’y a pas d’autres problèmes d’utilisation par la suite.

        Installé sur une VM, migration de 40 à 41.

        Le seul problème repéré : pas d’affichage au premier démarrage.

        Après reboot forcé : tout va bien.

        Pour l’instant je n’ai pas repéré de choses qui ne fonctionneraient pas.

          tof57

          Si pilote NVIDIA, il faut parfois attendre un peu car le module noyau se construit.

          Bon 2 petites choses à dire après “upgrade”, les paquets sont notés comme “unknow” et j’ai un souci avec le ssh et mes VM sur le même hôte rapporté sur le bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=2316063

          Édit : Bon cela provient du client ipa (Manager d’identité). Sans doute qu’il y a une sécurité ajouté dans ce cas là. Pourtant aucun problème sur les hyperviseurs KVM sous F40…

          Me reste aussi un souci d’affichage avec CURA (pour l’impression 3D), que j’utilise car il reconnait directement mon imprimante 3D sur usb. Mais c’est déjà le cas depuis F40. Par contre la version flatpack 5.8 n’avait plus ce problème… A voir si c’est Mesa qui fait des siennes… Bon faut juste attendre longtemps…

          Édit :

          Bon mon bogue est en fait une option décoché dans /etc/ssh/ssh_config.d/04-ipa.conf.

          #KnownHostsCommand /usr/bin/sss_ssh_knownhosts %H

          En remettant le # cela refonctionne. Je fais le tour de mes autres clients, car je n’ai pas souvenir d’y avoir touché…

          Marrant sur les autres clients voici ce que j’ai :

          # IPA-related configuration changes to ssh_config
          #
          PubkeyAuthentication yes
          GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts
          #VerifyHostKeyDNS yes
          
          # assumes that if a user does not have shell (/sbin/nologin),
          # this will return nonzero exit code and proxy command will be ignored
          Match exec true   
                  ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

          Mais pas trace de KnownHostsCommand

          Actuellement :

          # IPA-related configuration changes to ssh_config
          #
          PubkeyAuthentication yes
          #GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts
          #VerifyHostKeyDNS yes
          
          # use sss_ssh_knownhosts if available
          # assumes that if a user does not have shell (/sbin/nologin),
          # this will return nonzero exit code and proxy command will be ignored
          Match exec true
          #KnownHostsCommand /usr/bin/sss_ssh_knownhosts %H
          
          # assumes that if a user does not have shell (/sbin/nologin),
          # this will return nonzero exit code and proxy command will be ignored
          #Match exec true
          #       ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h
          ~                                                                

          Sans doute une manière de travailler différentes, donc à suivre sur un autre sujet peut être?

          un mois plus tard

          couocu!

          j’ai déjà un fedora 41 vm car il vraiment rapide 🙂