Notes de la versió #

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.

NotaIncompatible packages

Alguns paquets modifiquen els continguts de /var o /srv als scripts %post d'RPM. Aquests paquets no són compatibles. Si en trobeu un, tramiteu un informe d'error.

Per proporcionar aquestes funcionalitats, aquest sistema d'actualització confia en el següent:

ImportantTransactional Server needs at least 12 GB of disk space

The system role Transactional Server needs a disk size of at least 12 GB to accommodate Btrfs snapshots.

Per treballar amb les actualitzacions transaccionals, useu sempre l'ordre transactional-update en comptes del YaST o el Zypper per a totes les gestions de programari:

When using this system role, by default, the system will perform a daily update and reboot between 03:30 am and 05:00 am. Both of these actions are systemd-based and if necessary can be disabled using systemctl:

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

Per a més informació sobre les actualitzacions transaccionals, vegeu els apunts del blog de l'openSUSE Kubic https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ i https://kubic.opensuse.org/blog/2018-04-20-transactionalupdates2/.

The installer will only propose a partitioning scheme if the available hard disk size is larger than 12 GB. If you want to set up, for example, very small virtual machines images, use the guided partitioner to tune partitioning parameters manually.

Abans d'instal·lar l'openSUSE en un sistema que arrenqui amb UEFI (Unified Extensible Firmware Interface), us suggerim emfàticament que comproveu qualsevol actualització del microprogramari que pugui recomanar-ne el fabricant i, si està disponible, que la instal·leu. Si teniu Windows 8 o posterior preinstal·lat és una sòlida indicació que el sistema arrenca amb UEFI.

Background: Algun microprogramari UEFI té errors que causen que falli si s'escriuen massa dades a l'àrea d'emmagatzematge UEFI. Ara bé, no hi ha informació clara sobre què vol dir exactament «massa».

L'openSUSE en minimitza el risc no escrivint més que el mínim necessari per arrencar el sistema. El mínim significa dir al microprogramari UEFI la localització del carregador d'arrencada de l'openSUSE. Les característiques de la font original del nucli de Linux que usen l'àrea d'emmagatzematge UEFI per desar-hi informació d'arrencada i de fallades (pstore) s'han inhabilitat per defecte. Tot i això, és recomanable instal·lar qualsevol actualització del microprogramari UEFI que el fabricant recomani.

Amb la implementació d'EFI/UEFI, va arribar un nou estil de partició: GPT (GUID Partition Table). Aquest nou esquema usa identificadors globalment únics (valors de 128 bits mostrats en 32 dígits hexadecimals) per identificar dispositius i tipus de particions.

Addicionalment, l'especificació UEFI també permet particions de llegat MBR (MS-DOS). Els carregadors d'arrencada de Linux (ELILO o GRUB2) intenten generar automàticament un GUID per a aquestes particions de llegat i escriure-les al microprogramari. Aquest GUID pot canviar freqüentment i causar una reescriptura al microprogramari. Aquesta reescriptura consisteix en dues operacions diferents: suprimir l'entrada antiga i crear-ne una que reemplaci la primera.

El microprogramari modern té un recollidor de porqueria que recull entrades esborrades i allibera la memòria reservada per a entrades antigues. Sorgeix un problema quan un microprogramari és defectuós i no ho fa, això pot arribar a suposar que un sistema que no arrenqui.

La solució provisional és simple: convertir la partició de llegat MBR a GPT.

Hi ha paquets obsolets que encara s'inclouen com a part de la distribució però hi ha la planificació de suprimir-los a la propera versió de l'openSUSE Leap. Aquests paquets existeixen per ajudar a fer la migració, però se'n desencoratja l'ús i poden no rebre actualitzacions.

Per comprovar si teniu paquets instal·lats que ja no es mantinguin, assegureu-vos que tingueu el paquet lifecycle-data-openSUSE estigui instal·lat i useu l'ordre següent:

zypper lifecycle

Els paquets suprimits ja no s'inclouen com a part de la distribució.

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.

Això pot evitar que es carreguin mòduls del nucli de tercers si està activada l'arrencada segura d'UEFI. Això no afecta els paquets de mòduls del nucli (KMP) dels repositoris oficials d'openSUSE, perquè els mòduls que contenen estan signats amb la clau d'openSUSE. El control de signatura té el comportament següent:

És possible generar un certificat personalitzat, registrar-lo a la base de dades MOK (Key Owner Key of Owner Machine) del sistema i signar mòduls de nucli compilats localment amb la clau d’aquest certificat. Els mòduls signats d'aquesta manera no es blocaran ni provocaran avisos. Vegeu https://en.opensuse.org/openSUSE:UEFI.

Com que això també afecta als controladors gràfics d'NVIDIA, ho vam abordar als nostres paquets oficials per a l'openSUSE. Tanmateix, cal inscriure manualment una clau MOK nova després de la instal·lació per fer que els nous paquets funcionin. Per obtenir instruccions sobre com instal·lar els controladors i registrar la clau MOK, vegeu 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.