Note di rilascio #

The openSUSE Leap 15.3 maintenance setup consists of three main update repositories. These are: repo-update, repo-backports-update, and repo-sle-update. The latter two are new and are a result of re-using binaries from SUSE Linux Enterprise. These repositories are available and checked during the online installation of openSUSE Leap. We recommend you to use them. New update repository definitions for openSUSE Leap 15.3 will be additionally supplied via a 0day maintenance update of the openSUSE-release package. The update will be delivered via the traditional repo-update maintenance channel. It will carry a special update flag that means it touches the software management area which is then specially handled by zypper. You should double-check using the zypper up command whether all updates were processed. For more information, see https://bugzilla.opensuse.org/show_bug.cgi?id=1186593.

The repo-update repository is for openSUSE Leap (OSS) updates. It is the smallest one and contains system configuration packages, including release package, branding, and potential forks of SUSE Linux Enterprise packages. This repository has also a debug-info variant.

The repo-backports-update repository is an update repository for openSUSE Backports that contains updates for the majority of openSUSE Leap packages. This repository also has a debug-info variant.

The third repository, named repo-sle-update, is an update repository that contains combined updates from all active SUSE Linux Enterprise update streams. This repository is without the debug-info variant.

L'installatore supporta il ruolo di sistema Server transazionale. Questo ruolo di sistema include un metodo di aggiornamento che applica gli aggioramenti in maniera atomica (come operazione singola) e ne rende semplice il ripristino qualora fosse necessario. Queste funzionalità sono basate sui sistemi di gestione dei pacchetti su cui fanno affidamento tutte le altre distribuzioni SUSE e openSUSE. Ciò significa che la maggioranza di pacchetti RPM che funzionano con altri ruoli di sistema di openSUSE Leap 15.3 funzionano anche con il ruolo di sistema Server transazionale.

Nota: Pacchetti incompatibili

Alcuni pacchetti modificano i contenuti di /var o di /srv nei %post script all'interno del relativo RPM. Questi pacchetti sono incompatibili. Qualora si dovesse rinvenire un pacchetto del genere, compilare una segnalazione d'errore.

Per fornire queste funzionalità, questo aggiornamento del sistema fa affidamento su:

Importante: Il Server transazionale richiede almeno 12 GB di spazio su disco

Il ruolo di sistema server transazionale necessita di uno spazio disco di almeno 12 GB per accomodare le istantanee Btrfs.

Importante: YaST non funziona nella modalità transazionale

Attualmente YaST non funziona con gli aggiornamenti transazionali. Questo perché esegue immediatamente le cose, e perché non può modificare un filesystem a sola lettura.

Per lavorare con gli aggiornamenti transazionali, usare sempre il comando transactional-update per la gestione di tutti i programmi invece di YaST e Zypper:

Quando si utilizza questo ruolo di sistema, in maniera predefinita il sistema eseguirà un aggiornamento giornaliero e un riavvio tra le 03:30 e le 05:00 del mattino. Entrambe queste azioni sono basate su systemd e se necessario possono essere disabilitate usando systemctl:

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

Per maggiori informazioni sugli aggiornamenti transazionali, fare riferimento agli interventi sul blog openSUSE Kubic https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ e https://kubic.opensuse.org/blog/2018-04-20-transactionalupdates2/.

L'installatore proporrà uno schema di partizionamento se la capacità disponibile dell'hard disk supera i 12 GB. Se si intende configurare, per esempio, immagini di macchine virtuali molto piccole, usare il partizionatore guidato per regolare manualmente i parametri di partizionamento.

Prima di installare openSUSE su un sistema che si avvia usando UEFI (Unified Extensible Firmware Interface), si verifichi urgentemente se esiste un aggiornamento del firwmare raccomandato dal fornitore dell'hardware e, se disponibile, lo si installi. Un sistema Windows 8 u successivo pre-installato indica che quasi sicuramente il sistema si avvia usando UEFI.

Informazioni di base: alcuni firmware UEFI presentano dei bug che ne causano il malfunzionamento quando si scrive una quantità di dati eccessiva nell'area di memorizzazione UEFI. Tuttavia nessuno conosce di preciso a quanto corrisponda questa «quantità eccessiva».

openSUSE minimizza il rischio non scrivendo alcun dato oltre al minimo richiesto per avviare il sistema operativo. Il minimo significa dire al firmware UEFI la locazione del boot loader di openSUSE. Le funzionalità del kernel Linux upstream che usano l'area di memorizzazione UEFI per memorizzare le informazioni di avvio e crash (pstore) sono state disabilitate in modo predefinito. Comunque sia si raccomanda di installare qualsiasi aggiornamento firmware raccomandato dal fornitore dell'hardware.

Assieme alla specifica EFI/UEFI è arrivato un nuovo stile di partizionamento: GPT (Tabella delle Partizioni GUID). Questo nuovo schema usa identificatori univoci globali (valori a 128 bit rappresentati con 32 caratteri esadecimali) per identificare dispositivi e tipi di partizione.

La specifica UEFI permette inoltre le partizioni obsolete MBR (MS-DOS). I boot loader Linux (ELILO o GRUB2) cercano di generare automaticamente un GUID per tali partizioni obsolete e di scriverlo nel firmware. Tale GUID può cambiare frequentemente causando la riscrittura nel firmware. Una riscrittura è composta da due operazioni diverse: rimozione della vecchia voce e creazione di una nuova voce che sostituisce la prima.

Il firmware moderno possiede un garbage collector che raccoglie le voci cancellate e libera la memoria riservata per le vecchie voci. Un problema sorge quando un firmware difettoso non raccoglie e libera tali voci: ne potrebbe derivare un sistema non avviabile.

Per aggirare tale problema, convertire le partizioni MBR obsolete nelle nuove GPT.

During installation on a laptop, the tlp package is installed (together with its sub-package tlp-rdw, if the installation of recommended packages is enabled). This package provides additional tools to save battery power on laptops, especially Lenovo laptops.

The service is not enabled by default because it might interfere with other specialized laptop tools, for example, laptop-mode-tools, rfkill, gnome-power-manager, or kde-power-manager. To enable and start the service explicitly, use YaST Services Manager or use the command systemctl enable --now tlp.service . If you encounter any unexpected behavior afterward, for example, WiFi problems or non-functional USB ports, disable the service again.

openSUSE Leap 15.3 is newly built on top of binary rpms from SUSE Linux Enterprise Server. This change was introduced as part of the Closing The Leap Gap (CtLG) effort to bring openSUSE Leap and SUSE Linux Enterprise Server closer together.

Unlike 15.2, the default installation of openSUSE Leap 15.3 contains the majority of rpms from SUSE Linux Enterprise Server. These rpms are signed by SUSE LLC instead of using the openSUSE key. The libzypp package version 12.25.8 introduced whitelist for the SUSE LLC and openSUSE vendor exchange to allow seamless migration. This whitelist removes the need to specify --allow-vendor-change for openSUSE and SUSE LLC vendor exchange only. You might still need to specify --allow-vendor-change during migration if you are using OBS repositories signed with other keys.

openSUSE Leap releases older than 15.2 do not contain this feature because they are not supported anymore. All users are advised to upgrade to openSUSE Leap 15.2 with the latest updates before upgrading to 15.3. The following parameters can be used as a workaround for libzypp versions older than 12.25.8 (replace 15.0 below with your current openSUSE version):

zypper addrepo --check --refresh --name 'openSUSE-Leap-15.0-Update' http://download.opensuse.org/update/leap/15.0/oss/ repo-update
zypper dup --allow-vendor-change --force-resolution

openSUSE Leap 15.3 provides all the required RPM verification keys, including the SUSE Linux Enterprise Server ones, as part of the openSUSE-build-key package. All the keys are also newly available inside the OSS repository.

The libzypp package version 17.25.11 should automatically import the required keys that are identified as trusted. If it has, you will be notified about the import and no other action will be needed.

If the system has not imported the key that was used to sign the repodata, you will need to import it manually. You can check by running the following command:

rpm -qa gpg-pubkey

The output should include a line starting with the following text: gpg-pubkey-39db7c82-* If it does not, the do the following to import the key manually:

For more information, see https://bugzilla.opensuse.org/show_bug.cgi?id=1184326.

In openSUSE Leap il kernel predefinito è stato diviso in tre sotto-pacchetti: kernel-default, kernel-default-extra e kernel-default-optional. Allo stesso modo kernel-preempt è stato diviso in kernel-preempt, kernel-preempt-extra e kernel-preempt-optional. Il pacchetto -optional contiene dei moduli facoltativi che sono solo per openSUSE Leap, mentre -extra contiene dei moduli non supportati. La modalità di prelazione del kernel può essere controllata impostando il parametro del kernel preempt=voluntary da riga di comando. Questo parametro funziona con kernel-default.

Assicurarsi che tutti gli RPM richiesti siano installati, se si utilizza questa variante del kernel.

Pacchetti deprecati fanno tuttora parte della distribuzione ma la loro rimozione è in programma per la prossima versione di openSUSE Leap. Tali pacchetti sono inclusi per agevolare la migrazione ma il loro uso è sconsigliato e potrebbero non ricevere aggiornamenti.

Per controllare se i pacchetti installati non siano più sottoposti a manutenzione: assicurarsi che lifecycle-data-openSUSE sia installato e quindi usare il comando:

zypper lifecycle

I pacchetti rimossi non sono più forniti come parte della distribuzione.

The newly introduced openSUSE-signkey-cert package is required for openSUSE KMPs like virtualbox, but only in Secure Boot mode. The package includes the certificate of openSUSE signing key for signing kernel module file (.ko) in openSUSE KMP and calls mokutil to help user enroll the certificate to MOK. This way, the openSUSE KMP can be verified by the kernel.

If you do not have the base pattern installed and are using any of these KMPs, we recommend installing the openSUSE-signkey-cert package manually. A system reboot is required. More information about this process and manual enrollment can be found at https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot.

openSUSE Leap 15.2 e le versioni successive abilitano un modulo del kernel per la verifica della firma dei driver di terze parti (CONFIG_MODULE_SIG=y). Questa è un'importante misura di sicurezza che evita l'esecuzione di codice non fidato nel kernel.

Ciò può impedire il caricamento di moduli del kernel di terze parti se l'avvio protetto UEFI è abilitato. I pacchetti di moduli del kernel (KMP, Kernel Module Packages) che provengono dai repository ufficiali di openSUSE non sono interessati, perché essi contengono dei moduli che sono firmati con la chiave di openSUSE. Il controllo della firma ha il comportamento seguente:

È possibile generare un certificato personalizzato, registrarlo nel database MOK (Machine Owner Key) del sistema e firmare i moduli del kernel compilati localmente con la chiave di questo certificato. I moduli firmati in questo modo non verranno né bloccati né genereranno avvisi. Vedere https://en.opensuse.org/openSUSE:UEFI.

Dal momento che questo influisce anche sui driver grafici NVIDIA abbiamo affrontato questo problema nei nostri pacchetti ufficiali per openSUSE, tuttavia è necessario registrare manualmente una nuova chiave MOK dopo l'installazione per far funzionare i nuovi pacchetti. Per istruzioni su come installare i driver e su come registrare la chiave MOK, vedere https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot.

I pacchetti di KDE 4 non fanno più parte di openSUSE Leap 15.3; aggiornare quindi il sistema a Plasma 5 e a Qt 5. Alcuni pacchetti Qt 4 possono esserci ancora per ragioni di compatibilità. Per maggiori informazioni vedere https://bugzilla.opensuse.org/show_bug.cgi?id=1179613.

Since IBus version 1.5.23 renamed some keyboard layouts, it cannot load configuration containing these renamed layouts after upgrading. Thereby, it might reset the layout to US. Layouts of the following languages are affected: Belgian, German, Greek, Romanian, and Slovak. See https://bugzilla.opensuse.org/show_bug.cgi?id=1177545 for more information.

Users need to migrate configuration manually. Open GNOME Settings and choose an appropriate layout. For desktop environments other than GNOME, run ibus-setup instead.