Tutorial Ubuntu 26.04 / Memulihkan gangguan boot, kernel, dan jaringan

Pemulihan Ubuntu dimulai dengan memeriksa sejauh mana proses boot berlangsung melalui konsol, menyimpan bukti, lalu menelusuri perubahan terakhir. Kegagalan koneksi SSH belum membuktikan bahwa sistem operasi gagal boot. Pisahkan masalah boot, kernel, jaringan, dan aplikasi agar perubahan pemulihan sesuai dengan penyebab yang ditemukan.

Membedakan tahap kegagalan dan sasaran pemeriksaan

Sebelum mengubah keadaan, simpan bukti yang masih dapat diambil dan siapkan cadangan serta kunci pembukaan disk terenkripsi. Jangan sengaja merusak disk atau jaringan server produksi untuk berlatih. Catat waktu, pesan kesalahan asli, tindakan terakhir yang berhasil, dan perubahan sesaat sebelum gangguan; jangan sertakan kunci rahasia atau kredensial.

Gunakan log untuk mempersempit penyebab gangguan, lalu hubungkan bukti dengan perubahan yang benar-benar dilakukan. Untuk latihan dengan pencatatan kondisi awal dan pemeriksaan setelah pemulihan, lihat praktik mereproduksi gangguan dan memulihkannya berdasarkan bukti.

Mengumpulkan informasi tanpa mengubah konfigurasi

Jika masih dapat masuk ke Ubuntu yang bermasalah, perintah berikut membaca identitas sistem, layanan gagal, ruang disk, sistem berkas, dan journal. Jalankan satu per satu dan catat hasilnya; perintah yang tidak tersedia atau tidak dapat mengakses log juga merupakan informasi yang perlu ditelusuri.

cat /etc/os-release
uname -r
systemctl --failed
df -h
lsblk -f
findmnt /
sudo journalctl --list-boots
sudo journalctl -b -p err --no-pager

Jika journal menyimpan boot sebelumnya, bandingkan dengan sudo journalctl -b -1 -p err --no-pager. Tidak adanya riwayat tidak membuktikan bahwa boot sebelumnya bebas gangguan. Jika ruang disk habis, tentukan penyebab dan lokasi pemakaiannya terlebih dahulu serta simpan catatan penting sebelum membersihkan apa pun.

Baris berprioritas error membantu memilih titik awal, tetapi tidak selalu menjelaskan urutan kejadian. Perluas ke log unit dan rentang waktu di sekitar kejadian ketika hubungan sebab-akibat belum jelas. Periksa isi log sebelum membagikannya karena keluaran aplikasi dapat memuat informasi sensitif.

Berlatih memulihkan kegagalan layanan pada VM salinan

Gunakan VM latihan yang terpisah dari sistem asli dan masuk melalui konsol. Contoh ini membuat unit systemd baru tanpa mengaktifkannya saat boot, tanpa menghapus data pengguna, dan tanpa mengubah jaringan. Unit adalah konfigurasi yang dikelola systemd; drop-in menambahkan atau mengganti pengaturan unit melalui berkas terpisah.

Pastikan nama ubuntu-recovery-lab.service belum digunakan, termasuk pada lokasi unit lain atau unit yang sedang dimuat. Jika sudah ada, pilih nama latihan yang berbeda dan sesuaikan seluruh perintah pembuatan, pemulihan, serta pembersihan. Penjagaan dalam skrip menolak berkas, direktori drop-in, dan symlink di lokasi sasaran, tetapi tidak menggantikan pemeriksaan nama unit pada sistem.

Jalankan blok berikut secara utuh. Pertama unit menjalankan /usr/bin/true, lalu drop-in mengganti perintahnya dengan /usr/bin/false. Penulisan menggunakan set -C untuk menolak penimpaan berkas yang sudah ada. Jika skrip berhenti di tengah, periksa berkas yang telah dibuat dan lognya sebelum melanjutkan; jangan menonaktifkan penjagaan lalu menjalankan ulang secara membabi buta.

(
set -eu
unit=ubuntu-recovery-lab.service
file=/etc/systemd/system/$unit
drop=/etc/systemd/system/$unit.d
if sudo test -e "$file" || sudo test -L "$file" || sudo test -e "$drop" || sudo test -L "$drop"; then
    printf 'Unit latihan sudah ada; pilih nama lain.\n' >&2
    exit 1
fi
sudo sh -c 'set -C; cat > "$1"' sh "$file" <<'EOF'
[Unit]
Description=Latihan pemulihan Ubuntu terbatas
[Service]
Type=oneshot
ExecStart=/usr/bin/true
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
sudo systemctl start "$unit"
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo install -d -m 0755 "$drop"
sudo sh -c 'set -C; cat > "$1/10-failure.conf"' sh "$drop" <<'EOF'
[Service]
ExecStart=
ExecStart=/usr/bin/false
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
if sudo systemctl start "$unit"; then
    printf 'Berhasil di luar dugaan: periksa unit yang dimuat.\n' >&2
    exit 1
fi
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo journalctl -u "$unit" --since '5 minutes ago' --no-pager
)

Eksekusi awal diharapkan menghasilkan Result=success dan ExecMainStatus=0. Setelah drop-in diterapkan, hasil yang dicari adalah Result=exit-code dan ExecMainStatus=1. Status keluar tidak nol dari systemctl start saja belum membuktikan kegagalan yang direncanakan: cocokkan hasil unit, perintah yang dijalankan, dan waktu kejadian di journal. Kesalahan izin atau konfigurasi lain harus diselidiki terlebih dahulu.

Pada layanan Type=oneshot tanpa RemainAfterExit=yes, proses yang selesai dengan sukses dapat kembali ke keadaan inactive. Jangan menyamakan inactive dengan failed. Baris ExecStart= yang kosong pada drop-in mengosongkan daftar sebelumnya sebelum menetapkan /usr/bin/false; pertahankan baris ini. Perilaku tersebut dijelaskan dalam dokumentasi resmi systemd tentang oneshot dan ExecStart.

Blok pemulihan berikut hanya berlaku jika berkas drop-in tersebut baru dibuat oleh latihan ini dan belum diubah untuk keperluan lain. Blok menghapus berkas itu saja, memuat ulang konfigurasi, menghapus status gagal, lalu menjalankan kembali unit.

(
set -eu
sudo rm -- /etc/systemd/system/ubuntu-recovery-lab.service.d/10-failure.conf
sudo systemctl daemon-reload
sudo systemctl reset-failed ubuntu-recovery-lab.service
sudo systemctl start ubuntu-recovery-lab.service
sudo systemctl show ubuntu-recovery-lab.service -p Result -p ExecMainStatus
)

Pastikan hasil kembali menjadi success dan 0. Untuk membersihkan seluruh latihan, periksa bahwa unit memang milik latihan ini dan tidak aktif, hapus hanya berkas unit tersebut serta direktori drop-in yang sudah kosong, lalu lakukan sudo systemctl daemon-reload. Jangan menghapus direktori unit lain secara rekursif. Latihan ini memeriksa jalur diagnosis layanan; latihan ini tidak mereproduksi kegagalan boot atau kernel.

Mencoba kernel sebelumnya setelah pembaruan

Jika boot gagal sesaat setelah pembaruan, sedangkan GRUB dan kernel sebelumnya masih tersedia, gunakan konsol untuk membuka Advanced options for Ubuntu dan mencoba kernel sebelumnya. GRUB adalah pemuat boot yang memilih kernel. Cara memunculkan menunya bergantung pada firmware, host, dan waktu penekanan tombol; ikuti cara akses konsol atau menu boot perangkat yang digunakan. Disk terenkripsi tetap memerlukan pembukaan enkripsi.

Jika kernel sebelumnya berhasil boot, catat uname -r, lalu bandingkan riwayat pembaruan, log kernel terkait, dan kondisi driver. Jika menggunakan DKMS (Dynamic Kernel Module Support), periksa pula modul yang dibangun untuk kernel tersebut. Keberhasilan ini membantu mempersempit masalah, tetapi tidak membuktikan bahwa kernel baru merupakan satu-satunya penyebab.

Pertahankan kernel yang sedang berjalan serta kernel cadangan yang diketahui dapat boot. Perbaiki penyebab yang telah ditemukan, kemudian periksa boot normal lagi. Panduan Recovery mode pada Ubuntu Wiki menjelaskan menu pemulihan dan prasyarat aksesnya.

Memastikan alat pembuat initial RAM disk

Initial RAM disk menyediakan lingkungan awal untuk menyiapkan sistem sebelum root utama digunakan. Ubuntu 26.04 memakai Dracut sebagai infrastruktur bakunya, sedangkan initramfs-tools tetap didukung dan mungkin masih digunakan pada instalasi tertentu. Karena itu, jangan langsung menyalin perintah pembuatan ulang dari panduan LTS lain. Periksa paket, perintah yang tersedia, dan bahan boot pada /boot terlebih dahulu.

dpkg-query -W dracut dracut-core initramfs-tools 2>/dev/null
command -v dracut update-initramfs
ls -lh /boot

Keberadaan suatu alat tidak membuktikan bahwa citra boot saat ini dibuat olehnya. Paket yang tidak terpasang dapat membuat dpkg-query mengembalikan status tidak nol; contoh ini mengalihkan pesan error ke /dev/null. Baca hasil tiap perintah secara terpisah, dan jangan menjadikan tidak adanya keluaran sebagai alasan langsung untuk memasang atau menghapus paket.

Sebelum membuat ulang citra boot, tentukan kernel sasaran dan konfigurasi enkripsi, LVM (Logical Volume Manager), atau RAID yang digunakan. Siapkan kernel yang masih berfungsi, konsol, dan cadangan. Rincian pergantian infrastruktur dan keberlanjutan dukungan initramfs-tools tersedia pada ringkasan resmi Ubuntu 26.04 untuk pengguna LTS, bagian Dracut.

Memeriksa keadaan sebelum mengizinkan penulisan di mode pemulihan

Shell root pada menu pemulihan memiliki hak administrator penuh. Periksa pengenalan disk, ruang kosong, keadaan mount, dan berkas yang benar-benar perlu diperbaiki. Hanya jika sistem berkas root dalam keadaan baca-saja dan perbaikan konfigurasi memang membutuhkan penulisan, pertimbangkan remount berikut dari shell pemulihan.

findmnt /
mount -o remount,rw /

Perintah ini tidak memakai sudo karena dijalankan sebagai root di shell pemulihan. findmnt / membantu melihat mount root; sesudah remount, periksa kembali opsi mount dan lakukan hanya perubahan yang sudah ditentukan. Jika muncul kerusakan sistem berkas atau kesalahan input/output, hentikan upaya penulisan berulang dan prioritaskan penyelamatan data serta prosedur yang sesuai dengan susunan disk.

Jangan menjalankan fsck dalam mode perbaikan pada sistem berkas yang masih terpasang. Jangan menginisialisasi disk jika identitas dan perannya belum jelas. Remount baca-tulis bukan cara memperbaiki kerusakan fisik atau menjamin konsistensi sistem berkas.

Memulihkan koneksi setelah perubahan jaringan

Gunakan konsol untuk membedakan alamat yang hilang, rute yang salah, masalah resolusi nama, dan layanan SSH yang tidak mendengarkan. DNS adalah sistem penerjemah nama menjadi alamat; koneksi dengan alamat IP yang berhasil belum memastikan bahwa resolusi nama juga berfungsi.

ip -br address
ip route
resolvectl status
sudo netplan get
systemctl is-active NetworkManager systemd-networkd
sudo ss -lntp

Periksa antarmuka nyata, pengelola jaringan, dan konfigurasi Netplan yang berlaku. Baca keluaran NetworkManager dan systemd-networkd sesuai pengelola yang digunakan; salah satunya tidak aktif belum tentu merupakan gangguan. Bandingkan berkas terakhir yang diubah dengan cadangan sebelum perubahan. Jangan menambahkan berkas YAML dengan nama lain untuk menutupi kesalahan, karena konfigurasi dapat digabungkan. Periksa juga apakah cloud-init atau alat lain yang membuat konfigurasi tersebut.

Sebelum memulihkan cadangan yang benar, simpan salinan konfigurasi saat ini. Setelah sudo netplan generate berhasil, pertahankan akses konsol dan gunakan sudo netplan try --timeout 120. Uji alamat, rute, DNS, serta koneksi SSH baru selama waktu konfirmasi sebelum menerima konfigurasi. Jika waktu habis atau pengujian dibatalkan, verifikasi bahwa konfigurasi benar-benar kembali; mekanisme otomatis ini memiliki keterbatasan. Periksa pula isi berkas di disk sebelum melakukan reboot.

Jika jaringan sudah berfungsi, selidiki kunci SSH dan port yang mendengarkan serta aturan UFW secara terpisah. Dokumentasi resmi netplan try dan masalah rollback yang diketahui menjelaskan alasan pemeriksaan setelah pengujian tetap diperlukan.

Menyelamatkan data dan menentukan pemulihan selesai

Jika sistem operasi terpasang tidak dapat digunakan, pertimbangkan lingkungan pemulihan dari Live ISO yang telah diverifikasi. Sebelum mengakses disk, identifikasi enkripsi, LVM, dan RAID. Pastikan disk sumber tidak keliru dipilih sebagai sasaran instalasi. Jangan menebak perintah pemasangan ulang GRUB atau pembuatan ulang partisi; pilih prosedur yang sesuai dengan susunan sistem dan cadangan yang sudah diuji.

Setelah perbaikan, periksa reboot, koneksi SSH baru, keadaan layanan, pembacaan dan penulisan aplikasi, log, serta cadangan. Catat perubahan yang dikembalikan, bagian yang membaik, hal yang belum terselesaikan, dan bukti yang perlu dikumpulkan jika masalah berulang. Pemulihan selesai ketika operasi normal dapat dipertahankan, bukan semata-mata saat server pertama kali merespons kembali.