Linux 7.3 di Fedora: Mengapa Kernel, Modul, dan Initramfs Harus Cocok

Kompilasi Linux 7.3 menghasilkan kernel image, tetapi file itu hanya salah satu bagian yang dibutuhkan Fedora untuk boot. Pada instalasi Fedora umumnya, proses boot juga bergantung pada modul kernel, initramfs yang dibuat untuk release yang tepat, dan entri boot yang menunjuk ke artefak tersebut. Jika versinya tidak cocok, kernel yang berhasil dikompilasi sekalipun bisa gagal me-mount root filesystem.

Masalah ini muncul ketika memakai source upstream dari kernel.org, bukan paket kernel RPM Fedora. Instalasi paket Fedora biasanya mengoordinasikan beberapa artefak boot sekaligus. Dalam build upstream manual, kesesuaian itu harus dijaga sendiri. Contoh berikut berlaku untuk Fedora x86_64 biasa dengan GRUB dan grubby, bukan desktop berbasis rpm-ostree.

Kernel release menghubungkan tiga lokasi berbeda

Release yang ditampilkan make -s kernelrelease menentukan direktori modul yang akan diinstal. Nilainya harus cocok dengan release yang tertanam di kernel image serta versi kernel yang diberikan kepada dracut.

Dengan suffix -fedora-local, salah satu contoh build memiliki identitas 7.3.0-fedora-local:

/boot/vmlinuz-7.3.0-fedora-local
/usr/lib/modules/7.3.0-fedora-local/
/boot/initramfs-7.3.0-fedora-local.img
    |
    +-- Fedora boot entry references the image and initramfs

Di Fedora, /lib/modules umumnya mengarah ke lokasi modul yang sama di /usr/lib/modules. String release merupakan batas identitas, bukan sekadar bagian nama file. modprobe mencari modul sesuai release kernel yang sedang berjalan, sedangkan dracut memerlukan modul terpasang yang tepat untuk menyiapkan early userspace.

Menggunakan ulang string release untuk build yang berbeda berisiko menimpa direktori modul kernel custom sebelumnya. Suffix lokal yang unik juga membedakan kernel hasil kompilasi manual dari kernel paket Fedora. Dokumentasi build kernel Linux menganjurkan mempertahankan kernel yang berfungsi dan memakai LOCALVERSION untuk membedakan build.

Konfigurasi Fedora bukan manifest build yang langsung portabel

Menyalin /boot/config-$(uname -r) mempertahankan banyak pilihan terkait hardware, driver filesystem, dan modul yang dapat dimuat. Namun, file tersebut tidak menyertakan patch downstream Fedora ataupun file yang dirujuk oleh opsi konfigurasi khusus distribusi.

Untuk arsip source Linux 7.3 di x86_64, persiapan yang relevan adalah:

sudo dnf install -y \
  gcc make bc bison flex binutils \
  elfutils-libelf-devel openssl-devel dwarves \
  ncurses-devel perl python3 xz zstd wget tar \
  dracut grubby mokutil

mkdir -p ~/kernel-build
cd ~/kernel-build
wget https://cdn.kernel.org/pub/linux/kernel/v7.x/linux-7.3.tar.xz
tar -xf linux-7.3.tar.xz
cd linux-7.3

cp "/boot/config-$(uname -r)" .config
printf '%s\n' '-fedora-local' > localversion
./scripts/config --file .config --set-str SYSTEM_TRUSTED_KEYS ""
./scripts/config --file .config --set-str SYSTEM_REVOCATION_KEYS ""
make olddefconfig
make -s kernelrelease

Dua pemanggilan scripts/config tersebut mengosongkan path bundle sertifikat tambahan yang mungkin tersedia pada source package Fedora, tetapi tidak ada dalam tarball kernel vanilla. Keduanya tidak menandatangani kernel atau membangun kepercayaan untuk Secure Boot. Kebutuhan build lain masih bergantung pada konfigurasi, termasuk toolchain untuk fitur opsional yang diaktifkan.

make olddefconfig menetapkan nilai default untuk simbol konfigurasi baru tanpa prompt interaktif. Periksa hasil .config sebelum memakai build tersebut pada konfigurasi storage, enkripsi, atau hardware yang belum dikenal. Versi yang dicetak make -s kernelrelease harus dipakai secara konsisten pada seluruh perintah instalasi setelahnya.

Kernel image dan modul yang terpasang adalah output terpisah

Kompilasi dapat dilakukan sebagai user biasa. Hak akses lebih tinggi baru diperlukan saat menulis file ke lokasi sistem.

make -j"$(nproc)"
sudo make modules_install
KREL=$(make -s kernelrelease)

Kompilasi paralel bisa menghabiskan banyak RAM dan ruang disk. Kurangi jumlah job, misalnya menjadi -j4, jika memori tidak mencukupi.

make modules_install memasang modul yang dapat dimuat di /lib/modules/$KREL. Perintah itu sendiri tidak memasang arch/x86/boot/bzImage sebagai kernel yang bisa dipilih saat boot berikutnya. Salin kernel image serta file yang berguna untuk menelusuri konfigurasi build:

sudo install -m 0644 arch/x86/boot/bzImage "/boot/vmlinuz-$KREL"
sudo install -m 0644 System.map "/boot/System.map-$KREL"
sudo install -m 0644 .config "/boot/config-$KREL"

System.map dan konfigurasi tersimpan membantu diagnosis berikutnya; compressed kernel image adalah file yang dimuat bootloader. Modul harus berasal dari build yang sama. Modul untuk release berbeda bisa ditolak karena informasi versinya atau interface kernel tidak sesuai.

Dracut harus menargetkan release baru, bukan kernel aktif

Jika dracut --force dijalankan begitu saja sebelum reboot, perintah tersebut umumnya menargetkan kernel yang sedang berjalan. Akibatnya, initramfs milik kernel lama yang dibuat ulang, sementara Linux 7.3 belum memperoleh early userspace yang sesuai.

Berikan release kernel baru secara eksplisit:

sudo dracut --force "/boot/initramfs-$KREL.img" "$KREL"
ls -lh "/boot/vmlinuz-$KREL" "/boot/initramfs-$KREL.img"

dracut membaca modul yang terpasang untuk $KREL lalu menyusun initramfs berisi komponen yang diperlukan selama early boot. Dukungan disk controller, filesystem, enkripsi, dan volume management mungkin harus tersedia sebelum root filesystem yang sebenarnya dapat diakses. Driver yang hilang dapat menyebabkan sistem masuk emergency shell meskipun kernel sudah berhasil dimuat.

Initramfs dalam mode host-only mengikuti lingkungan storage mesin saat dibuat. Jika disk dipindahkan ke hardware lain, image yang tidak terlalu spesifik terhadap hardware mungkin perlu dibuat ulang. Dokumentasi dracut Fedora menjelaskan peran versi kernel yang ditargetkan.

Entri boot harus menunjuk pasangan yang cocok

Menyalin bzImage ke /boot tidak otomatis menjamin GRUB memiliki entri untuknya. Pada instalasi Fedora yang memakai boot loader specification, grubby dapat mendaftarkan kernel manual sambil menyalin argumen root dan kernel command line dari entri default:

sudo grubby \
  --add-kernel="/boot/vmlinuz-$KREL" \
  --initrd="/boot/initramfs-$KREL.img" \
  --title="Fedora Linux $KREL" \
  --copy-default

sudo grubby --info="/boot/vmlinuz-$KREL"

--copy-default menyalin pengaturan yang relevan dari entri default, bukan path kernel image atau initramfs lama. Ini penting pada Fedora yang menggunakan UUID filesystem, encrypted root, atau parameter boot lain. Periksa entri yang dihasilkan; jangan menganggap parameter antarmesin selalu sama.

Jangan langsung menjadikan kernel baru sebagai default. Pilih entrinya dari menu boot untuk pengujian pertama dan pertahankan kernel distribusi sebagai cadangan. Setelah boot berhasil, periksa identitas kernel aktif dan pesan kernel:

uname -r
journalctl -b -k -p warning
sudo grubby --info=ALL

Kecocokan hasil uname -r memastikan kernel mana yang sudah berjalan, tetapi tidak membuktikan seluruh driver berfungsi. Storage, jaringan, grafis, suspend, dan modul eksternal tetap perlu diuji.

Secure Boot dan pemulihan memiliki batas tersendiri

Pada sistem UEFI, periksa kebijakan yang aktif sebelum mencoba boot ke kernel unsigned:

mokutil --sb-state

Jika Secure Boot aktif, boot chain dapat menolak kernel custom yang belum ditandatangani. Penandatanganan kernel dengan key tepercaya dan pendaftaran key melalui proses MOK yang sesuai merupakan pekerjaan terpisah dari kompilasi. Penerapan tanda tangan modul kernel juga dapat menambah persyaratan kepercayaan untuk driver yang dimuat. Mengosongkan SYSTEM_TRUSTED_KEYS tidak melewati pemeriksaan tersebut; dokumentasi module signing kernel menjelaskan konfigurasi kepercayaannya.

Gejala kegagalan menunjukkan batas yang perlu diperiksa:

Kernel yang dipasang dengan cara ini bukan RPM yang dikelola dnf. Update kernel Fedora biasa tidak memelihara atau menghapus file boot hasil pemasangan manual tersebut. Pertahankan entri boot Fedora yang sudah terbukti berfungsi beserta direktori modulnya hingga kernel custom lulus pengujian pada workload sebenarnya. Cadangan itulah yang memungkinkan sistem dipulihkan jika percobaan kernel upstream gagal.