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.4, działa również z rolą systemową Serwer Transakcyjny.

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

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.

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.

To check whether installed packages are no longer maintained, make sure that the lifecycle-data-openSUSE package is installed, then use the command:

cykl życia zypper

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

Starting with openSUSE Leap 15.2, kernel module signature check for third-party drivers (CONFIG_MODULE_SIG=y) is now enabled. 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.

Pakiety KDE 4 nie będą częścią openSUSE Leap 15.4. Zaktualizuj swój system do Plazmy 5 i Qt 5. Niektóre pakiety Qt 4 mogą nadal pozostać ze względu na kompatybilność. https://bugzilla.opensuse.org/show_bug.cgi?id=1179613.