Boot Failures

Komputer menyala, logo vendor lewat, lalu semuanya berhenti — tidak ada menu GRUB, tidak ada prompt login. Kegagalan boot terasa seperti bencana total, padahal proses boot adalah rantai estafet yang sudah kita petakan di Chapter Boot Process . Setiap mata rantai yang putus meninggalkan gejala khas di layar, jadi pekerjaan kita adalah mencocokkan gejala dengan tahap yang tepat, bukan menebak. Chapter ini membuka Section Troubleshooting dengan peta lima tahap, tiga studi kasus klasik, dan skrip diagnosis mini.

Memetakan Gejala ke Lima Tahap Boot #

Tabel berikut merangkum lima tahap rantai boot beserta gejala khas saat tahap itu putus:

Tahap	Gejala khas saat putus	Alat perbaikan
1. Firmware/POST	layar mati total, beep, `No bootable device`	setup UEFI: urutan boot, RAM, disk
2. Bootloader GRUB	prompt `grub rescue>`, menu GRUB tidak muncul	live USB, `grub-install`, `update-grub`
3. Kernel dan initramfs	kernel panic awal, `Waiting for root device`	pilih kernel lama, `update-initramfs -u`
4. Mount root filesystem	shell `(initramfs)` setelah `ALERT! ... does not exist`	koreksi UUID `/etc/fstab`
5. Userspace systemd	layar hitam setelah GRUB, macet di satu service	`journalctl -b`, `systemctl`

Anatomi GRUB dibedah di Chapter Bootloader dan GRUB , peran early userspace di Chapter initramfs . Prinsip bacanya: gejala yang muncul paling awal menandai tahap pertama yang putus — perbaiki di situ, jangan menembak tahap di atasnya.

Kasus 1: Terjebak di Prompt grub rescue #

Studi kasus pertama terjadi setelah Budi mengubah susunan partisi: mesin menampilkan error: unknown filesystem. Entering rescue mode. Kode GRUB di MBR masih tereksekusi, tetapi modul-modulnya tidak ditemukan lagi karena alamatnya berpindah. Prompt grub rescue> menyediakan sedikit perintah yang justru cukup untuk melanjutkan boot. Berikut contoh tampilan sesi pemulihannya:

text
grub rescue> ls
(hd0) (hd0,msdos1) (hd0,msdos2) (hd1)
grub rescue> ls (hd0,msdos2)/
boot/ etc/ home/ usr/ var/
grub rescue> set root=(hd0,msdos2)
grub rescue> set prefix=(hd0,msdos2)/boot/grub
grub rescue> insmod normal
grub rescue> normal

Perintah ls mendaftar partisi yang terlihat GRUB, lalu ls (hd0,msdos2)/ mengintip isi kandidat sampai ketemu yang memuat folder boot/. Dua perintah set mengarahkan variabel root dan prefix ke lokasi modul, lalu insmod normal dan normal menampilkan menu GRUB yang biasa. Boot hasil trik ini sementara — setelah masuk, perbaikan permanennya sudo grub-install /dev/sda diikuti update-grub.

Kasus 2: Waiting for root device #

Studi kasus kedua muncul setelah penggantian disk: boot berjalan normal beberapa detik, lalu macet lama sebelum jatuh ke prompt (initramfs). Pesannya menyebut UUID yang dicari dan tidak ditemukan — berikut contoh tampilan bagian akhirnya:

text
Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/disk/by-uuid/11111111-2222-3333-4444-555555555555 does not exist.
Dropping to a shell!

BusyBox v1.36.1 (Debian 1:1.36.1+dfsg-1) built-in shell (ash)
(initramfs) _

Mekanismenya persis bahasan Chapter initramfs : kernel termuat baik-baik, tetapi skrip early userspace gagal menemukan root filesystem yang dijanjikan — disk baru membawa UUID baru, sementara /etc/fstab masih menunggu UUID lama. Kita latih membandingkan keduanya dengan fixture fstab korban dan keluaran blkid dari live USB:

bash
cat > fstab-korban <<'AKHIR'
UUID=11111111-2222-3333-4444-555555555555  /      ext4  errors=remount-ro  0  1
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee  /boot  ext4  defaults            0  2
AKHIR
cat > blkid-live.txt <<'AKHIR'
/dev/sda1: UUID="aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" TYPE="ext4" PARTUUID="0001-01"
/dev/sda2: UUID="99999999-8888-7777-6666-555555555555" TYPE="ext4" PARTUUID="0001-02"
AKHIR
root_fstab=$(awk '$2 == "/" {sub(/^UUID=/, "", $1); print $1}' fstab-korban)
root_nyata=$(awk -F'"' '/sda2/ {print $2}' blkid-live.txt)
printf 'fstab  : UUID=%s\nblkid  : UUID=%s\n' "$root_fstab" "$root_nyata"
if [ "$root_fstab" = "$root_nyata" ]; then
  echo "cocok: initramfs akan menemukan root"
else
  echo "BEDA: kernel menunggu UUID yang tidak pernah muncul"
fi

Output yang Dihasilkan:

text
fstab  : UUID=11111111-2222-3333-4444-555555555555
blkid  : UUID=99999999-8888-7777-6666-555555555555
BEDA: kernel menunggu UUID yang tidak pernah muncul

Interpretasinya tercetak jelas: UUID fstab dan UUID nyata tidak sama, sehingga initramfs menunggu perangkat yang tidak pernah hadir. Mari kita bedah bloknya:

Dua fixture: fstab-korban adalah isi /etc/fstab korban — baris root dikenali dari kolom kedua bernilai / — sedangkan blkid-live.txt meniru keluaran blkid dari live USB.
root_fstab=$(awk ...): awk memilih baris yang kolom keduanya /, lalu sub() mengupas prefiks UUID=; format fstab dibedah di Chapter fstab .
root_nyata=$(awk -F'"' ...): pemisah kolom diganti tanda kutip, sehingga UUID yang diapit kutip jatuh tepat di kolom kedua.
Blok if: hasil BEDA menuntut koreksi, hasil cocok berarti penyebab macetnya bukan UUID.

Solusinya dijalankan lewat chroot dari live USB: sunting /etc/fstab, ganti UUID lama dengan UUID dari blkid, lalu update-initramfs -u bila modul yang hilang jadi penyebabnya.

Kasus 3: fsck dari Live USB #

Studi kasus ketiga bermula dari listrik padam mendadak: boot berikutnya berhenti di pesan UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Filesystem rusak ringan karena penulisan terputus di tengah jalan — kondisi yang dibahas tuntas di Chapter Filesystem Troubleshooting . Aturan keamanannya mutlak: fsck hanya boleh berjalan pada filesystem yang tidak terpasang, karena memperbaiki struktur disk yang sedang sibuk dipakai justru menambah kerusakan; di mesin yang tidak bisa boot, pemeriksaan dilakukan dari live USB. Keputusan “perangkat ini boleh di-fsck atau tidak” bisa dilatih dengan fixture potongan /proc/mounts:

bash
cat > daftar-mount.txt <<'AKHIR'
/dev/sda1 /boot ext4 rw,relatime 0 0
/dev/sda2 / ext4 rw,relatime 0 0
/dev/sdb1 /media/usb vfat rw 0 0
AKHIR
for perangkat in /dev/sda1 /dev/sda2 /dev/sdb1 /dev/sdc1; do
  if grep -q "^$perangkat " daftar-mount.txt; then
    printf '%s %-9s -> JANGAN di-fsck: lepas kaitan atau gunakan live USB\n' \
      "$perangkat" terpasang
  else
    printf '%s %-9s -> aman diperiksa: fsck -N dulu, lalu fsck -y bila perlu\n' \
      "$perangkat" bebas
  fi
done

Output yang Dihasilkan:

text
/dev/sda1 terpasang -> JANGAN di-fsck: lepas kaitan atau gunakan live USB
/dev/sda2 terpasang -> JANGAN di-fsck: lepas kaitan atau gunakan live USB
/dev/sdb1 terpasang -> JANGAN di-fsck: lepas kaitan atau gunakan live USB
/dev/sdc1 bebas     -> aman diperiksa: fsck -N dulu, lalu fsck -y bila perlu

Tiga perangkat pertama tercantum di daftar mount sehingga wajib dilewati; /dev/sdc1 tidak terpasang dan layak diperiksa. Di live USB sungguhan urutannya: lsblk -f mengenali partisi, fsck -N melihat rencana pemeriksaan tanpa menjalankan apa pun, lalu fsck -y menjalankan perbaikan. Opsi lengkapnya ada di fsck(8) .

Praktik: Skrip Diagnosis Tahap #

Peta lima tahap di awal chapter bisa dituliskan sebagai skrip kecil yang dibawa ke lokasi kejadian. Skrip berikut menerima satu gejala, lalu mencetak tahap yang terdampak beserta langkah pertamanya:

bash
cat > diagnosis-tahap.sh <<'AKHIR'
#!/bin/bash
# Memetakan satu gejala boot ke tahap rantai yang putus.
case "$1" in
  *beep*|*sebelum*logo*)
    echo "tahap 1 firmware/POST: cek RAM, kartu grafis, urutan boot di setup UEFI";;
  *rescue*|*bootable*)
    echo "tahap 2 bootloader: pulihkan GRUB lewat live USB (grub-install)";;
  *root*device*|*ALERT*|*initramfs*)
    echo "tahap 3 initramfs: UUID root salah atau modul hilang; bandingkan fstab vs blkid";;
  *panic*)
    echo "tahap 3/4 kernel: boot entri kernel lama, jalankan fsck bila disk dicurigai";;
  *layar*hitam*|*macet*)
    echo "tahap 5 userspace: baca journalctl -b dari TTY atau live USB";;
  *)
    echo "gejala belum terpetakan: bandingkan dengan tabel lima tahap";;
esac
AKHIR
bash diagnosis-tahap.sh "muncul prompt grub rescue"
bash diagnosis-tahap.sh "boot macet: Waiting for root device"
bash diagnosis-tahap.sh "GRUB selesai lalu layar hitam"

Output yang Dihasilkan:

text
tahap 2 bootloader: pulihkan GRUB lewat live USB (grub-install)
tahap 3 initramfs: UUID root salah atau modul hilang; bandingkan fstab vs blkid
tahap 5 userspace: baca journalctl -b dari TTY atau live USB

Tiga gejala dipetakan ke tiga tahap berbeda, padahal ketiganya membuat mesin tidak sampai ke prompt login. Bagian penting skripnya:

case "$1": seluruh keputusan bergantung pada satu argumen — gejala yang terlihat di layar.
Pola *rescue*: glob tanpa spasi cocok dengan grub rescue apa pun penulisannya; tangan *root*device*|*ALERT* menggabungkan dua gejala yang bermuara pada initramfs yang gagal menemukan root.
Tangan *): gejala tak dikenal ditolak dengan sopan alih-alih dikira-kira.

Boot yang gagal adalah skenario paling menegangkan, tetapi peta lima tahap memberi setiap gejala alamat yang jelas, dan hampir semua perbaikannya selesai dari live USB tanpa instal ulang. Ada satu kegagalan yang sering disangka boot gagal total padahal sistemnya hidup: layar hitam karena desktop yang menolak tampil. Kita bedah kasus itu di Chapter Black Screen dan Display Issues .

Referensi lanjut: fstab(5) untuk format kolom mount, GRUB di ArchWiki untuk prosedur pemulihan bootloader, dan fsck(8) untuk opsi pemeriksaan filesystem.