Làm Chủ Chroot trên Linux: Cứu Hộ và Khôi Phục Hệ Thống từ Live USB

Bắt Đầu Nhanh: Vào Chroot Trong Vòng 5 Phút

Server không chịu khởi động. Đang 2 giờ sáng. Bạn có một chiếc Live USB và một deadline đang chờ. Đây là con đường nhanh nhất để có môi trường chroot hoạt động được.

Boot từ Live USB (Ubuntu, Debian, Arch — không quan trọng lắm), mở terminal rồi chạy:

# Tìm phân vùng root
lsblk

# Mount phân vùng root của hệ thống hỏng
mount /dev/sda2 /mnt

# Mount các virtual filesystem thiết yếu
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run

# Nhảy vào hệ thống hỏng
chroot /mnt /bin/bash

Xong rồi đó. Bây giờ bạn đang thao tác bên trong filesystem của hệ thống hỏng với quyền root. Reset mật khẩu, cài lại bootloader, sửa package lỗi — bất cứ thứ gì bạn thường làm trên hệ thống đang chạy đều có thể làm được ngay bây giờ.

Một lưu ý trước khi tiếp tục: cấu hình LVM hoặc hệ thống có phân vùng root trên ổ đĩa không rõ ràng có thể trông khác trong output của lsblk. Khi không chắc, hãy kiểm tra chéo với fdisk -l hoặc blkid để xác nhận thiết bị nào bạn thực sự muốn mount.

Chroot Thực Sự Hoạt Động Như Thế Nào Bên Dưới

Chroot — viết tắt của “change root” — là một syscall của Unix giúp ánh xạ lại thư mục root cho tiến trình hiện tại và mọi tiến trình con của nó. Một tiến trình bên trong chroot nhìn thấy /mnt như thể đó là /. Mọi thứ phía trên mount point đó đều không nhìn thấy được.

Với công việc cứu hộ, đây chính xác là điều bạn muốn. Các package manager, công cụ bootloader và file cấu hình đều hoạt động như thể hệ thống hỏng đang chạy bình thường — vì từ góc nhìn của chúng, đúng là như vậy.

Tại Sao Việc Mount Virtual Filesystem Là Bắt Buộc

Những lệnh mount --bind cho /dev, /proc, /sys và /run không phải trang trí. Bỏ sót một cái là mọi thứ hỏng theo cách trông hoàn toàn không liên quan đến mount bị thiếu đó:

• /dev — không có device node; grub-install thất bại im lặng nếu thiếu cái này
• /proc — thông tin tiến trình không có; hầu hết công cụ hệ thống hoặc crash hoặc trả về dữ liệu rác
• /sys — giao diện kernel biến mất; các thao tác liên quan đến phần cứng ngừng hoạt động
• /run — dữ liệu runtime bị thiếu; bất cứ thứ gì liên quan đến systemd sẽ hoạt động sai

Bỏ sót một trong số này và bạn sẽ mất 20 phút đuổi theo những lỗi khó hiểu trước khi nhận ra nguyên nhân thực sự.

Xử Lý EFI và Phân Vùng Boot Riêng Biệt

Hầu hết các hệ thống hiện đại dùng UEFI với một EFI System Partition (ESP) riêng. Để sửa bootloader thì cần mount nó nữa:

# Tìm phân vùng EFI (thường là FAT32, khoảng 512MB)
lsblk -f | grep -i vfat

# Mount nó
mount /dev/sda1 /mnt/boot/efi

# Nếu /boot cũng là phân vùng riêng
mount /dev/sda3 /mnt/boot

Luôn kiểm tra layout phân vùng theo fstab trước khi suy đoán cấu trúc ổ đĩa:

cat /mnt/etc/fstab

Các Tình Huống Cứu Hộ Thực Tế Với Lệnh Cụ Thể

Tình Huống 1: Reset Mật Khẩu Root Bị Quên

Lý do phổ biến nhất khiến ai đó phải lôi Live USB ra. Một khi đã vào chroot, chỉ cần hai lệnh:

passwd root
# hoặc cho một user cụ thể:
passwd username

Không cần vật lộn với single-user mode. Không cần chỉnh kernel boot parameter. Xong luôn.

Tình Huống 2: Cài Lại GRUB Sau Khi Update Bị Hỏng

Trường hợp này từng xảy ra với mình trên một server Ubuntu 22.04 production — một kernel update đụng độ với việc mất điện giữa chừng khi đang cài. Hệ thống khởi động lên màn hình GRUB rescue prompt mà không có cách nào rõ ràng để tiến tiếp. Hai lệnh từ bên trong chroot đã sửa hoàn toàn:

# Bên trong chroot (hệ thống BIOS/MBR)
grub-install /dev/sda
update-grub

Hệ thống UEFI cần cú pháp hơi khác:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
update-grub

Làm việc trực tiếp từ GRUB rescue prompt rất khổ sở. Môi trường đó bị cắt giảm tối đa; một nửa số lệnh bạn muốn dùng đều không có ở đó. Chroot cho bạn toàn bộ bộ công cụ hệ thống, điều đó tạo ra sự khác biệt giữa sửa xong trong 10 phút hay mò mẫm cả tiếng đồng hồ.

Tình Huống 3: Sửa Package Manager Bị Hỏng

Một lần chạy apt upgrade hoặc dpkg bị gián đoạn sẽ để lại database package ở trạng thái cấu hình dở dang. Từ bên trong chroot:

# Tiếp tục các cài đặt bị gián đoạn
dpkg --configure -a

# Cài lại bắt buộc một package cụ thể bị hỏng
apt-get install --reinstall linux-image-generic

# Nếu chính apt bị lỗi
dpkg --audit
apt-get -f install

Các hệ thống dùng RPM (RHEL, AlmaLinux, Fedora) có lệnh tương đương:

rpm --rebuilddb
dnf reinstall systemd

Tình Huống 4: Khôi Phục Sau Khi Sửa /etc/fstab Sai

Một ký tự sai trong /etc/fstab có thể khiến hệ thống rơi vào emergency mode khi khởi động. Thủ phạm thường là UUID gõ nhầm. Từ chroot, đây chỉ là chỉnh sửa file thông thường:

nano /etc/fstab
# hoặc
vim /etc/fstab

Lấy UUID đúng từ blkid — lệnh này liệt kê mọi block device cùng UUID của nó để bạn có thể copy-paste mà không cần đoán mò:

blkid

Tình Huống 5: Mở Khóa Volume Mã Hóa LUKS Trước Khi Chroot

Mã hóa toàn ổ đĩa thêm một bước trước khi bạn có thể mount bất cứ thứ gì:

# Mở LUKS container
cryptsetup open /dev/sda2 cryptroot

# Mount volume đã giải mã
mount /dev/mapper/cryptroot /mnt

# Nếu LVM nằm trên LUKS
vgscan
vgchange -ay
mount /dev/mapper/ubuntu--vg-ubuntu--lv /mnt

Mẹo Thực Tế Thực Sự Hữu Ích Lúc 2 Giờ Sáng

Chuẩn Bị Sẵn Script Cứu Hộ

Gõ những lệnh mount đó từ trí nhớ trong lúc căng thẳng là cách lỗi đánh máy xảy ra. Hãy lưu script này vào USB hoặc phần ghi chú của password manager — nó tự động xử lý việc mount và dọn dẹp:

#!/bin/bash
# rescue-chroot.sh — mount và vào chroot
set -e

ROOT_PART="${1:-/dev/sda2}"
MOUNT_POINT="/mnt"

mount "$ROOT_PART" "$MOUNT_POINT"
for fs in dev proc sys run; do
  mount --bind "/$fs" "$MOUNT_POINT/$fs"
done

echo "Đang vào chroot trên $ROOT_PART..."
chroot "$MOUNT_POINT" /bin/bash

# Dọn dẹp khi thoát
for fs in run sys proc dev; do
  umount "$MOUNT_POINT/$fs"
done
umount "$MOUNT_POINT"
echo "Đã unmount sạch sẽ."

Cách dùng: bash rescue-chroot.sh /dev/sda2

Luôn Unmount Đúng Cách

Khi xong việc, thoát khỏi shell chroot và unmount theo thứ tự ngược lại:

exit

umount /mnt/run
umount /mnt/sys
umount /mnt/proc
umount /mnt/dev
umount /mnt

Bỏ qua bước này sẽ để lại filesystem journal ở trạng thái bẩn. Trường hợp nhẹ: mất thêm thời gian fsck lần khởi động tiếp theo. Trường hợp nặng: filesystem bị hỏng thực sự. Không kết quả nào vui vẻ cả khi đang là 3 giờ sáng.

DNS Không Hoạt Động Bên Trong Chroot — Đây Là Cách Sửa

Nếu bạn cần tải package hoặc chạy update từ bên trong chroot, name resolution mặc định sẽ bị hỏng. Một lệnh là sửa được:

cp /etc/resolv.conf /mnt/etc/resolv.conf

Lệnh này copy cấu hình DNS của môi trường Live vào chroot để apt và dnf có thể kết nối internet bình thường.

Lỗi Exec Format Error: Vấn Đề Không Khớp Kiến Trúc CPU

Gặp lỗi chroot: failed to run command '/bin/bash': Exec format error? Live USB và hệ thống đích của bạn có kiến trúc CPU khác nhau. Tình huống phổ biến: cố chroot vào ảnh Raspberry Pi hoặc server ARM từ laptop x86_64. Cách sửa cần dùng QEMU user-mode emulation:

apt-get install qemu-user-static
cp /usr/bin/qemu-aarch64-static /mnt/usr/bin/
chroot /mnt /bin/bash

Tình huống này xảy ra thường xuyên hơn bạn nghĩ khi bắt đầu quản lý phần cứng ARM song song với các server x86 thông thường.

Xác Nhận Bạn Đang Thực Sự Ở Trong Đúng Hệ Thống

Một bước kiểm tra nhanh sau khi vào chroot chỉ tốn 10 giây và tránh được nhiều nhầm lẫn:

# Phải hiển thị hostname của hệ thống hỏng, không phải của Live USB
hostname

# Phải hiển thị thông tin OS release của hệ thống hỏng
cat /etc/os-release

# Phải liệt kê các package đã cài của hệ thống hỏng
dpkg -l | head -20

Nếu bất kỳ lệnh nào trong số này hiển thị dữ liệu của Live USB thay vì của hệ thống hỏng, thì việc mount đã bị sai. Quay lại và xác nhận bạn đã chỉ đúng phân vùng — hầu như lúc nào cũng là nhầm giữa /dev/sda2 và /dev/sdb2 khi boot từ USB.