Tiga tahun lalu, saya menulis artikel yang menjelaskan cara memulihkan dari boot yang gagal setelah peningkatan versi utama di Fedora. Saat itu, saya sedang bekerja dengan Fedora 25, dan tiba-tiba, saya tidak bisa lagi membuka desktop. Masalahnya ternyata adalah initramfs kereta, yang merupakan masalah yang hanya pernah saya temui sekali di masa lalu, kembali di Ubuntu, pada tahun 2009. Sejak itu, sudah sepi.
Nah, roda waktu telah mencampakkan kita kembali ke awal. Masalah yang sama terjadi lagi. Saya (agak) baru-baru ini memutakhirkan instance Fedora 29 ke Fedora 30, dan lihatlah, saya mendapati diri saya menghadapi masalah yang sama. Hampir. Saya memiliki layar hitam, dan pesan yang mengatakan:Tidak dapat membuka akses ke konsol, akun root terkunci. Pada titik ini, mencoba melakukan apa pun tidak membuahkan hasil apa pun. Saya hanya bisa reboot. Saya memang mencoba kernel lain, dan ini membantu - saya membuka desktop saya. Meskipun masalahnya tampaknya serupa, saya harus menggunakan cara yang sedikit berbeda untuk memperbaikinya.
Gejala masalah lebih detail
Saya menemukan diri saya cukup bingung dengan kurangnya alat diagnostik yang dapat diakses atau lingkungan yang dapat digunakan di mana saya dapat memecahkan masalah. Harus mem-boot ulang berarti kehilangan informasi yang mungkin berharga. Paling tidak, saya bisa boot ke kernel lain, yang berarti saya punya sesuatu untuk dikerjakan.
Di kernel 1 terbaru, saya pertama kali mencoba mengikuti saran saya sendiri dari dua tahun lalu, tetapi perintah systemctl status boot-efi.mount tidak menunjukkan apa pun yang berguna. Saya selalu bingung dengan betapa rapuhnya, kompleksnya dan tidak ramahnya kerangka kerja boot baru dan modern ini. Edisi sebelumnya mendorong saya untuk menulis artikel Kemajuan saya melalui kompleksitas, dan kesimpulannya masih berlaku, bertahun-tahun kemudian.
Kendala paling sederhana adalah ketersediaan informasi di bawah /var/log. Kembali pada hari-hari awal yang baik, Anda biasanya akan menemukan yang berikut di sana:syslog/messages, boot, boot lama dan log kernel. Ini adalah file teks yang dapat Anda periksa dengan mudah dan instan dengan cat, lebih sedikit, apa pun.
Di Fedora, Anda mendapatkan beberapa - tetapi tidak semua file ini. Misalnya, boot.log ada, tetapi kemudian:
sudo less boot.log
"boot.log" mungkin berupa file biner. Tetap melihatnya?
Lucunya, ini ADALAH file teks (dengan beberapa karakter aneh), dan Anda sebenarnya dapat menampilkannya dengan cat. Namun file ini tidak memberikan informasi berguna yang akan membantu saya menemukan masalahnya.
Saya kemudian menghabiskan sedikit lebih banyak waktu membaca opsi yang berbeda untuk journalctl, dan itu memberi Anda opsi untuk melihat log boot sebelumnya. Anda dapat melakukan ini dengan memberikan nilai integer negatif untuk melihat log lama. Ini tidak terlalu intuitif, tetapi setidaknya itu memberi saya apa yang saya butuhkan, meskipun pada prinsipnya saya membenci ide format log biner. Anda telah melihat ini baru-baru ini ketika saya men-debug masalah laptop yang rusak. Tema serupa.
journalctl --boot=-1
Di sini, saya menelusuri garis, mencari kesalahan. Meskipun systemctl thingie tidak membantu sebelumnya, dengan perintah ini, saya akhirnya menemukan masalah boot kritis:
11 Juli 13:55:07 tester systemd[1]:Memasang /boot/efi...
11 Juli 13:55:07 penguji mount[899]:memasang:/boot/efi:jenis sistem file tidak dikenal 'vfat '.
11 Juli 13:55:07 penguji systemd[1]:boot-efi.mount:Proses pemasangan keluar, kode=keluar, status=32/n/a
11 Juli 13:55:07 penguji systemd[1]:boot-efi.mount:Gagal dengan hasil 'kode-keluar'.
11 Juli 13:55:07 penguji systemd[1]:Gagal me-mount /boot/efi.
11 Juli 13:55:07 penguji systemd[1]:Ketergantungan gagal untuk Sistem File Lokal.
11 Juli 13:55:07 penguji systemd[1]:local-fs.target:Pekerjaan local-fs.target/start gagal dengan hasil 'ketergantungan'.
11 Juli 13:55:07 penguji systemd[1]:local-fs.target:Memicu ketergantungan OnFailure=.
Sangat mirip dengan apa yang terjadi tiga tahun lalu. Jadi sekali lagi, kami tampaknya memiliki initramf yang dirakit dengan buruk, yang tampaknya terlalu sering terjadi untuk selera saya. Plus, itu berkorelasi dengan peningkatan versi. Saya bertanya-tanya apa yang bisa begitu rumit tentang modul FAT32, tapi kemudian, itu pertanyaan untuk orang lain. Sejauh menyangkut file initramfs, saya memiliki yang berikut di bawah /boot:
ls -ltr initramfs*
-rw-------. 1 root root 73443963 19 Mei 2018 initramfs-0-rescue-efe3eec4bb6646fe864735812f4d094b.img
-rw-------. 1 root root 22953495 2 Apr 15:54 initramfs-5.0.4-200.fc29.x86_64.img
-rw-------. 1 root root 22961687 20 Mei 13:11 initramfs-5.0.16-200.fc29.x86_64.img
-rw-------. 1 root root 23015208 20 Mei 21:17 initramfs-5.0.16-300.fc30.x86_64.img
Yang terakhir adalah pelakunya, sedangkan yang sebelumnya (di atas) bekerja dengan baik. Apa pun yang terjadi selama pembaruan membuat initramf kedua rusak, tanpa modul vfat untuk memungkinkan pemasangan sistem file yang benar. Karena penasaran, saya memutuskan untuk mengekstrak gambar untuk melihat perbedaannya - yang mengkonfirmasi kecurigaan saya. Sekali lagi, ini bukan latihan yang paling sepele, karena Anda tidak dapat menggunakan zcat dan cpio untuk mengekstrak file initarmfs seperti sebelumnya, Anda memerlukan kombo yang lebih kompleks:
/usr/lib/dracut/skipcpio initramfs-"version".img | zcat | cpio -id
Solusi
Nah, Anda memiliki beberapa pilihan di sini. Satu, jika Anda memiliki salinan kedua Fedora di kotak yang sama, dan itu berfungsi, maka Anda dapat menyalin file initramfs-nya dan menggunakannya, seperti yang saya lakukan di Ubuntu dulu. Ini bukan pilihan sepele, tetapi jika Anda memilikinya, Anda beruntung!
Jika tidak, maka kernel lama akan membantu - seperti yang mereka lakukan dalam skenario saya. Kemudian, Anda dapat menjalankan pembaruan sistem atau membuat ulang file initramfs secara manual. Anda dapat membaca artikel boot lambat Ubuntu saya untuk detail tentang cara melakukan ini. Jika Anda tidak dapat boot ke kernel lain, dan Anda tidak memiliki instance Linux lain di host, maka opsi terakhir Anda adalah menggunakan sesi langsung dan kemudian melakukan pemulihan di sana - atau menginstal ulang.
Kesimpulan
Saya terkejut dan agak kecewa dengan situasi ini - semuanya. Kesalahan itu sendiri, ketidakmampuan untuk men-debug langsung, fakta ini terjadi pada saya setelah peningkatan Fedora (lagi), fakta bahwa saya berakhir dengan distro yang tidak dapat di-boot setelah aktivitas sistem biasa, kompleksitas keseluruhan systemd. Semua ini membuatku merasa tidak nyaman.
Pada tahun 2020, dunia teknologi tidak lagi abstrak, kuat, atau tangguh dibandingkan sepuluh tahun yang lalu. Sebaliknya, kesalahan terus terjadi, dan ketika kesalahan itu terjadi, ekosistem di sekitarnya jauh lebih sulit untuk digunakan dan dikerjakan daripada di masa lalu. Ini membuat pemecahan masalah dan pemecahan masalah lebih membuat frustrasi. Jadi ya, saya memperbaikinya, dan mungkin itu yang penting, tapi kemudian tidak, bukan itu yang penting. Pengalaman pengguna yang mulus adalah tujuan akhir. Sayangnya, hari demi hari, desktop Linux perlahan-lahan menjauh dari misi mulia ini, menjadi semakin tidak relevan dalam skema yang lebih besar. Anyway, dari sisi teknis, semoga artikel ini bermanfaat. Hati-hati.