Informacje o wydaniu #

Konfiguracja konserwacyjna openSUSE Leap 15.3 składa się z trzech głównych repozytoriów aktualizacji. Są to: repo-update, repo-backports-update i repo-sle-update. Dwa ostatnie są nowe i są wynikiem ponownego wykorzystania plików binarnych z SUSE Linux Enterprise. Te repozytoria są dostępne i sprawdzane podczas instalacji online openSUSE Leap. Zalecamy ich używanie. Nowe definicje repozytoriów aktualizacji dla openSUSE Leap 15.3 będą dodatkowo dostarczane przez 0-dniową aktualizację konserwacyjną pakietu openSUSE-release. Aktualizacja zostanie dostarczona za pośrednictwem tradycyjnego kanału konserwacji repo-update. Będzie nosił specjalną flagę aktualizacji, co oznacza, że dotyka obszaru zarządzania oprogramowaniem, który jest następnie specjalnie obsługiwany przez zypper. Powinieneś dwukrotnie sprawdzić za pomocą polecenia zypper up, czy wszystkie aktualizacje zostały przetworzone. Aby uzyskać więcej informacji, zobacz https://bugzilla.opensuse.org/show_bug.cgi?id=1186593.

Repozytorium repo-update służy do aktualizacji openSUSE Leap (OSS). Jest to najmniejszy i zawiera pakiety konfiguracji systemu, w tym pakiet wersji, branding i potencjalne rozwidlenia pakietów SUSE Linux Enterprise. To repozytorium ma również wariant debug-info.

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.

Trzecie repozytorium, nazwane repo-sle-update, jest repozytorium aktualizacji, które zawiera połączone aktualizacje ze wszystkich aktywnych strumieni aktualizacji SUSE Linux Enterprise. To repozytorium nie zawiera wariantu debug-info.

Instalator obsługuje rolę systemową Serwer transakcyjny. Ta rola systemowa obejmuje system aktualizacji, który stosuje aktualizacje niepodzielnie (jako pojedynczą operację) i ułatwia ich przywrócenie, jeśli zajdzie taka potrzeba. Funkcje te są oparte na narzędziach do zarządzania pakietami, na których opierają się również wszystkie inne dystrybucje SUSE i openSUSE. Oznacza to, że zdecydowana większość pakietów RPM, które współpracują z innymi rolami systemowymi openSUSE Leap 15.3, działa również z rolą systemową Serwer transakcyjny.

Uwaga: Niekompatybilne pakiety

Niektóre pakiety modyfikują zawartość /var lub /srv w swoich skryptach RPM %post. Te pakiety są niezgodne. Jeśli znajdziesz taki pakiet, zgłoś błąd.

Aby zapewnić te funkcje, ten system aktualizacji opiera się na:

Ważne: Serwer transakcyjny potrzebuje co najmniej 12 GB miejsca na dysku

Rola systemowa Serwer transakcyjny wymaga dysku o rozmiarze co najmniej 12 GB, aby pomieścić migawki Btrfs.

Ważne: YaST nie działa w trybie transakcyjnym

Obecnie YaST nie działa z aktualizacjami transakcyjnymi. Dzieje się tak dlatego, że YaST wykonuje rzeczy natychmiast i ponieważ nie może edytować systemu plików tylko do odczytu.

Aby pracować z aktualizacjami transakcyjnymi, zawsze używaj polecenia transactional-update zamiast YaST i Zypper do zarządzania całym oprogramowaniem:

W przypadku korzystania z tej roli systemowej system domyślnie przeprowadza codzienną aktualizację i uruchamia się ponownie między 03:30 a 05:00. Obie te akcje są oparte na systemie i w razie potrzeby można je wyłączyć za pomocą systemctl:

systemctl disable --now transactional-update.timer rebootmgr.service (PL)

Aby uzyskać więcej informacji o aktualizacjach transakcyjnych, zobacz posty na blogu openSUSE Kubic https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ i https://kubic.opensuse.org/blog/2018-04-20-transactionalupdates2/.

Instalator zaproponuje schemat partycjonowania tylko wtedy, gdy dostępny rozmiar dysku twardego jest większy niż 12 GB. Jeśli chcesz skonfigurować na przykład bardzo małe obrazy maszyn wirtualnych, użyj partycjonera z przewodnikiem, aby ręcznie dostroić parametry partycjonowania.

Przed zainstalowaniem openSUSE w systemie, który uruchamia się za pomocą UEFI (Unified Extensible Firmware Interface), pilnie zaleca się sprawdzenie wszelkich aktualizacji oprogramowania sprzętowego zalecanych przez dostawcę sprzętu i, jeśli są dostępne, zainstalowanie takiej aktualizacji. Wstępna instalacja systemu Windows 8 lub nowszego wyraźnie wskazuje, że system uruchamia się przy użyciu UEFI.

Wyjaśnienie: Zdarza się, że firmware interfejsu UEFI zawiera błędy, które powodują niepoprawne działanie, gdy zbyt duża ilość danych jest zapisywana w buforze UEFI. Nie wiadomo jak dużo to „za dużo”.

openSUSE ogranicza ryzyko zapisania większej ilości danych niż jest to niezbędne. Wskazane jest wyłącznie położenie menadżera rozruchu openSUSE. Jądro Linux zapewnia możliwość użycia bufora UEFI do zapisywania informacji dotyczących uruchamiania i błędów, jednakże funkcja (pstore) domyślnie jest zablokowana. Niezależnie od tego zaleca się instalowanie aktualizacji firmware polecanych przez producenta sprzętu.

Wraz ze specyfikacją EFI/UEFI pojawił się nowy styl partycjonowania: GPT (Tabela partycji GUID). Ten nowy schemat używa globalnie unikatowych identyfikatorów (wartości 128-bitowe wyświetlane w 32 cyfrach szesnastkowych) do identyfikacji urządzeń i typów partycji.

Dodatkowo, specyfikacja UEFI partycje MRB (MS-DOS) są kompatybilne wstecz. Program rozruchowy LINUX (ELILO lub GRUB2) próbuje automatycznie wygenerować GUID dla tych partycji i zapisuje je w firmwarze. Takie GUID mogą się często zmieniać, wywołując nadpisanie w firmwarze. Na nadpisanie składają się dwie operacje: Usunięcie starego wpisu oraz stworzenie nowego który zastępuje pierwszy.

Nowoczesny firmware posiada kolektor śmieci który zbiera usunięte wpisy i uwalnia pamięć zarezerwowaną dla starego wpisu.Problem powstaje gdy wadliwy firmware nie zbiera i uwalnia tych wpisów. Może to doprowadzić do problemów z uruchomieniem systemu.

W celu ominięcia problemu, przekształć stare partycje MRB na 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 jest nowo zbudowany na binarnych pakietach RPM z SUSE Linux Enterprise Server. Ta zmiana została wprowadzona w ramach starań Closing The Leap Gap (CtLG) mających na celu zbliżenie do siebie openSUSE Leap i SUSE Linux Enterprise Server.

W przeciwieństwie do 15.2, domyślna instalacja openSUSE Leap 15.3 zawiera większość RPM z SUSE Linux Enterprise Server. Te RPM są podpisane przez SUSE LLC zamiast używania klucza openSUSE. Pakiet libzypp w wersji 12.25.8 wprowadził białą listę dla wymiany dostawców SUSE LLC i openSUSE, aby umożliwić bezproblemową migrację. Ta biała lista eliminuje potrzebę określenia --allow-vendor-change tylko dla wymiany dostawców openSUSE i SUSE LLC. Nadal może być konieczne określenie --allow-vendor-change podczas migracji, jeśli używasz repozytoriów OBS podpisanych innymi kluczami.

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 zapewnia wszystkie wymagane klucze weryfikacji RPM, w tym klucze SUSE Linux Enterprise Server, jako część pakietu openSUSE-build-key. Wszystkie klucze są również nowo dostępne w repozytorium OSS.

Pakiet libzypp w wersji 17.25.11 powinien automatycznie importować wymagane klucze, które są identyfikowane jako zaufane. Jeśli tak, zostaniesz powiadomiony o imporcie i żadne inne działania nie będą potrzebne.

Jeśli system nie zaimportował klucza, który został użyty do podpisania repodata, będziesz musiał zaimportować go ręcznie. Możesz to sprawdzić, uruchamiając następujące polecenie:

rpm -qa gpg- pubkey

Dane wyjściowe powinny zawierać wiersz rozpoczynający się następującym tekstem: gpg-pubkey-39db7c82-* Jeśli tak nie jest, wykonaj następujące czynności, aby ręcznie zaimportować klucz:

Aby uzyskać więcej informacji, zobacz https://bugzilla.opensuse.org/show_bug.cgi?id=1184326.

On openSUSE Leap, the default kernel has been split into three subpackages: kernel-default, kernel-default-extra, and kernel-default-optional. Similarly, kernel-preempt has also been split into kernel-preempt, kernel-preempt-extra, and kernel-preempt-optional. The -optional package contains optional modules only for openSUSE Leap. The -extra package contains unsupported modules. The kernel preemption mode can be controlled by setting the preempt=voluntary kernel parameter on the command line. This parameter works with kernel-default.

Jeśli używasz tego wariantu jądra, upewnij się, że wszystkie pakiety RPM wymagane dla twojego przypadku użycia są zainstalowane.

Przestarzałe pakiety są nadal dostarczane jako część dystrybucji, ale planowane jest ich usunięcie w następnej wersji openSUSE Leap. Pakiety te istnieją w celu ułatwienia migracji, ale ich użycie jest odradzane i mogą nie otrzymywać aktualizacji.

Aby sprawdzić, czy zainstalowane pakiety nie są już obsługiwane: Upewnij się, że lifecycle-data-openSUSE jest zainstalowany, a następnie użyj polecenia:

cykl życia zypper

Usunięte pakiety nie są już dostarczane jako część dystrybucji.

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 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.

Może to uniemożliwić ładowanie modułów jądra innych firm, jeśli jest włączony UEFI Secure Boot. Pakiety modułów jądra (KMP) z oficjalnych repozytoriów openSUSE nie są naruszone, ponieważ moduły, które zawierają, są podpisane kluczem openSUSE. Sprawdzanie podpisu ma następujące zachowanie:

Możliwe jest wygenerowanie certyfikatu niestandardowego, zarejestrowanie go w bazie danych klucza właściciela komputera (MOK) systemu i podpisanie lokalnie skompilowanych modułów jądra za pomocą klucza tego certyfikatu. Moduły podpisane w ten sposób nie będą blokowane ani nie będą powodować ostrzeżeń. Zobacz https://en.opensuse.org/openSUSE:UEFI.

Ponieważ dotyczy to również sterowników graficznych NVIDIA, zajęliśmy się tym w naszych oficjalnych pakietach dla openSUSE. Musisz jednak ręcznie zarejestrować nowy klucz MOK po instalacji, aby nowe pakiety działały. Aby uzyskać instrukcje, jak zainstalować sterowniki i zarejestrować klucz MOK, zobacz 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.

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.