Ia adalah 2:17 AM dan alat kelui dimatikan. Salah satu pelayan anda tidak menjawab SSH. Anda periksa konsol — mesin dihidupkan, kipas berputar, dan kemudian ia hanya duduk di sana. Tiada gesaan log masuk. Tiada rangkaian. Panik kernel, gesaan GRUB atau dinding teks yang menatal melepasi terlalu cepat untuk dibaca.
Inilah saat di mana panik memutuskan sama ada anda membetulkan pelayan dalam masa dua puluh minit atau membina semula dalam tempoh dua hari. Pelayan yang tidak akan boot jarang sekali menjadi pelayan yang mati. Ia hampir selalu kegagalan konfigurasi — baris `/etc/fstab` yang buruk, pemuat but rosak, sistem fail akar penuh atau kemas kini kernel yang memecahkan pemacu. Kesemuanya boleh dipulihkan, dan kebanyakannya boleh dipulihkan tanpa memasang semula apa-apa.
Buku permainan ini menelusuri empat kelas kegagalan yang sebenarnya anda akan lakukan, arahan yang tepat untuk pulih daripada setiap kelas, dan minda yang memisahkan sysadmin yang tenang daripada binaan semula 4 AM. Pastikan ia ditanda halaman — anda akan memerlukannya pada masa yang paling teruk.
Peraturan Sifar: Baca Log Sebelum Anda Menyentuh Apa-apa
Satu-satunya kesilapan terbesar semasa kegagalan but ialah improvisasi. Anda mula menaip arahan yang anda separuh ingat, dan anda mengubah pembetulan sepuluh minit menjadi sistem fail yang rosak. Tahan keinginan itu. Linux menulis tepat apa yang salah, dan dalam kebanyakan kes jawapannya sudah ada pada cakera.
Jika mesin but cukup jauh untuk mencapai cangkang — walaupun cangkang kecemasan — anda mempunyai semua yang anda perlukan. Penampan cincin kernel menyimpan satu but pada satu masa, tetapi `journalctl` menyimpan sejarah berterusan merentas but semula secara lalai pada kebanyakan pengedaran moden:
```bash
journalctl -b # but ini
journalctl -b -1 # but PREVIOUS (gagal).
journalctl -p err -b -1 # hanya ralat daripada but yang gagal
dmesg | ekor -50 # penimbal cincin kernel, jika journald tidak tersedia
```
Bendera `-b -1` ialah arahan wang. Apabila pelayan ranap semasa but dan anda berjaya masuk semula melalui mod penyelamat atau kernel yang terkenal, `journalctl -b -1` memainkan semula gagal but baris demi baris. Sembilan kali daripada sepuluh baris terakhir sebelum pembekuan menamakan penyebabnya: tamat masa menunggu cakera, pelekap yang gagal, modul kernel yang hilang atau pembunuhan di luar ingatan.
Jika mesin jatuh ke gesaan GRUB dan tidak pernah mencapai kernel sama sekali, maka masalahnya adalah di hulu OS — dan anda boleh melangkau terus ke bahagian seterusnya.
Kegagalan 1: Gesaan Menyelamat GRUB
Anda melihat ini dan hati anda tenggelam:
```
penyelamat grub>
```
Ini bermakna GRUB menemui kodnya sendiri tetapi kehilangan laluan ke konfigurasi dan modulnya. Punca klasik ialah perubahan jadual partition, cakera yang disusun semula atau `/boot` yang dialihkan. GRUB tidak rosak — ia tidak tahu di mana rumahnya.
Pemulihan adalah tarian tiga perintah. Mula-mula, cari partition yang memegang `/boot`:
```
ls
ls (hd0,gpt2)/
ls (hd0,gpt2)/boot/grub
```
`ls` GRUB memberitahu anda sama ada partition boleh dibaca dan apa yang ada padanya. Apabila anda menemui yang mengandungi `grub/` dan imej kernel anda, beritahu GRUB tempat untuk melihat:
```
set root=(hd0,gpt2)
tetapkan awalan=(hd0,gpt2)/boot/grub
insmod biasa
biasa
```
Langkah `insmod normal` memuatkan modul biasa supaya GRUB boleh menghuraikan konfigurasi sebenar dan menunjukkan menu kepada anda. Dari sana sistem biasanya but, dan anda boleh membaiki GRUB secara kekal sebaik sahaja anda log masuk:
```bash
sudo grub-install /dev/sda
sudo update-grub # Debian/Ubuntu
sudo grub2-mkconfig -o /boot/grub2/grub.cfg # keluarga RHEL
```
Jika anda mempunyai USB atau ISO penyelamat, butnya dan menjalankan kedua-dua arahan tersebut di dalam chroot ialah laluan yang lebih dipercayai. Boot dari cakera untuk membetulkan cakera adalah mungkin, tetapi ia adalah penyelesaian, bukan pembaikan.
Kegagalan 2: Mod Kecemasan Kerana `/etc/fstab` yang Buruk
Ini adalah panggilan "ia tidak akan boot" yang paling biasa dan paling mudah untuk diperbaiki. Anda mengedit `/etc/fstab`, but semula dan kini mesin jatuh ke mod kecemasan dengan mesej seperti:
```
Kebergantungan gagal untuk /mnt/data.
```
Systemd memasang segala-galanya dalam `/etc/fstab` sebelum ia menganggap but selesai. Jika satu masukan menghala pada peranti yang tidak wujud lagi — cakera USB yang anda cabut plag, UUID yang berubah selepas format semula, kesilapan menaip dalam laluan pelekap — keseluruhan but dianggap gagal, walaupun sistem fail akar adalah baik.
Untuk membetulkannya, anda memerlukan akar yang boleh ditulis. Mod kecemasan biasanya memasang `/` baca sahaja, jadi pasang semula:
```bash
mount -o remount,rw /
```
Kemudian buka `/etc/fstab` dan lihat entri yang gagal. Satu-satunya diagnostik yang paling berguna adalah untuk mengesahkan bahawa setiap UUID sebenarnya wujud pada sistem:
```bash
lsblk -f # menyenaraikan semua peranti blok dengan UUID dan titik pelekap
blkid # penyenaraian UUID / JENIS mentah
```
Bandingkan UUID dalam `/etc/fstab` dengan output ini. Ketakpadanan adalah jawapan anda. Betulkan UUID, atau ulas baris dengan `#` di hadapan jika pelekap adalah pilihan, kemudian but semula. Untuk sistem fail rangkaian dan media boleh tanggal, sentiasa tambahkan pilihan `nofail` supaya peranti yang hilang tidak boleh menyekat but lagi:
```
UUID=xxxx-xxxx /mnt/data ext4 lalai,tidak gagal 0 2
```
Satu perkataan itu, `nofail`, menghalang keseluruhan kelas 3 AM gangguan. Tambahkannya pada setiap pelekap bukan akar pada setiap pelayan yang anda urus. Ia adalah insurans termurah dalam pentadbiran sistem.
Kegagalan 3: Sistem Fail Root Telah Penuh
Sistem fail akar penuh menghasilkan beberapa gejala yang paling pelik dalam Linux. Perkhidmatan gagal dimulakan, log masuk hang, sudo enggan dijalankan, dan kadangkala mesin tidak mencapai gesaan log masuk sama sekali kerana systemd tidak boleh menulis keadaannya. Ia kelihatan seperti rasuah yang dahsyat. Ia hampir selalu hanya fail log.
Sebaik sahaja anda berada dalam mod menyelamat atau kecemasan, sahkan tekanan:
```bash
df -h /
du -xh / --max-depth=1 2>/dev/null | sort -rh | kepala -15
```
Perintah kedua itu berjalan di peringkat teratas sistem fail dan mengisih direktori mengikut saiz, yang biasanya cukup untuk mencari pesalah dalam beberapa saat. Suspek biasa ialah `/var/log`, `/var/cache`, kernel lama dalam `/boot`, dan log aplikasi lari dalam `/var/lib`. Pengguna docker juga harus menyemak `/var/lib/docker` —
```bash
sistem docker df
prune sistem docker -a --volume
```
Sebaik sahaja anda kembali pada gesaan dalam mod biasa, potong daripada padam fail log supaya pengendalian fail kekal sah:
```bash
truncate -s 0 /var/log/huge-file.log
```
Kemudian menyerang punca utama. Jika `/var/log` sedang mengisi partition kecil, dayakan dasar `logrotate` atau alihkan log ke volumnya sendiri. Jika `/boot` penuh, alih keluar kernel lama dengan arahan autoremove pengurus pakej anda. Sistem fail yang diisi dua kali adalah masalah reka bentuk, bukan kemalangan.
Kegagalan 4: Kernel Panik Selepas Kemas Kini
Anda menampal kernel, but semula, dan kini mesin panik sebelum ia sampai ke ruang pengguna. Ini adalah kegagalan yang paling menakutkan orang ramai — OS tidak pernah mendapat peluang untuk bermula. Tetapi ia juga merupakan salah satu yang paling boleh dipulihkan, kerana kernel lama masih dalam cakera.
Pada menu GRUB, pilih "Pilihan lanjutan untuk Ubuntu" (atau yang setara) dan but versi kernel sebelumnya. GRUB menyimpan beberapa kernel terakhir yang dipasang untuk alasan ini. Sebaik sahaja anda menggunakan kernel lama, anda boleh baiki yang baharu atau gulung semula dengan bersih:
```bash
uname -r # sahkan kernel yang anda but
dpkg -l | grep linux-image # Debian/Ubuntu — senaraikan kernel yang dipasang
rpm -qa | grep kernel # keluarga RHEL
```
Jika kernel baharu memecahkan pemacu yang bergantung kepada pelayan anda — pengawal storan, penyesuai rangkaian atau modul proprietari — sematkan kernel yang berfungsi dan kecualikan pakej yang rosak daripada naik taraf automatik sehingga pembaikan tiba. Kemudian jadualkan tetingkap penyelenggaraan yang betul untuk menyiasat dan bukannya berjudi lagi.
Alat yang lebih berat, dan yang patut diketahui, ialah pembaikan rescue-chroot. But mana-mana media Linux secara langsung, kenal pasti peranti root anda dan lekapkannya terus:
```bash
lekapkan /dev/mapper/vg0-root /mnt
mount /dev/sda2 /mnt/boot
untuk d dalam dev proc sys run; lakukan mount --bind /$d /mnt/$d; selesai
chroot /mnt /bin/bash
```
Kini anda menjalankan sistem rosak seolah-olah anda telah log masuk ke dalamnya, dengan akses penuh kepada pengurus pakejnya, alatan initramfsnya dan pemuat butnya. Anda boleh memasang semula kernel, membina semula initramfs, membaiki GRUB atau membetulkan kesilapan kesilapan fstab dari luar. Teknik tunggal ini telah menyelamatkan lebih banyak pelayan yang tidak boleh diboot daripada mana-mana alat lain dalam kit.
Minda Pemulihan: Pencegahan Mengalahkan Kepahlawanan
Setiap pemulihan yang anda lakukan adalah pukulan amaran. Pelayan yang turun dua kali adalah yang tiada siapa yang bertanya mengapa kegagalan pertama berlaku. Tiga tabiat menghapuskan kebanyakan kegagalan but sebelum ia berlaku:
- Jangan sekali-kali but semula pelayan yang anda tidak boleh capai secara fizikal tanpa menyemak `fstab` terlebih dahulu. Sahkan UUID dengan `lsblk -f` dan uji pelekap baharu dengan `mount -a` sebelum but semula, bukan selepas. `mount -a` menangkap entri buruk semasa mesin masih sihat.
- Simpan syot kilat atau sekurang-kurangnya inti yang diketahui bagus. Gambar LVM, Btrfs dan ZFS membolehkan anda mengembalikan perubahan buruk dalam beberapa minit. Jika anda menggunakan ext4 biasa, kernel sebelumnya yang berada dalam `/boot` ialah gambar pilihan terakhir anda. Jangan biarkan autoremove memadamkannya.
- Pantau ruang cakera dan kesihatan SMART, bukan hanya CPU. Makluman ramalan pada 85 peratus penuh bernilai lebih daripada sebarang kemahiran pemulihan. Ruang cakera, keletihan inod dan pemacu yang gagal menyebabkan lebih banyak pelayan tidak boleh boot daripada pepijat perisian.
Tulis buku permainan dan latih tubi. Sysadmin yang kekal tenang pada pukul 2 pagi tidak lebih bijak daripada mereka yang panik — mereka baru sahaja membaca log, melihat ralat dan mengenali corak sebelum ini.
Kesimpulan
Pelayan yang tidak akan boot terasa seperti lantai telah tercicir. Ia jarang berlaku. Linux moden adalah berdaya tahan dan sangat mengagumkan: but yang gagal dilog, kernel lama masih wujud, data masih utuh, dan salah konfigurasi berada dalam fail teks menunggu untuk diperbetulkan.
Baca log dahulu. But kernel sebelumnya. Lekapkan semula baca-tulis akar. Betulkan satu baris yang buruk. Sembilan daripada sepuluh kegagalan mengikut laluan yang tepat itu, dan setiap satu daripadanya adalah lebih pantas daripada pemasangan semula — jika anda mengekalkan fikiran anda dan mengikut buku main. Toskan bateri kelui, bukan mesin kopi.
Infografik: Apabila Pelayan Linux Anda Tidak Akan But — Buku Main Pemulihan
💬 0 Comments