Ingat, saya memberi tahu Anda tentang laptop yang rusak? Nah, mari kita uraikan, ya. Saya melakukan beberapa pengujian dengan perangkat lunak pencitraan &pemulihan, dan setelah saya selesai, saya ingin melihat seberapa baik prosesnya. Tidak baik, ternyata. GRUB ada di sana, tetapi pada awalnya tidak ada entri di menu yang berfungsi. Setelah saya segera memperbaikinya, saya melihat bahwa Windows 10 tidak mau boot, dan tidak mau memperbaiki otomatis, dan setengah distro pada sistem (dari total delapan) dalam pengaturan multi-boot juga tidak akan mulai , masuk ke mode darurat. Kami sedang membicarakan bagian penuh dari distro, silakan pilih.
Sekarang, pemulihan GRUB cukup rumit - tidak ada metode yang saya pikirkan berhasil, dan saya akhirnya menginstal distro uji hanya untuk mendapatkan bootloader yang dikonfigurasi dengan benar. Kemudian, saya memulai salah satu distro yang DID berfungsi, dan melihat tidak ada kehilangan data. Semuanya ada di sana, semua partisi waras dan utuh, dan file berada di tempat yang tepat, termasuk Linux dan Windows. Dalam artikel ini, saya ingin menunjukkan kepada Anda bagaimana saya mengatasi masalah ini, dan bagaimana saya memperbaikinya - dan dalam sekuelnya, kita akan melakukan hal yang sama untuk Windows 10. Latihan yang bermanfaat. Ikuti saya.
Masalah lebih detail
Saya melakukan latihan berikut dengan neon sebagai starter, tetapi ini berlaku untuk hampir semua distro sejak sekitar 2011-2012. Jadi yang terjadi adalah, KDE neon mulai booting dan kemudian masuk ke shell darurat. Saya diberitahu oleh sistem bahwa saya harus menjalankan journalctl -xb untuk melihat log startup dan mencari tahu apa yang salah. Sekarang, ini bukan pertama kalinya kami mengalami ini. Saya menangani masalah serupa dengan Fedora belum lama ini.
Tapi di sini, masalahnya sedikit berbeda. Ya, log boot menunjukkan masalah dengan /boot/efi, tetapi mengapa ini terjadi berasal dari masalah lain. Jika Anda bertanya-tanya bagaimana saya memperoleh dan menyalin log di sesi darurat (jika Anda memerlukan sesuatu seperti itu), Anda dapat menyalin konten ke file dan kemudian mengambilnya melalui sesi langsung (dengan redirect> atau menggunakan perintah tee ), atau setelah Anda memperbaiki masalah, Anda dapat membuang log minus satu terakhir dengan journalctl -x --boot=-1. Itu teknologi modern untuk Anda.
06 Desember 12:57:09 penguji systemd[1]:Ketergantungan gagal untuk Pemeriksaan Sistem File pada /dev/disk/
-- Perihal:Unit systemd-fsck@dev-disk-by\x2duuid-641C\x2d39CE. layanan gagal
-- Ditetapkan-Oleh:systemd
-- Dukungan:http://www.ubuntu.com/support
--
-- Unit systemd-fsck@ dev-disk-by\x2duuid-641C\x2d39CE.service telah gagal.
--
-- Hasilnya adalah HASIL.
06 Des 12:57:09 penguji systemd[1]:Ketergantungan gagal untuk /boot/efi.
-- Perihal:Unit boot-efi.mount telah gagal
-- Ditetapkan-Oleh:systemd
-- Dukungan:http://www.ubuntu.com/support
--
-- Unit boot-efi.mount gagal.
Solusi
Aku bertanya-tanya apa yang bisa salah. Seluruh dev-disk-by adalah petunjuk besar. Ingat ketika saya menunjukkan kepada Anda cara memperbaiki masalah boot yang lambat ketika partisi swap UUID diubah? Ini tampak seperti itu, kecuali /boot/efi sangat penting dalam proses startup sistem.
Saya membuka /etc/fstab, dan memang, UUID yang terdaftar untuk partisi swap (dev/sda10) TIDAK benar. File tersebut bahkan memiliki komentar yang mengatakan entri partisi dulunya adalah nomor perangkat, dan kemudian diubah menjadi UUID yang dianggap "modern" dan "membantu" yang hanya menyebabkan masalah.
# swap aktif /dev/sda10 selama instalasi
UUID=8140c8d0-1e33-42c1-8c3c-828449adfe08 none swap swap 0 0
Saya mengubah hal-hal UUID ke /dev/sda10, reboot, dan semuanya bagus!
Perintah yang Anda perlukan untuk melakukan ini
Sekarang, mari kita perlambat sebentar. Jadi ini adalah bagaimana Anda dapat memverifikasi apakah sistem Anda menggunakan nomor atau pengidentifikasi perangkat yang benar. Pertama, Anda dapat membuat daftar partisi dengan fdisk -l. Perintah ini akan memberi Anda gambaran umum tentang semua partisi yang berbeda dan sistem filenya. Dengan cara ini Anda bisa mendapatkan pemahaman dasar tentang sistem Anda. Khususnya, Anda memerlukan partisi root (/), Anda mungkin memiliki partisi /boot terpisah, yang sering terjadi pada sistem UEFI, Anda mungkin menggunakan /home terpisah, dan Anda mungkin juga memiliki partisi swap opsional dan terpisah. Ini akan ditandai dengan nomor perangkat, seperti /dev/sda2, /dev/sda8, dll.
Masalahnya dimulai pada bagaimana rilis terbaru dari distribusi Linux memetakan perangkat ke /etc/fstab, file yang diuraikan pada startup sistem untuk informasi tentang perangkat mana yang harus dipasang secara otomatis. Di masa lalu, perangkat direferensikan seperti fdisk, dev/XdYZ, di mana X akan menunjukkan jenis disk (biasanya huruf h atau s), Y akan menjadi huruf perangkat (seperti yang diperintahkan oleh BIOS sistem Anda, misalnya a, b atau serupa), dan Z akan menjadi nomor partisi. Misalnya, /dev/sdb3 berarti partisi ketiga pada disk kedua dengan jenis koneksi SATA/SCSI/PCI-E.
Memang, distribusi "modern" menggunakan UUID - ini adalah string angka dan huruf yang tidak memiliki arti manusia, seperti a45f-cc9a, yang dimaksudkan untuk memetakan partisi secara unik, jadi jika urutan disk entah bagaimana berubah, sistem masih bisa boot. Mungkin masuk akal di perusahaan, tetapi di lingkungan rumah, ini benar-benar tidak masuk akal - seperti hampir SETIAP solusi "modern", seperti systemd, konvensi penamaan antarmuka jaringan baru, alat manajemen jaringan baru, dan sebagainya. Lebih lanjut tentang filsafat nanti.
Sekarang, jika Anda memiliki UUID yang salah yang tercantum di /etc/fstab, sistem tidak dapat memasang partisi ini - mekanismenya sangat tidak stabil, karena tidak memiliki kemampuan untuk memeriksa, mencari, atau memulihkan konfigurasi yang rusak - Anda mungkin berakhir dengan konfigurasi yang tidak dapat di-boot sistem. Situasi ini juga tidak mungkin untuk memecahkan masalah dengan cepat, karena string UUID sama sekali tidak berguna bagi manusia.
Anda dapat memverifikasi daftar UUID perangkat dengan perintah blkid, misalnya:
blkid
/dev/mapper/sda3_crypt:UUID="TpZGKB-31Lq-U1Ap-BZJCcX" TYPE="LVM2_member"
/dev/mapper/kubuntu--vg-root:UUID="dcae17fd-7cfe -c0b721e" TYPE="ext4"
Anda perlu membandingkan secara visual dan kemudian mencari tahu apa yang hilang. Kemudian perbaiki /etc/fstab secara manual.
Modern, Anda tetap menggunakan kata itu ...
Kenyataan sederhananya adalah sebagai berikut:Saya telah bekerja dengan Linux selama lebih dari 15 tahun. Pada titik tertentu dalam hidup, saya menangani pengaturan HPC yang indah dengan sekitar 50.000 server fisik yang didistribusikan di sekitar 40 pusat data. Saya memiliki bagian saya dalam bisnis dan sistem rumah, dengan teknologi lama dan baru.
Saya telah menemukan sistem yang rusak sebagian besar sejak kami pindah dari BIOS lama + MBR + GRUB + init ke UEFI + GPT + GRUB2 + systemd yang baru. Tidak ada yang ajaib, tangguh, atau lebih baik dalam solusi ini. Mereka memang memecahkan beberapa batasan teknis nyata dalam industri, benar. Tetapi mereka juga memperkenalkan pengaturan yang jauh lebih kuat yang jauh lebih sulit untuk di-debug dan dipecahkan oleh manusia. Misalnya, saya TIDAK PERNAH melihat sistem rusak karena urutan disk menjadi kacau. Tetapi saya telah melihat BANYAK contoh sistem yang rusak karena penggunaan UUID alih-alih notasi nomor perangkat sederhana.
Memperbaiki GRUB adalah hal yang sepele menyalin 512 byte data di sana-sini dalam kasus terburuk, dan mengedit file teks. Sekarang, hampir agama ilmiah mengakses antarmuka baru, bekerja dengan EFI dan semacamnya. Memperbaiki boot Linux yang rusak bukanlah masalah, dan sekarang, saya harus mengurai log biner ke dalam teks, dan kemudian mencari tahu mengapa sistem saya mungkin miring, hanya untuk menemukan itu semua karena saya terpaksa menggunakan "solusi " untuk masalah yang tidak ada. Misalnya soal UUID. Masalah ip versus ifconfig. Mengapa enp0s0, atau apa pun pengidentifikasi kartu jaringan baru, lebih baik atau lebih pintar atau lebih intuitif daripada eth0? Dulu logis, ethernet =eth.
Apa skenario di mana pengguna rumahan harus sering menambah atau menghapus hard disk masuk dan keluar dari kotak mereka atau bermain dengan pengaturan BIOS? Ini bukan. Jadi mengapa sistem rumah datang dengan solusi yang tidak memadai? Karena Linux pada dasarnya tidak dimaksudkan untuk menjadi solusi rumahan, dan saya merasa seperti orang bodoh.
Dan ini baru permulaan. Seiring berjalannya waktu, kita akan memiliki lebih banyak abstraksi, abstraksi, abstraksi, otomatisasi, omong kosong yang dioptimalkan mesin, dan Anda harus mengandalkan dan bergantung pada belas kasihan entitas apa pun yang mengeluarkan Apapun sebagai Layanan terbaru mereka. Akan tiba saatnya ketika semua omong kosong ini meledak, karena tidak dapat di-debug. Atau akan diserahkan kepada mesin untuk mengelola sendiri, menggunakan protokol jelek mereka yang tidak pernah dimaksudkan untuk dilihat atau dialami manusia sejak awal. Berbicara tentang desain yang buruk.
Kesimpulan
Pertama, saya harap Anda menemukan artikel ini bermanfaat. Dalam kebanyakan kasus di mana sistem Linux tidak bisa boot, Anda mungkin menghadapi masalah dengan, yah, ada hubungannya dengan /boot atau /boot/efi. Jika itu terjadi, Anda harus agak percaya diri membaca log, dan kemudian mencoba mencari tahu apakah Anda memiliki komponen yang hilang atau rusak, seperti yang saya tunjukkan dengan bug initrd dan initramfs (ditautkan di atas), atau konfigurasi sistem salah , dan mencoba merujuk sumber daya yang tidak ada. Dalam kasus kami, seperti masalah boot yang lambat, penggunaan UUID palsu untuk partisi adalah penyebabnya.
Ini harus diselesaikan pada tingkat sistem. Tetapi seperti yang telah saya catat berkali-kali sebelumnya, validasi bukanlah hal yang penting di Linux. Pengembang melakukan pekerjaan mereka dan melanjutkan. Tidak ada yang repot-repot memikirkan gambaran yang lebih besar, tentang filsafat. Tapi itu pemikiran perangkat lunak:fungsi -> keluaran. Tidak ada yang peduli apa yang hidup di luar fungsi dan merangkum fungsionalitas.
Sistem yang kuat sebenarnya akan memeriksa perangkat dan sistem file yang ada dan mencoba mencari tahu apakah ada masalah dalam konfigurasi. Sistem yang kuat akan memiliki cadangan file penting dan mencoba merujuknya. Sistem yang kuat akan mencoba sesuatu dalam beberapa cara berbeda dan menghubungkan berbagai hal sebelum gagal dengan cara yang berarti. Tak satu pun dari itu ada saat ini, tidak di Linux atau sistem lain, karena lebih murah untuk memelihara sekelompok teknisi yang buruk daripada menciptakan mekanisme penyembuhan diri yang cerdas. Dan jika itu terjadi pada Anda di rumah Anda, Anda hanya jaminan. Jadi ketika orang berbicara tentang kebebasan dan sumber terbuka, mereka berbicara tentang hal yang salah. Apa gunanya open-source jika digunakan untuk mengembangkan solusi yang dikaburkan? Saya sedih. Aku harus menangis.