Passer au contenu
openSUSE Leap 15.3

Notes de version

openSUSE Leap est un système d'exploitation libre et basé sur Linux pour votre ordinateur personnel, votre ordinateur portable ou votre serveur. Vous pouvez surfer sur le web, gérer vos e-mails et vos photos, faire du travail bureautique, lire des vidéos ou de la musique, et vous amuser !

Contributeurs: Guillaume GARDET, Antoine BELVIRE, et Sylvain TOSTAIN
Date de publication : 2022-12-31, Version : 15.3.20221231.096cd3b

Les notes de version sont en développement permanent. Pour avoir les dernières mises à jour, consultez la version en ligne sur https://doc.opensuse.org/release-notes. Les notes de version en anglais sont mises à jour dès que le besoin s'en fait sentir. Les versions traduites peuvent être temporairement incomplètes.

Si vous mettez à niveau une ancienne installation vers cette version d'openSUSE Leap, consultez les précédentes notes de version listées ici :https://en.opensuse.org/openSUSE:Release_Notes.

Des informations sur le projet sont disponibles à l'adresse https://www.opensuse.org.

Pour rapporter des bugs relatifs à cette version, veuillez utiliser le Bugzilla d'openSUSE. Pour plus d'informations, consultez https://en.opensuse.org/Submitting_Bug_Reports.

Les principales nouvelles fonctionnalités d'openSUSE Leap 15.3 sont aussi listées sur https://en.opensuse.org/Features_15.3.

1 Installation

Cette section contient des notes à propos de l'installation. Pour des instructions détaillées sur l'installation, veuillez consulter la documentation sur https://doc.opensuse.org/documentation/leap/startup/html/book-startup/part-basics.html.

1.1 openSUSE Leap a maintenant trois dépôts de mise à jour

La configuration de la maintenance d'openSUSE Leap 15.3 consiste en trois dépôts principaux de mise à jour. Ce sont : repo-update, repo-backports-update, et repo-sle-update. Les deux derniers sont nouveaux et résultent de la réutilisation de binaires de SUSE Linux Enterprise. Ces dépôts sont disponibles et vérifiés pendant l'installation en ligne d'openSUSE Leap. Nous vous recommandons de les utiliser. Les nouvelles définitions de dépôt de mise à jour pour openSUSE Leap 15.3 seront en outre fournies via une mise à jour de maintenance 0day du paquet openSUSE-release. La mise à jour sera livrée via le traditionnel canal de maintenance repo-update. Elle portera un drapeau spécial de mise à jour qui signifie qu'elle touche la zone de gestion des logiciels qui est alors spécialement traitée par zypper. Vous devriez revérifier à l'aide de la commande zypper up si toutes les mises à jour ont été traitées. Pour plus d'informations, voir https://bugzilla.opensuse.org/show_bug.cgi?id=1186593.

Le dépôt repo-update est destiné aux mises à jour d'openSUSE Leap (OSS). C'est le plus petit et il contient les paquets de configuration du système, y compris le paquet de version, la marque et les forks potentiels des paquets SUSE Linux Enterprise. Ce dépôt possède également une déclinaison debug-info.

Le dépôt repo-backports-update est un dépôt de mise à jour pour openSUSE Backports qui contient des mises à jour pour la majorité des paquets openSUSE Leap. Ce dépôt a également une déclinaison debug-info.

Le troisième dépôt, nommé repo-sle-update, est un dépôt de mise à jour qui contient les mises à jour combinées de tous les flux actifs de mise à jour de SUSE Linux Enterprise. Ce dépôt est dépourvu de la déclinaison debug-info.

1.2 Utiliser les mises à jour atomiques avec le rôle système serveur transactionnel

L'installateur propose le rôle système serveur transactionnel. Ce rôle système inclut un système de mise à jour qui est capable d'appliquer les mises à jour de manière atomique (en une seule opération) et qui permet de facilement les annuler si cela devient nécessaire. Ces fonctionnalités sont basées sur les outils de gestion de paquets sur lesquels les autres distributions openSUSE et SUSE reposent. Cela signifie que la vaste majorité des paquets RPM qui fonctionnent avec d'autres rôles système d'openSUSE Leap 15.3 fonctionnent aussi avec le nouveau rôle serveur transactionnel.

Remarque
Remarque : Paquets incompatibles

Certains paquets modifient le contenu de /var ou de /srv dans leurs scripts RPM %post. Ces paquets sont incompatibles. Si vous trouvez un tel paquet, merci de remplir un rapport de bug.

Afin de fournir ces fonctionnalités, le système de mise à jour repose sur :

  • les instantanés Btrfs.  Avant que la mise à jour du système démarre, un nouvel instantané Btrfs du système de fichiers racine est créé. Ensuite, tous les changements de la mise à jour sont installés sur cet instantané. Pour compléter la mise à jour, il suffit de redémarrer le système sur le nouvel instantané.

    Pour annuler cette mise à jour, démarrer simplement sur le précédent instantané.

  • Un système fichier racine en lecture seule.  Pour éviter les problèmes et la perte de données à cause des mises à jour, le système de fichiers racine ne doit pas être écrit autrement. Par conséquent, le système de fichiers racine est monté en lecture seule pendant le fonctionnement normal.

    Afin que cette configuration fonctionne, deux changements supplémentaires au niveau du système de fichiers ont été nécessaires : afin de pouvoir écrire la configuration utilisateur dans /etc, ce répertoire est automatiquement configuré pour utiliser OverlayFS ; /var est maintenant un sous-volume séparé qui peut être écrit par les programmes.

Important
Important : Un serveur transactionnel a besoin d'au moins 12 Go d'espace disque

Le rôle serveur transactionnel a besoin d'au moins 12 Go d'espace disque afin d'accueillir les instantanés Btrfs.

Important
Important : YaST ne fonctionne pas en mode transactionnel

Actuellement, YaST ne fonctionne pas avec les mises à jour transactionnelles. Ceci est dû au fait que YaST effectue les choses immédiatement et qu'il ne peut pas modifier un système de fichiers en lecture seule.

Pour travailler avec les mises à jour transactionnelles, veuillez toujours utiliser la commande transactional-update au lieu de YaST et Zypper pour toute la gestion des logiciels :

  • Mettre à jour le système :transactional-update up

  • Installer un paquet : transactional-update pkg in NOM_DU_PAQUET

  • Supprimer un paquet : transactional-update pkg rm NOM_DU_PAQUET

  • Pour annuler le dernier instantané, c'est-à-dire les derniers changements effectués sur le système de fichiers, assurez-vous que votre système est démarré sur l'avant-dernier instantané et lancez : transactional-update rollback

    En option, ajoutez un ID d'instantané à la fin de la commande pour revenir à un ID spécifique.

Avec ce rôle, par défaut le système effectuera une mise à jour quotidienne et un redémarrage entre 3 h 30 et 5 h 00 du matin. Ces deux actions sont basées sur systemd et peuvent être désactivées si nécessaire en utilisant systemctl :

systemctl disable --now transactional-update.timer rebootmgr.service

Pour plus d'informations sur les mises à jour transactionnelles, voir les posts du blog d'openSUSE Kubic https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ et https://kubic.opensuse.org/blog/2018-04-20-transactionalupdates2/.

1.3 Installation sur des disques dur avec moins de 12 Go de capacité

L'installateur proposera un schéma de partitionnement seulement si l'espace disponible sur le disque dur est plus grand que 12 Go. Si vous voulez installer, par exemple, de très petites images de machines virtuelles, utilisez le partitionneur guidé pour régler manuellement les paramètres de partitionnement.

1.4 UEFI — Unified Extensible Firmware Interface

Avant d'installer openSUSE sur un système qui démarre au moyen d'UEFI (Unified Extensible Firmware Interface) il est fortement recommandé de vérifier l'existence de mises à jour du microprogramme (firmware) recommandées par le fournisseur du matériel et, le cas échéant, d'installer de telles mises à jour. Une installation préexistante de Windows 8 ou supérieur constitue une indication forte comme quoi votre système démarre au moyen d'UEFI.

Contexte : Certains microprogrammes (firmwares) UEFI présentent des bogues conduisant à leur défaillance si un volume de données trop important est écrit dans la zone de stockage de l'UEFI. Néanmoins, personne ne sait vraiment où se trouve la limite à ce volume « trop important ».

openSUSE minimise le risque en n'écrivant que le strict nécessaire pour démarrer l'OS. Ce strict nécessaire revient à indiquer au microprogramme UEFI l'emplacement du chargeur d'amorçage d'openSUSE. Les fonctionnalités du noyau Linux qui utilisent la zone de stockage de l'UEFI pour stocker les données de démarrage et de plantage (pstore) ont été désactivées par défaut. Il est cependant recommandé d'installer toute mise à jour du microprogramme recommandée par le fournisseur du matériel.

1.5 UEFI, GPT et partitions MS-DOS

Un nouveau type de partitionnement a fait son apparition avec l'arrivée de l'EFI/UEFI : GPT (GUID Partition Table). Ce nouveau schéma emploie des identifiants globaux uniques (des valeurs sur 128 bits affichées sous forme de 32 chiffres hexadécimaux) afin d'identifier les périphériques et les types de partition.

En outre, la spécification UEFI gère également les anciennes partitions MBR (MS-DOS). Les chargeurs d'amorçage Linux (ELILO ou GRUB2) tentent de générer automatiquement un GUID pour ces anciennes partitions, et les écrivent dans le microprogramme. Un GUID de ce type est susceptible de changer fréquemment, occasionnant alors une réécriture dans le microprogramme. Une réécriture est constituée de deux opérations distinctes : l'effacement de l'ancienne entrée et la création d'une nouvelle entrée qui remplace la première.

Un microprogramme moderne dispose d'un nettoyeur qui collecte les entrées supprimées et libère la mémoire réservées aux anciennes entrées. Un problème se présente lorsqu'un microprogramme défectueux ne collecte pas et ne libère pas ces entrées. Ceci peut amener le système à ne plus pouvoir démarrer.

Pour contourner ce problème, convertissez l'ancienne partition MBR en nouvelle partition GPT.

1.6 Paquet de service tlp

Lors de l'installation sur un ordinateur portable, le paquet tlp est installé (ainsi que son sous-paquet tlp-rdw, si l'installation des paquets recommandés est activée). Ce paquet fournit des outils supplémentaires pour économiser la batterie des ordinateurs portables, notamment ceux de Lenovo.

Le service n'est pas activé par défaut car il pourrait interférer avec d'autres outils spécialisés pour ordinateurs portables, par exemple, laptop-mode-tools, rfkill, gnome-power-manager, ou kde-power-manager. Pour activer et démarrer le service explicitement, utilisez le gestionnaire de services YaST ou utilisez la commande systemctl enable --now tlp.service . Si vous rencontrez un comportement inattendu par la suite, par exemple des problèmes de WiFi ou des ports USB non fonctionnels, désactivez à nouveau le service.

2 Mise à niveau du système

Cette section liste des informations à propos de la mise à niveau du système. Pour découvrir les scénarios supportés et des instructions détaillées sur la mise à niveau, veuillez consulter la documentation sur :

En outre, veuillez vérifier Section 3, « Paquets et fonctionnalités supprimés et dépréciés ».

2.1 Mise à niveau simplifiée depuis openSUSE Leap 15.2

openSUSE Leap 15.3 est désormais construit sur des rpms binaires de SUSE Linux Enterprise Server. Ce changement a été introduit dans le cadre de l'effort Closing The Leap Gap (CtLG) pour rapprocher openSUSE Leap et SUSE Linux Enterprise Server.

Contrairement à 15.2, l'installation par défaut d'openSUSE Leap 15.3 contient une majorité de rpms de SUSE Linux Enterprise Server. Ces rpms sont signés par SUSE LLC au lieu d'utiliser la clé openSUSE. Le paquet libzypp dans sa version 12.25.8 a introduit une liste blanche pour l'échange de fournisseurs SUSE LLC et openSUSE afin de permettre une migration transparente. Cette liste blanche supprime la nécessité de spécifier --allow-vendor-change pour les échanges entre fournisseurs openSUSE et SUSE LLC uniquement. Vous pourriez encore avoir besoin de spécifier --allow-vendor-change pendant la migration si vous utilisez des référentiels OBS signés avec d'autres clés.

openSUSE Leap releases older than 15.2 do not contain this feature because they are not supported anymore. All users are advised to upgrade to openSUSE Leap 15.2 with the latest updates before upgrading to 15.3. The following parameters can be used as a workaround for libzypp versions older than 12.25.8 (replace 15.0 below with your current openSUSE version):

zypper addrepo --check --refresh --name 'openSUSE-Leap-15.0-Update' http://download.opensuse.org/update/leap/15.0/oss/ repo-update
zypper dup --allow-vendor-change --force-resolution

openSUSE Leap 15.3 fournit toutes les clés de vérification RPM requises, y compris celles de SUSE Linux Enterprise Server, intégrées dans le paquet openSUSE-build-key. Toutes les clés sont également nouvellement disponibles à l'intérieur du dépôt OSS.

Le paquet libzypp version 17.25.11 devrait automatiquement importer les clés requises qui sont identifiées comme étant de confiance. Si c'est le cas, vous serez notifié de l'importation et aucune autre action ne sera nécessaire.

Si le système n'a pas importé la clé qui a été utilisée pour signer les repodata, vous devrez l'importer manuellement. Vous pouvez vérifier en exécutant la commande suivante :

rpm -qa gpg-pubkey

La sortie devrait inclure une ligne commençant par le texte suivant : gpg-pubkey-39db7c82-* Si ce n'est pas le cas, faites ce qui suit pour importer la clé manuellement :

  • Téléchargez la clé SUSE Linux Enterprise 15 à partir de https://download.opensuse.org/distribution/leap/15.3/repo/oss/gpg-pubkey-39db7c82-5847eb1f.asc.

  • Enregistrez la clé dans le répertoire /var/cache/zypp/pubkeys. Renommez-la de manière à ce qu'elle se termine par .key.

  • Exécutez la commande zypper dup. Il vous sera demandé d'importer la clé manquante. Cela se produira même si la clé se trouve dans le répertoire mentionné ci-dessus. Si le fichier contient plusieurs clés, zypper n'importera que la clé requise.

Pour plus d'informations, consultez https://bugzilla.opensuse.org/show_bug.cgi?id=1184326.

2.2 Alignement de l'empaquetage du noyau de SUSE Linux Enterprise Server et d'openSUSE Leap

Sur openSUSE Leap, le noyau par défaut a été divisé en trois sous-paquets : kernel-default, kernel-default-extra, et kernel-default-optional. De même, kernel-preempt a également été divisé en kernel-preempt, kernel-preempt-extra, et kernel-preempt-optional. Le paquet -optional contient des modules optionnels uniquement pour openSUSE Leap. Le paquet -extra contient des modules non pris en charge. Le mode de préemption du noyau peut être contrôlé en définissant le paramètre preempt=voluntary du noyau sur la ligne de commande. Ce paramètre fonctionne avec kernel-default.

Si vous utilisez cette variante du noyau, assurez-vous que tous les RPMs nécessaires à votre type d'utilisation sont bien installés.

3 Paquets et fonctionnalités supprimés et dépréciés

3.1 Paquets et fonctionnalités obsolètes

Les paquets obsolètes sont toujours fournis par la distribution mais sont prévus pour être supprimés dans la prochaine version d'openSUSE Leap. Ces paquets existent pour faciliter la migration, mais leur utilisation est déconseillée et ils peuvent ne pas recevoir de mise à jour.

  • midori, un navigateur web léger basé sur WebKit et GTK+, n'est plus pris en charge et sa suppression est prévue dans la prochaine version.

Pour vérifier si des paquets installés ne sont plus maintenus : assurez-vous que lifecycle-data-openSUSE est installé puis utilisez la commande :

zypper lifecycle

3.2 Paquets et fonctionnalités supprimés

Les paquets supprimés ne font plus partie de la distribution.

3.2.1 Suppression du support de ReiserFS

Avec openSUSE Leap 15.3, la prise en charge de ReiserFS a été complètement supprimée de YaST et du noyau, et le programme d'installation bloquera la mise à niveau lorsqu'il détectera un système de fichiers ReiserFS.

Pour les partitions de données existantes formatées avec ReiserFS, nous suggérons de les convertir en Btrfs avant de migrer votre système vers openSUSE Leap 15.3.

3.2.2 Berkeley DB supprimé des paquets

Berkeley DB, utilisé comme base de données dans certains paquets, est sous double licence GNU AGPLv3/Sleepycat. Comme les fournisseurs de services qui redistribuent nos paquets pourraient trouver les paquets avec ces licences potentiellement préjudiciables à leurs solutions, nous avons décidé de supprimer Berkeley DB comme dépendance de ces paquets. À long terme, SUSE vise à fournir une solution sans Berkeley DB.

Ce changement affecte les paquets suivants :

  • apr-util

  • cyrus-sasl

  • iproute2

  • perl

  • php7

  • postfix

  • rpm

4 Pilotes et matériel

4.1 Secure Boot : Paquets signés du noyau de SUSE Linux Enterprise et des modules noyau d'openSUSE

Le paquet nouvellement introduit openSUSE-signkey-cert est requis pour les KMPs d'openSUSE comme virtualbox, mais seulement en mode Secure Boot. Le paquet inclut le certificat de la clé de signature d'openSUSE pour signer le fichier du module du noyau (.ko) dans openSUSE KMP et appelle mokutil pour aider l'utilisateur à inscrire le certificat dans MOK. De cette façon, le KMP d'openSUSE peut être vérifié par le noyau.

Si le modèle de base n'est pas installé et que vous utilisez l'un de ces KMP, nous vous recommandons d'installer manuellement le paquet openSUSE-signkey-cert. Un redémarrage du système est nécessaire. Vous trouverez de plus amples informations sur ce processus et sur l'inscription manuelle à l'adresse https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot.

4.2 Secure Boot : les pilotes tiers doivent être correctement signés

openSUSE Leap 15.2 et les versions suivantes activent la vérification des signatures des modules noyaux pour les pilotes tiers (CONFIG_MODULE_SIG=y). C'est une mesure de sécurité importante pour éviter l’exécution de code non-approuvé dans le noyau.

Cela peut empêcher le chargement de modules noyau tiers si le mode Secure Boot UEFI est activé. Les paquets de modules noyau (KMP) des dépôts officiels openSUSE ne sont pas concernés, car les modules qu'ils contiennent sont signés avec la clé openSUSE. La vérification de signature a le comportement suivant :

  • Les modules du noyau qui ne sont pas signés ou qui sont signés par une clé qui est connue comme non sûre ou qui ne peut être vérifiée par rapport à la base de données de clés du système seront bloqués.

Il est possible de générer un certificat personnalisé, de l'inscrire dans la base de données de clés Machine Owner Key (MOK) du système et de signer les modules du noyau compilés localement avec la clé de ce certificat. Les modules signés de cette manière ne seront pas bloqués et ne provoqueront pas d'avertissement. Voir https://en.opensuse.org/openSUSE:UEFI.

Comme cela affecte également les pilotes graphiques NVIDIA, nous avons abordé ce problème dans nos paquets officiels pour openSUSE. Cependant, vous devez enregistrer manuellement une nouvelle clé MOK après l'installation pour que les nouveaux paquets fonctionnent. Pour obtenir des instructions sur l'installation des pilotes et l'enregistrement de la clé MOK, voir https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot.

5 Bureau

Cette section liste les problèmes et les changements liés aux environnements de bureau dans openSUSE Leap 15.3.

5.1 KDE 4 et Qt 4 ont été supprimés

Les paquets KDE 4 ne font plus partie d'openSUSE Leap 15.3. Mettez votre système à jour vers Plasma 5 et Qt 5. Certains paquets Qt 4 peuvent subsister pour des raisons de compatibilité. Pour plus d'informations, voir https://bugzilla.opensuse.org/show_bug.cgi?id=1179613.

5.2 La migration manuelle de la configuration d'IBus est nécessaire en raison du changement de nom de la disposition

Depuis que le IBus dans sa version 1.5.23 a renommé certaines dispositions de clavier, il ne peut pas charger la configuration contenant ces dispositions renommées après la mise à niveau. Par conséquent, il peut réinitialiser la disposition sur US. Les dispositions des langues suivantes sont concernées : Belge, allemand, grec, roumain et slovaque. Voir https://bugzilla.opensuse.org/show_bug.cgi?id=1177545 pour plus d'informations.

Les utilisateurs doivent migrer la configuration manuellement. Ouvrez les paramètres GNOME et choisissez une disposition appropriée. Pour les environnements de bureau autres que GNOME, exécutez ibus-setup à la place.

6 Plus d'informations et de retours

  • Veuillez lire les documents README sur le support de stockage.

  • Voir les informations détaillées du journal de modifications à propos d'un paquet particulier à partir de RPM :

    rpm --changelog -qp NOM_DU_PAQUET.rpm

    Remplacez NOM_DU_PAQUET par le nom du paquet RPM.

  • Vérifiez le fichier ChangeLog à la racine du support de stockage pour un historique chronologique de toutes les modifications apportées aux paquets mis à jours.

  • Retrouvez plus d'informations dans le dossier docu sur le support de stockage.

  • Pour une documentation supplémentaire ou mise à jour, consultez https://doc.opensuse.org/.

  • Pour les dernières nouvelles sur openSUSE, consultez https://www.opensuse.org .

Copyright © SUSE LLC

Imprimer cette page