Màn hình đen đáng sợ: Tại sao quá trình khởi động lại quan trọng
Tất cả chúng ta đều đã từng nhìn chằm chằm vào con trỏ nhấp nháy trên màn hình đen, tự hỏi liệu dữ liệu của mình có vừa biến mất hay không. Bạn nhấn nút nguồn, quạt quay tít, nhưng rồi… không có gì cả. Hoặc có thể là một dòng lệnh grub rescue> đầy bí ẩn đang trêu ngươi bạn. Khi mới bắt đầu quản trị máy chủ Linux, những khoảnh khắc đó thực sự là cơn ác mộng. Tôi cảm thấy mình như đang chọc gậy vào một chiếc hộp đen, hy vọng một điều kỳ diệu sẽ xảy ra.
Hiểu về trình tự khởi động Linux không chỉ dành cho các học giả; đó là “siêu năng lực” tối thượng để xử lý sự cố. Sau khi quản lý hơn 15 thực thể Linux production cho nhiều khách hàng khác nhau, tôi nhận ra rằng 90% lỗi khởi động có thể dự đoán được nếu bạn biết các điểm bàn giao. Biết chính xác nơi phần cứng bàn giao cho phần mềm giúp bạn xác định được mình đang đối mặt với một viên pin CMOS đã chết, một bootloader bị hỏng hay một dịch vụ systemd đang bị treo.
Hãy coi trình tự khởi động như một cuộc đua tiếp sức đầy kịch tính. Bốn vận động viên phải chuyển gậy cho nhau một cách hoàn hảo. Nếu bất kỳ ai vấp ngã, cuộc đua sẽ dừng lại và bạn sẽ phải đối mặt với một hệ thống không thể khởi động.
Cuộc đua tiếp sức: Bản đồ 4 giai đoạn
Bạn không “cài đặt” quá trình khởi động — nó đã được tích hợp sẵn vào phần cứng và hệ điều hành của bạn. Tuy nhiên, bạn cần một bản đồ tư duy để điều hướng khi mọi thứ đi chệch hướng. Quá trình này tuân theo một hệ thống phân cấp chặt chẽ: nếu Giai đoạn 1 thất bại, Giai đoạn 2 thậm chí sẽ không bao giờ nhận được tín hiệu.
Giai đoạn 1: Phần cứng và Firmware (BIOS/UEFI)
Ngay khi dòng điện chạy vào bo mạch chủ, firmware sẽ nắm quyền điều khiển. Trên các phần cứng cũ (trước năm 2010), đây là BIOS. Các hệ thống hiện đại sử dụng UEFI (Unified Extensible Firmware Interface), về cơ bản nó là một hệ điều hành nhỏ của riêng mình.
- POST (Power-On Self-Test): Firmware thực hiện kiểm kê nhanh. Nó kiểm tra xem 32GB RAM đã được cắm đúng chưa và CPU có phản hồi hay không. Nếu bạn nghe thấy ba tiếng bíp ngắn và màn hình vẫn tối đen, cuộc đua tiếp sức thậm chí còn chưa bắt đầu.
- Tìm điểm bàn giao: BIOS tìm kiếm một cung khởi động (Boot Sector – MBR) nhỏ 512 byte ở ngay đầu đĩa. UEFI tinh vi hơn; nó tìm kiếm một Phân vùng Hệ thống EFI (ESP) — thường là phân vùng FAT32 — và thực thi một tệp
.eficụ thể, chẳng hạn như/EFI/ubuntu/grubx64.efi.
Giai đoạn 2: Trình khởi động (GRUB2)
Firmware thông minh, nhưng nó không biết cách chạy Linux. Nó chỉ biết cách tìm Bootloader. Hầu hết các bản phân phối (distro) dựa vào GRUB2. Nhiệm vụ chính của nó là hiển thị cho bạn một menu và tải kernel vào bộ nhớ.
Thấy được menu có nghĩa là firmware đã thành công. Tuy nhiên, nếu bạn bị đẩy vào dòng lệnh grub> hoặc grub rescue>, điều đó có nghĩa là GRUB đã tìm thấy mã của chính nó nhưng không tìm thấy tệp cấu hình hoặc phân vùng chứa kernel.
Giai đoạn 3: Kernel và Initramfs
Đây là nơi hệ điều hành Linux thực sự bắt đầu sự sống của mình. GRUB kéo hai tệp quan trọng vào RAM: Kernel (vmlinuz) và Initramfs (Initial RAM Filesystem).
Kernel là trái tim của hệ thống, nhưng nó đối mặt với một tình huống tiến thoái lưỡng nan. Nó cần driver để đọc ổ cứng (đặc biệt là với NVMe hoặc các ổ đĩa được mã hóa), nhưng những driver đó lại được lưu trữ trên chính ổ cứng đó. Initramfs giải quyết vấn đề này. Nó là một hệ thống tệp gốc (root filesystem) tạm thời, siêu nhỏ, chứa vừa đủ driver để kernel có thể mount phân vùng gốc thật (/). Khi đĩa thật đã được mount, kernel “chuyển sang” (pivot) đó và xóa đĩa RAM tạm thời.
Giai đoạn 4: Hệ thống Init (systemd)
Khi hệ thống tệp gốc thật sự đã sẵn sàng, kernel bắt đầu tiến trình đầu tiên: PID 1. Trên các bản phân phối hiện đại như Ubuntu, Debian và RHEL, đây là systemd. Nó là nhà điều phối chính khởi chạy ngăn xếp mạng (network stack), máy chủ SSH và cuối cùng là màn hình đăng nhập.
Cấu hình: Cách can thiệp
Để gỡ lỗi hiệu quả, bạn cần biết cách can thiệp vào cuộc đua tiếp sức này. Menu GRUB là điểm can thiệp của bạn.
Chỉnh sửa GRUB trực tiếp
Nếu hệ thống bị treo khi khởi động, bạn thường có thể bỏ qua sự cố bằng cách tinh chỉnh các tham số kernel. Khi menu GRUB xuất hiện, nhấn e để chỉnh sửa. Tìm dòng bắt đầu bằng linux:
linux /boot/vmlinuz-6.5.0-generic root=UUID=a1b2c3d4... ro quiet splashĐể xem chính xác điều gì đang gặp lỗi, hãy xóa quiet và splash. Điều này buộc hệ thống phải cuộn văn bản thay vì hiển thị logo đẹp mắt. Nếu bạn bị khóa tài khoản, việc thêm init=/bin/bash vào cuối dòng sẽ đưa bạn thẳng vào shell root trước khi bất kỳ dịch vụ bảo mật hay mật khẩu nào được tải.
Sửa lỗi vĩnh viễn
Tránh chạm trực tiếp vào /boot/grub/grub.cfg — nó sẽ bị ghi đè mỗi khi kernel cập nhật. Thay vào đó, hãy chỉnh sửa /etc/default/grub. Ví dụ, để đảm bảo bạn luôn thấy log chi tiết, hãy thay đổi dòng mặc định:
# Chỉnh sửa /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="nosplash debug"
# Áp dụng các thay đổi
sudo update-grub # Ubuntu/Debian
sudo grub2-mkconfig -o /boot/grub2/grub.cfg # RHEL/FedoraChuyển đổi Target
Systemd sử dụng các “target” thay vì các runlevel cũ. Nếu giao diện đồ họa (GUI) bị lỗi và ngăn bạn đăng nhập, bạn có thể buộc hệ thống khởi động vào chế độ chỉ văn bản để tiết kiệm tài nguyên hoặc sửa driver:
# Khởi động vào chế độ dòng lệnh (tiết kiệm hơn 500MB RAM)
sudo systemctl set-default multi-user.target
# Quay lại giao diện desktop chuẩn
sudo systemctl set-default graphical.targetKiểm tra: Tại sao máy khởi động chậm?
Đến được màn hình đăng nhập là một thành công, nhưng hiệu năng cũng rất quan trọng. Nếu máy chủ của bạn mất 3 phút để khởi động, bạn đang gặp phải một nút thắt cổ chai.
Tìm “thủ phạm”
Tôi sử dụng systemd-analyze để kiểm tra mọi máy chủ mà tôi triển khai. Nó cung cấp một bản tóm tắt cấp cao về thời gian tiêu tốn trong kernel so với không gian người dùng (userspace).
systemd-analyzeĐể tìm ra thủ phạm đang làm chậm hệ thống, hãy chạy:
systemd-analyze blameLệnh này liệt kê các dịch vụ theo thời gian khởi động của chúng. Tôi đã từng phát hiện ra một ổ đĩa mạng NFS bị cấu hình sai dẫn đến bị timeout và làm tăng thêm đúng 90 giây cho mỗi lần khởi động lại. Việc sửa nhanh trong /etc/fstab đã đưa thời gian khởi động xuống dưới 15 giây.
Đi sâu vào Logs
Nếu một thiết bị phần cứng không xuất hiện, dmesg là người bạn tốt nhất. Nó hiển thị bộ đệm thô của kernel. Đối với các lỗi dịch vụ, journalctl là tiêu chuẩn:
# Hiển thị tất cả lỗi từ phiên khởi động hiện tại
journalctl -b -p errLàm chủ được các giai đoạn này đã thay đổi cách tôi tiếp cận Linux. Thay vì đoán mò, giờ đây tôi tìm kiếm xem “cây gậy” đã bị rơi ở đâu. Không thấy menu GRUB? Kiểm tra phân vùng EFI. Kernel bị panic? Build lại initramfs. Không có màn hình đăng nhập? Kiểm tra các unit của systemd. Một khi bạn chia nhỏ quá trình này, “chiếc hộp đen” sẽ trở thành một chuỗi logic có thể giải quyết được.
