Catatan Rilis #

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.

Pemasang mendukung peran sistem Peladen Transaksional. Peran sistem ini menampilkan sistem pembaruan yang menerapkan pembaruan secara atomis (sebagai operasi tunggal) dan membuat mereka mudah dikembalikan sekiranya dibutuhkan. Fitur-fitur ini didasarkan pada alat bantu manajemen paket yang juga diandalkan oleh semua distribusi SUSE dan openSUSE lainnya. Ini berarti bahwa sebagian besar paket RPM yang bekerja dengan peran sistem lain dari openSUSE Leap 15.3 juga bekerja dengan peran sistem Peladen Transaksional.

CatatanPaket-paket yang tidak kompatibel

Beberapa paket memodifikasi konten /var atau /srv dalam skrip %post RPM mereka. Paket-paket ini tidak kompatibel. Jika Anda menemukan paket seperti itu, ajukan laporan kutu.

Untuk menyediakan fitur-fitur ini, sistem pemutakhiran ini mengandalkan:

PentingPeladen Transaksional membutuhkan ruang diska sekurang-kurangnya 12 GB

Peran sistem Peladen Transaksional membutuhkan ukuran disk setidaknya 12 GB untuk mengakomodasi snapshot Btrfs.

PentingYaST Tidak Bekerja Pada Mode Transaksional

Saat ini, YaST tidak berfungsi dengan pemutakhiran transaksional. Ini karena YaST melakukan sesuatu dengan segera dan karena tidak dapat menyunting sistem berkas hanya-baca.

Untuk bekerja dengan pemutakhiran transaksional, selalu gunakan perintah transactional-update alih-alih YaST dan Zypper untuk semua manajemen perangkat lunak:

Saat menggunakan peran sistem ini, secara bawaan, sistem akan melakukan pemutakhiran harian dan nyala ulang antara pukul 03:30 dan 05:00. Kedua tindakan ini berbasis systemd dan jika perlu dapat dinonaktifkan menggunakan systemctl:

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

Untuk informasi lebih lanjut tentang pemutakhiran transaksional, lihat entri blog openSUSE Kubic https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ dan https://kubic.opensuse.org/blog/2018-04-20-transactionalupdates2/.

Pemasang hanya akan mengusulkan skema partisi jika ukuran diska yang tersedia lebih besar dari 12 GB. Jika Anda ingin mengatur, misalnya, citra mesin virtual yang sangat kecil, gunakan pemartisi terpandu untuk menyetel parameter pemartisian secara manual.

Sebelum memasang openSUSE pada sistem yang melakukan booting menggunakan UEFI (Unified Extensible Firmware Interface), Anda sangat disarankan untuk memeriksa pemutakhiran perangkat tegar (firmware) yang direkomendasikan vendor perangkat keras dan, jika tersedia, untuk memasang pemutakhiran semacam itu. Pra-instalasi Windows 8 atau yang lebih baru merupakan indikasi kuat bahwa sistem Anda melakukan booting menggunakan UEFI.

Latar Belakang: Beberapa perangkat tegar (firmware) UEFI memiliki kutu yang menyebabkannya rusak jika terlalu banyak data yang ditulis ke area penyimpanan UEFI. Namun, tidak ada data yang jelas berapa “banyaknya”.

openSUSE meminimalkan risiko dengan tidak menulis lebih dari jumlah minimum yang diperlukan untuk boot ke OS. Minimum berarti memberi tahu perangkat tegar (firmware) UEFI tentang lokasi pemuat boot (boot loader) openSUSE. Fitur kernel Linux hulu yang menggunakan area penyimpanan UEFI untuk menyimpan informasi boot dan kres (pstore) telah dinonaktifkan secara bawaan. Namun demikian, disarankan untuk memasang pemutakhiran perangkat tegar (firmware) apa pun yang direkomendasikan oleh vendor perangkat keras.

Bersama dengan spesifikasi EFI/UEFI, gaya partisi baru telah hadir: GPT (GUID Partition Table). Skema baru ini menggunakan pengidentifikasi unik global (nilai 128-bit ditampilkan dalam 32 digit heksadesimal) untuk mengidentifikasi lebih banyak perangkat dan tipe partisi.

Selain itu, spesifikasi UEFI juga memungkinkan partisi MBR (MS-DOS) lama. Boot loader Linux (ELILO atau GRUB 2) mencoba membuat GUID secara otomatis untuk partisi lama tersebut, dan menulisnya ke perangkat tegar (firmware). GUID seperti itu dapat sering berubah, menyebabkan penulisan ulang di perangkat tegar (firmware). Penulisan ulang terdiri dari dua operasi berbeda: Menghapus entri lama dan membuat entri baru yang menggantikan entri pertama.

Perangkat tegar (Firmware) modern memiliki pengumpul sampah yang mengumpulkan entri yang dihapus dan membebaskan memori yang disediakan untuk entri lama. Masalah muncul ketika perangkat tegar (firmware) yang salah tidak mengumpulkan dan membebaskan entri tersebut. Ini dapat mengakibatkan sistem yang tidak dapat boot.

Untuk mengatasi masalah ini, konversi partisi MBR lama ke 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.

Pada openSUSE Leap, kernel bawaan (default kernel) dibagi ke dalam tiga sub-paket: kernel-default, kernel-default-extra, dan kernel-default-optional. Hal yang sama, kernel-preempt juga dibagi ke dalam kernel-preempt, kernel-preempt-extra, dan kernel-preempt-optional. Paket -optional berisi modul pilihan hanya untuk openSUSE Leap. Paket -extra berisi modul yang tidak didukung. Mode kernel preemption dapat dikontrol dengan mengatur parameter kernel preempt=voluntary melalui baris perintah. Parameter ini bekerja pada kernel-default.

Kalau Anda menggunakan varian kernel, pastikan semua RPM yang dibutuhkan untuk kasus Anda dipasang.

Paket usang masih dikirimkan sebagai bagian dari distribusi tetapi dijadwalkan untuk dihapus versi openSUSE Leap berikutnya. Paket-paket ini ada untuk membantu migrasi, tetapi penggunaannya tidak disarankan dan mereka mungkin tidak menerima pemutakhiran.

Untuk memeriksa apakah paket yang dipasang tidak lagi dirawat: Pastikan lifecycle-data-openSUSE dipasang, lalu gunakan perintah:

zypper lifecycle

Paket yang dihapus tidak dikirim sebagai bagian dari distribusi lagi.

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 dan yang lebih baru memungkinkan pemeriksaan tanda tangan modul kernel untuk driver pihak ketiga (CONFIG_MODULE_SIG=y). Ini adalah tindakan keamanan penting untuk menghindari kode yang tidak terpercaya berjalan di dalam kernel.

Ini dapat mencegah modul kernel pihak ketiga dimuat jika UEFI Secure Boot diaktifkan. Kernel Module Packages (KMPs) dari repositori resmi openSUSE tidak terpengaruh, karena modul yang dikandungnya ditandatangani dengan kunci openSUSE. Pemeriksaan tanda tangan memiliki perilaku berikut:

Dimungkinkan untuk membuat sertifikat khusus, mendaftarkannya ke basis data Machine Owner Key (MOK) sistem, dan menandatangani modul kernel yang dikompilasi secara lokal dengan kunci sertifikat ini. Modul yang ditandatangani dengan cara ini tidak akan diblokir atau menyebabkan peringatan. Lihat https://en.opensuse.org/openSUSE:UEFI.

Karena ini juga memengaruhi penggerak grafis NVIDIA, kami membahasnya dalam paket resmi kami untuk openSUSE. Namun, Anda perlu mendaftarkan kunci MOK baru secara manual setelah pemasangan untuk membuat paket baru berfungsi. Untuk instruksi tentang cara memasang penggerak dan mendaftarkan kunci MOK, lihat https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot.

Paket-paket KDE 4 tidak lagi menjadi bagian dari openSUSE Leap 15.3. Perbaharui sistem Anda ke Plasma 5 dan Qt 5. Beberapa paket Qt 4 mungkin tetap dipertahankan untuk alasan kompatibilitas. Informasi lebih lanjut, lihat 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.