Notes de la versió #

L'instal·lador admet el rol de sistema Servidor transaccional. Aquest rol de sistema presenta un sistema d'actualització nou que aplica les actualitzacions atòmicament (com una única operació) i fa que sigui fàcil revertir-les si esdevé necessari. Aquestes funcionalitats estan basades en les eines de gestió de paquets en què es basen totes les altres distribucions de SUSE i d'openSUSE. Això vol dir que una àmplia majoria de paquets RPM que funcionen amb altres rols de sistema de l'openSUSE Leap 15.2 també funcionen amb el rol de Servidor transaccional.

NotaPaquets no compatibles

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:

ImportantEl Servidor transaccional necessita com a mínim 12 GB d'espai de disc

El rol de sistema Servidor transaccional necessita com a mínim 12 GB d'espai de disc per a les instantànies de Btrfs.

ImportantEl YaST no funciona en mode transaccional.

Actualment, el YaST no funciona amb actualitzacions transaccionals. Això es deu al fet que el YaST fa les coses immediatament i perquè no pot editar un sistema de fitxers només de lectura.

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:

Quan s'usa aquest rol de sistema, per defecte, el sistema farà una actualització i un reinici dirari entre les 3:30 a. m. i les 5:00 a. m. Aquestes dues accions estan basades en systemd i, si cal, es poden inhabilitar usant 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/.

L'instal·lador només proposarà un esquema de particions si l'espai de disc dur disponible és superior a 12 GB. Si voleu establir, per exemple, imatges de màquines virtuals molt petites, useu les particions guiades per ajustar-ne els paràmetres manualment.

El sistema de fitxers Btrfs funciona millor en sistemes amb memòria RAM i emmagatzematge suficients. També es recomana un SSD. Hi ha hagut informes d’usuaris sobre la degradació del rendiment en sistemes amb poca quantitat de RAM (4 GB o menys) i unitats de disc dur regulars.

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:

cicle de vida de zypper

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

L'openSUSE Leap 15.2 ara habilita una comprovació de signatura dels mòduls del nucli per als controladors de tercers (CONFIG_MODULE_SIG=y). És una mesura de seguretat important per evitar que s’executi codi que no sigui de confiança al nucli.

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.

La funció de bloqueig del nucli està dissenyada per evitar l'accés a una imatge de nucli en execució. Això està actiu, per exemple, quan un sistema arrenca en mode d'arrencada segura d'EFI.

Per a més informació, vegeu https://www.mankier.com/7/kernel_lockdown.

No s'admeten les targetes gràfiques d'NVIDIA antigues que necessiten els controladors d'NVIDIA G03.

Es recomana l'actualització de KDE 4 i Qt 4 a Plasma 5 i Qt 5. El KDE 4 i el Qt 4 ja no tenen suport. L'openSUSE Leap 15.2 encara conté paquets de KDE 4 i Qt 4 per raons de compatibilitat. Tanmateix, aquests paquets ja no rebran actualitzacions ni correccions de seguretat. Per tant, es recomana fermament reemplaçar tots els paquets KDE 4 i Qt 4 instal·lats per paquets de Plasma 5 i Qt 5 amb les mateixes funcions o, almenys, funcions similars.