The installer supports the system role Transactional Server. This system role features an update system that applies updates atomically (as a single operation) and makes them easy to revert should that become necessary. These features are based on the package management tools that all other SUSE and openSUSE distributions also rely on. This means that the vast majority of RPM packages that work with other system roles of openSUSE Leap 15.3 also work with the system role Transactional Server.

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

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.

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 and later enable a kernel module signature check for third-party drivers (CONFIG_MODULE_SIG=y). This is an important security measure to avoid untrusted code running in the kernel.

This may prevent third-party kernel modules from being loaded if UEFI Secure Boot is enabled. Kernel Module Packages (KMPs) from the official openSUSE repositories are not affected, because the modules they contain are signed with the openSUSE key. The signature check has the following behavior:

It is possible to generate a custom certificate, enroll it into the system's Machine Owner Key (MOK) data base, and sign locally compiled kernel modules with this certificate's key. Modules signed in this manner will neither be blocked nor cause warnings. See https://en.opensuse.org/openSUSE:UEFI.

Since this also affects NVIDIA graphics drivers, we addressed this in our official packages for openSUSE. However, you need to manually enroll a new MOK key after installation to make the new packages work. For instructions how to install the drivers and enroll the MOK key, see https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot.

KDE 4 packages are no longer part of openSUSE Leap 15.3. Update your system to Plasma 5 and Qt 5. Some Qt 4 packages may still remain for compatibility reasons. For more information, see https://bugzilla.opensuse.org/show_bug.cgi?id=1179613.