Notes de version #

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.2 fonctionnent aussi avec le nouveau rôle serveur transactionnel.

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 :

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

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

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.

Le système de fichiers Btrfs est utilisé de préférence sur des systèmes disposant de suffisamment de mémoire vive et de stockage. Les disques durs SSD sont également recommandés. Des utilisateurs ont signalé une dégradation des performances sur des systèmes disposant d'une faible quantité de RAM (4 Go ou moins) et de disques durs ordinaires.

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.

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.

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.

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

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

openSUSE Leap 15.2 active 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 :

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.

La fonction de verrouillage du noyau est conçue pour empêcher l'accès à une image du noyau en cours d'exécution. Elle est active, par exemple, lorsqu'un système démarre en mode EFI Secure Boot.

Pour plus d'informations, voir https://www.mankier.com/7/kernel_lockdown.

Les anciennes cartes graphiques NVIDIA qui nécessitent les pilotes NVIDIA G03 ne sont pas prises en charge.

La mises à jour de KDE 4 et Qt 4 vers Plasma 5 et Qt 5 est recommandée. KDE 4 et Qt 4 ne sont plus pris en charge. openSUSE Leap 15.2 contient encore les paquets KDE 4 et Qt 4 pour des raisons de compatibilité. Cependant, ces paquets ne recevront plus de mises à jour ni de correctifs de sécurité. Ainsi, il est fortement recommandé de remplacer tous les paquets KDE 4 et Qt 4 installés par les paquets Plasma 5 et Qt 5 fournissant les mêmes fonctionnalités ou du moins des fonctionnalités similaires.