Recovery dari Live USB

Sampai di titik ini, semua perbaikan kita punya satu syarat yang sama: sistem masih bisa boot. Chapter penutup ini melepas syarat itu. Ketika GRUB rusak, fstab salah, atau sistem menolak menyala dengan kernel mana pun, live USB mengubah situasi: Linux yang utuh berjalan dari flashdisk, memandang disk yang rusak sekadar sebagai perangkat yang bisa dipasang dan diperbaiki dari luar — cara kerja live session sudah dibahas di Live USB Linux . Prosedur intinya tiga gerakan: identifikasi partisi, mount, lalu — untuk perbaikan yang butuh konteks sistem sungguhan — chroot.

Urutan yang Aman: Data Dulu, Perbaikan Belakangan #

Saat sistem tidak bisa boot, satu-satunya salinan data penting sering kali ada di dalam disk yang sama yang hendak kita obati. Karena itu urutannya tidak bisa ditukar: amankan data lebih dulu ke disk eksternal, baru menjalankan perbaikan. Perbaikan yang gagal paling buruk menyisakan disk kosong; perbaikan di atas salinan data yang sudah aman hanyalah kesempatan belajar.

Mengidentifikasi Partisi Korban dengan lsblk #

Di sesi live, disk internal belum terpasang apa-apa — jadi langkah pertama adalah mengenali partisinya. lsblk membaca tabel partisi tanpa menyentuh isinya; varian lsblk -o NAME,SIZE,FSTYPE,LABEL memberi kolom yang cukup untuk menebak kandidat root tanpa memasangnya. Potongan output berikut kita simpan sebagai fixture untuk dilatih:

cat > lsblk.txt <<'AKHIR'
NAME   SIZE FSTYPE LABEL
sda   465.8G
sda1   512M vfat   EFI
sda2  464.3G ext4   debian-root
sdb    28.9G
sdb1  28.9G  iso9660 Debian 13 live
AKHIR
awk '$3 == "ext4" {print "kandidat root :", $1, "-", $4}' lsblk.txt

Output yang Dihasilkan:

kandidat root : sda2 - debian-root

Saringannya membaca tiga tanda sekaligus: sda2 bertipe ext4 (partisi data Linux, bukan vfat EFI dan bukan iso9660 milik media live itu sendiri) dan berlabel debian-root. Ukurannya juga bicara — partisi root hampir selalu yang terbesar. Bila label tidak ada, lsblk -f tetap menampilkan FSTYPE, dan blkid memberi UUID yang bisa dicocokkan dengan isi /etc/fstab partisi itu — pemetaan UUID dibahas di fstab .

Mount dan chroot, Langkah demi Langkah #

Dengan kandidat root di tangan, prosedur standarnya berjalan dalam lima langkah bernomor — semuanya butuh root di sesi live:

# 1. Pasang partisi root korban ke /mnt
mount /dev/sda2 /mnt

# 2. Tautkan filesystem semu ke dalamnya
mount --bind /dev  /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys  /mnt/sys
mount --bind /run  /mnt/run

# 3. Pindahkan akar ke dalam sistem korban
chroot /mnt

Tiap perintah punya alasan yang perlu dipahami, bukan dihafal:

1. mount /dev/sda2 /mnt — isi partisi korban kini terbaca di bawah /mnt; perintah mount dan opsi-opsinya dibahas di Mount Configuration .
2. mount --bind /dev /mnt/dev — chroot hanya memindahkan akar path, bukan kernelnya; tanpa node perangkat di dalamnya, program di sistem korban tidak bisa membuka disk, terminal, atau perangkat apa pun. --bind menautkan pohon /dev yang hidup ke posisinya yang baru.
3. /proc dan /sys — dua pseudo-filesystem tempat kernel menampilkan informasi proses dan perangkat; tanpa keduanya, ps, apt, dan grub-install kehilangan jendela mereka ke kernel.
4. /run — berkas status runtime (PID, socket) yang ditulis sejak boot; beberapa alat modern menolak bekerja tanpanya.
5. chroot /mnt — prompt berganti: binary, library, dan konfigurasi yang sekarang dieksekusi adalah milik sistem korban, bukan milik sesi live. Sejak titik ini, passwd, grub-install, dan apt bekerja seolah-olah sistem yang rusak sedang menyala.

Struktur yang harus siap sebelum chroot bisa dilatih tanpa root — kita bangun miniatur partisi korban sebagai folder latihan, lalu periksa kesiapannya dengan skrip:

mkdir -p disk-sistem/dev disk-sistem/proc disk-sistem/sys disk-sistem/run
mkdir -p disk-sistem/etc disk-sistem/boot disk-sistem/usr/bin disk-sistem/home
printf 'UUID=9c1f... / ext4 errors=remount-ro 0 1\n' > disk-sistem/etc/fstab
cat > siapkan-chroot.sh <<'AKHIR'
#!/bin/bash
# Periksa kesiapan struktur chroot: titik bind dan berkas penting.
ok=1
for d in dev proc sys run; do
  if [ -d "disk-sistem/$d" ]; then
    echo "siap   : disk-sistem/$d"
  else
    echo "HILANG : disk-sistem/$d"; ok=0
  fi
done
if [ ! -f disk-sistem/etc/fstab ]; then
  echo "HILANG : disk-sistem/etc/fstab"; ok=0
fi
[ "$ok" = 1 ] && echo "struktur disk-sistem siap di-chroot"
AKHIR
bash siapkan-chroot.sh

Output yang Dihasilkan:

siap   : disk-sistem/dev
siap   : disk-sistem/proc
siap   : disk-sistem/sys
siap   : disk-sistem/run
struktur disk-sistem siap di-chroot

Skripnya sengaja memeriksa, bukan memperbaiki: empat direktori bind plus etc/fstab adalah prasyarat minimum chroot yang berfungsi — persis daftar yang dibuat lima langkah bernomor di atas. Setelah keluar dari chroot nanti, lepas semua tautan itu dalam urutan terbalik (umount /mnt/dev /mnt/proc /mnt/sys /mnt/run, lalu /mnt), karena titik yang masih tertaut membuat partisi menolak dilepas bersih.

Perbaikan dari Dalam chroot #

Di dalam chroot, kita berdiri di sistem yang rusak dengan peralatannya yang utuh. Tabel berikut memetakan skenario paling umum ke tindakannya:

Dua detail penting. Pertama, grub-install menunjuk disk /dev/sda, bukan partisi — bootloader dipasang di awal disk, bukan di dalam filesystem. Kedua, passwd di dalam chroot mengubah berkas /etc/shadow milik disk korban, itulah mengapa reset password dari live USB sah: kita memperbaiki berkasnya langsung di tempat tidurnya. Varian tanpa chroot untuk kasus ini (boot dengan init=/bin/bash) sudah dipetakan di System Recovery .

Satu perbaikan justru dilarang dari dalam chroot: fsck tidak boleh menjalankan filesystem yang sedang terpasang baca-tulis. Lepas dulu partisinya, atau jalankan pemeriksaan dari luar chroot pada partisi yang tidak ter-mount — dan bila kerusakan berat, salin datanya lebih dulu sebelum fsck menyentuh apa pun.

Menyelamatkan Data dengan rsync #

Kembali ke urutan aman: sebelum semua perbaikan itu, data harus keluar. Dengan partisi korban terpasang di /mnt, rsync menyalinnya ke disk eksternal dengan verifikasi bawaan — pola lengkap penyelamatan dan pemulihannya dibahas di Restore dan Disaster Recovery . Latihan polanya di folder lokal:

mkdir -p disk-sistem/home/budi/dokumen disk-eksternal
printf 'laporan triwulan\n' > disk-sistem/home/budi/dokumen/laporan.txt
printf 'catatan penting\n' > disk-sistem/home/budi/catatan.txt
rsync -a disk-sistem/home/budi/ disk-eksternal/
diff -r disk-sistem/home/budi disk-eksternal && echo "salinan identik dengan sumber"
find disk-eksternal -type f | sort

Output yang Dihasilkan:

salinan identik dengan sumber
disk-eksternal/catatan.txt
disk-eksternal/dokumen/laporan.txt

Tiga perintah itu membentuk disiplin penyelamatan: rsync -a menyalin dengan izin dan stempel waktu utuh — perhatikan trailing slash di sumber, yang berarti “salin isinya”, bukan foldernya; diff -r membandingkan isi kedua pohon berkas — keluar tanpa keluhan berarti identik; dan find | sort mendaftar hasil akhirnya sebagai bukti. Di kasus nyata, tambahkan opsi --numeric-ids bila kepemilikan UID/GID harus terjaga, dan jalankan ulang rsync yang sama untuk melanjutkan salinan yang terputus — rsync hanya memindahkan selisihnya. Opsi-opsinya dibedah di rsync .

Kapan Memutuskan Instal Ulang #

Satu pertanyaan terakhir yang jujur diajukan live USB: apakah sistem ini masih layak diperbaiki? Jawabannya ukurannya sederhana — bila datanya sudah aman di media eksternal, biaya instal ulang hanyalah waktu, sementara perbaikan yang berkali-kali gagal punya biaya yang tidak kunjung jelas. Tabel skenario di atas menyelesaikan mayoritas kasus dalam satu sesi; untuk sisanya, salinan rsync yang terverifikasi membuat “mulai dari nol” bukan lagi ancaman.

Dengan chapter ini section Troubleshooting tertutup: dari boot yang gagal sampai sistem yang menolak hidup, kita kini punya prosedur untuk semuanya. Perjalanan berikutnya berbalik arah — dari memperbaiki Linux ke membongkarnya: Section Advanced Linux dimulai dari system call, gerbang tempat semua program user space berbicara dengan kernel.

Dokumentasi perintah-perintah kuncinya: --bind dan perilaku mount di mount(8) , pemasangan bootloader di grub-install(8) , dan opsi arsip rsync di rsync(1) .