Notas de la versión #

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.

Nota: Incompatible packages

Algunos paquetes modifican el contenido de /var o /srv en sus guiones %post de RPM. Estos paquetes son incompatibles. Si usted se encuentra con este tipo de paquete, presente un informe de error.

Para proporcionar estas características, este sistema de actualización se basa en:

Importante: Transactional 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.

Para trabajar con actualizaciones transaccionales, use siempre la orden transactional-update en vez de YaST y Zypper para toda la gestión del software:

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

Para obtener más información sobre las actualizaciones transaccionales, vea las publicaciones del blog de openSUSE Kubic https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ y 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.

Antes de instalar openSUSE en un sistema que se inicia utilizando UEFI (Interfaz de Firmware Extensible Unificada), se recomienda encarecidamente verificar si hay actualizaciones del «firmware» del fabricante y, de existir, instalar dichas actualizaciones. Un sistema con Windows 8 o posterior preinstalado es un gran indicador de que su sistema se inicia utilizando UEFI.

Antecedentes: Algunos «firmware» UEFI tienen fallos que causan problemas si se escribe demasiada información en el área de almacenamiento UEFI. Nadie sabe realmente cuánto es «demasiado».

openSUSE minimiza el riesgo al no escribir más del mínimo necesario para iniciar el sistema. Lo mínimo significa indicar al «firmware» UEFI la ubicación del cargador de arranque de openSUSE. El kernel Linux original tiene características que utilizan el área de almacenamiento UEFI para grabar información de inicio e información de fallos (pstore), las cuales han sido deshabilitadas. Aún así, se recomienda instalar cualquier actualización de «firmware» recomendada por el fabricante.

Junto con la especificación EFI/UEFI, ha llegado un nuevo estilo de particionamiento: GPT (GUID Partition Table). Este nuevo esquema usa identificadores globalmente únicos (valores de 128-bit mostrados como 32 dígitos hexadecimales) para identificar dispositivos y tipos de particiones.

Además, la especificación UEFI también permite particiones tradicionales MBR (MS-DOS). Los cargadores de arranque de Linux (ELILO o GRUB2) tratan de generar automáticamente un GUID para esas particiones tradicionales y escribirlos al «firmware». Tal GUID puede cambiar frecuentemente, causando una escritura en el «firmware». Una escritura consta de dos operaciones distintas: quitar la entrada antigua y crear una nueva que reemplaza a la primera.

Los «firmware» modernos incorporan un recolector de basura que recoge las entradas eliminadas y libera la memoria reservada para las entradas anteriores. Cuando un «firmware» defectuoso no recoge y libera esas entradas surge un problema. Ésto puede traducirse en que el sistema no arranque.

Para solucionar este problema, convierta la partición MBR en GPT.

Los paquetes obsoletos aún se incluyen como parte de la distribución, pero su eliminación está planificada para la próxima versión de openSUSE Leap. Dichos paquetes existen para ayudar con la migración, pero su uso está desaconsejado y puede que no reciban actualizaciones.

Para comprobar si hay paquetes instalados que ya no reciben mantenimiento: asegúrese de que lifecycle-data-openSUSE está instalado y a continuación ejecute la orden:

zypper lifecycle

Los paquetes eliminados ya no formarán parte de la distribución.

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.

Esto previene que módulos de terceros sean integrados al kernel si el arranque seguro UEFI se encuentra activado. Los Paquetes de Módulos del Kernel (KMPs) que provengan de los repositorios oficiales de openSUSE no serán afectados, pues estos se firman con la llave de openSUSE. La verificación de la signatura tiene el siguiente comportamiento:

Existe la posiblidad de crear un cerificado personalizado, inscribirlo en la base de datos "Machine Owner Key" (MOK) y firmar módulos compilados en el sistema con dicho certificado. Los módulos firmados bajo esta modalidad no son bloqueados ni generan advertencias. Véase https://es.opensuse.org/openSUSE:UEFI.

Ya que esto también afecta a los controladores de NVIDIA, consideramos esto en los paquetes oficiales para openSUSE; sin embargo, es necesario autorizar la nueva llave MOK al finalizar la instalación para que los nuevos paquetes funcionen. Para más información sobre el proceso de inscripción de la llave, véase https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot (en inglés).

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.