Linux系统彻底进不去的救援指南(initramfs、recovery与chroot)

前言

当旧内核也无法正常进入系统时，排查环境会从完整 ubuntu 系统逐步缩小为 recovery mode、initramfs shell，甚至 live usb。

重点处理下面三种情况：

1. 启动后停在 (initramfs)；
2. 只能进入 grub 的 recovery mode；
3. 系统完全无法启动，需要 live usb 挂载原系统并进入 chroot。

后半部分还会整理内核包重装、旧内核默认项、恢复验收、升级前检查和常见错误操作。

注意：fsck、磁盘挂载、grub-install 和 chroot 都会直接操作系统文件或启动环境。执行前必须确认设备名、分区类型、启动模式和挂载状态。

一、进入(initramfs)后怎么判断

1.1 先核对内核收到的启动参数

常见提示：

alert! uuid=xxxx does not exist
dropped to a shell!
(initramfs)

先执行：

cat /proc/cmdline

确认其中的 root=uuid=...。

再看系统当前识别到的设备：

cat /proc/partitions
ls /dev
ls /dev/disk/by-uuid

如果目标 uuid 根本不存在，可能是：

• 存储驱动没有加载；
• 磁盘没有被识别；
• uuid 已经变化；
• lvm 或加密卷没有激活；
• grub 仍然传入旧 uuid。

1.2 按硬件情况加载模块

常见示例：

modprobe nvme
modprobe ahci
modprobe virtio_blk

不要把所有模块一起乱加载，应根据实际硬件选择。加载后重新检查：

ls /dev/disk/by-uuid

如果设备随后出现，说明相关模块可能没有正确进入 initramfs。

1.3 lvm 或加密卷场景

如果根分区位于 lvm，可以尝试：

lvm pvscan
lvm vgscan
lvm vgchange -ay

如果是 luks 加密卷，需要先确认 initramfs 中存在 cryptsetup，再根据实际映射名称解锁。不同安装方式差异较大，不要照抄不匹配的设备名。

1.4 文件系统检查

只有在目标文件系统未挂载时，才能安全执行检查。

ext4 示例：

fsck -f /dev/nvme0n1p2

不要对正在读写挂载的根文件系统直接执行修复。

xfs、btrfs、luks 和 lvm 的处理工具不同，不能把 ext4 的命令机械套用到所有环境。

二、recovery mode 能做什么

在 grub 中选择带有 (recovery mode) 的内核项。常见菜单包括：

• resume：继续正常启动；
• clean：尝试释放磁盘空间；
• dpkg：修复损坏的软件包；
• fsck：检查文件系统；
• network：启用网络；
• root：进入 root shell。

进入 root shell 后，根文件系统可能是只读的：

mount -o remount,rw /

如果 /boot、/boot/efi、/var 等是独立分区，可以在检查 /etc/fstab 后执行：

mount -a

随后根据实际问题运行：

dpkg --configure -a
apt-get -f install
update-initramfs -u -k all
update-grub
dkms status

如果 mount -a 失败，不要忽略报错继续操作。它往往说明 /etc/fstab 中本身就存在错误挂载项。

三、完全不能启动：使用 live usb + chroot

当新旧内核、recovery mode 都进不去时，live usb 是最稳妥的恢复入口。

下面这张图更容易理解 chroot 的作用：live 系统本身不是被修复对象，它只是搭了一座桥，让我们临时进入硬盘里的原 ubuntu 系统。

3.1 找到根分区和 efi 分区

从 ubuntu live 环境启动后：

lsblk -f

假设：

/dev/nvme0n1p2  根分区
/dev/nvme0n1p1  efi 分区

实际机器可能使用 lvm、luks、raid 或独立 /boot，应以 lsblk -f 的真实结果为准。

3.2 挂载原系统

挂载根分区：

sudo mount /dev/nvme0n1p2 /mnt

uefi 机器挂载 efi 分区：

sudo mkdir -p /mnt/boot/efi
sudo mount /dev/nvme0n1p1 /mnt/boot/efi

如果有独立 /boot：

sudo mount /dev/<boot-partition> /mnt/boot

3.3 绑定运行环境

推荐使用递归绑定，避免遗漏 /dev 下的子挂载：

sudo mount --rbind /dev  /mnt/dev
sudo mount --make-rslave /mnt/dev
sudo mount -t proc  /proc /mnt/proc
sudo mount --rbind /sys  /mnt/sys
sudo mount --make-rslave /mnt/sys
sudo mount --rbind /run  /mnt/run
sudo mount --make-rslave /mnt/run

确认 dns：

cat /mnt/etc/resolv.conf

现代 ubuntu 往往使用 systemd-resolved 管理该文件，不要无条件覆盖原有符号链接。

3.4 进入 chroot

sudo chroot /mnt /bin/bash

进入后先确认你操作的是原系统：

ls /boot
ls /lib/modules
dpkg --audit
dkms status

再按需修复：

dpkg --configure -a
apt-get -f install
update-initramfs -u -k all
update-grub

3.5 grub 本身损坏时

uefi 示例：

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

update-grub

legacy bios 示例通常是把 grub 安装到整块磁盘，而不是某个分区：

grub-install /dev/sda
update-grub

执行 grub-install 前必须确认启动模式、目标磁盘和 efi 挂载点。把命令复制到错误磁盘上，可能影响其他系统的引导。

3.6 正确退出并卸载

退出 chroot：

exit

按相反顺序卸载：

sudo umount -r /mnt/run  2>/dev/null || true
sudo umount -r /mnt/sys  2>/dev/null || true
sudo umount /mnt/proc    2>/dev/null || true
sudo umount -r /mnt/dev  2>/dev/null || true
sudo umount /mnt/boot/efi 2>/dev/null || true
sudo umount /mnt/boot     2>/dev/null || true
sudo umount /mnt

如果提示 busy：

sudo fuser -vm /mnt

检查是否仍有终端或进程停留在 /mnt 中。

四、什么时候需要重新安装内核包

如果确认新内核文件不完整，可以重新安装对应包。

先查询：

dpkg -l | grep "$new_kernel"

常见包包括：

• linux-image-<version>；
• linux-modules-<version>；
• linux-modules-extra-<version>；
• linux-headers-<version>。

重新安装内核和基础模块：

sudo apt install --reinstall \
  "linux-image-$new_kernel" \
  "linux-modules-$new_kernel"

部分通用内核还需要额外模块包：

sudo apt install --reinstall \
  "linux-modules-extra-$new_kernel"

随后重新生成：

sudo update-initramfs -u -k "$new_kernel"
sudo update-grub

包名要以当前系统仓库和安装状态为准，可以先核对：

apt-cache policy "linux-image-$new_kernel"

五、新内核没修好时，暂时让旧内核成为默认项

最安全的临时方案，是每次开机从 grub 手动选择旧内核。

需要长期暂时固定时，先备份：

sudo cp /etc/default/grub \
  /etc/default/grub.backup

查看真实菜单路径：

grep -e "^menuentry|^submenu" \
  /boot/grub/grub.cfg

可以使用 grub saved entry 机制：

sudo grub-set-default \
'advanced options for ubuntu>ubuntu, with linux <old-version>-generic'

并确保 /etc/default/grub 中设置：

grub_default=saved

然后：

sudo update-grub

菜单标题因机器而异，不要直接复制别人电脑上的版本字符串。

六、恢复之后必须做的验收

一次启动成功，只能说明“这次碰巧进来了”，还不能证明修复完成。

6.1 确认内核版本

uname -r

6.2 检查本次启动错误

sudo journalctl -b -p err
sudo journalctl -b -k -p err

6.3 检查失败单元

systemctl --failed

6.4 检查 dkms

dkms status

6.5 检查关键模块

lsmod | head
lspci -k

单独检查模块信息：

modinfo <module-name>

6.6 检查磁盘和挂载

findmnt
lsblk -f
df -h

6.7 至少完成一轮连续验证

建议验证：

• 新内核冷启动；
• 新内核正常重启；
• 旧内核仍能从 grub 进入；
• 网络、声音、显卡正常；
• 关键磁盘和外设正常；
• virtualbox、nvidia、zfs 等外部模块可用。

确认一切正常前，继续保留旧内核。

七、下次升级内核前，先把风险降下来

7.1 查看待升级内容

apt list --upgradable

模拟升级：

sudo apt-get -s upgrade

7.2 检查/boot

df -h /boot
ls -lh /boot

7.3 记录当前可用内核与 dkms

uname -r
dpkg -l 'linux-image-*' | grep '^ii'
dkms status

7.4 远程服务器必须保留带外入口

升级远程服务器内核前，至少确认一种不依赖 ssh 的恢复通道：

• 云厂商串口控制台；
• ipmi、idrac、ilo；
• 虚拟机控制台；
• 救援模式；
• 能把系统盘挂到另一台机器的能力。

只有 ssh、没有控制台时，一旦内核启动失败，远程操作会直接中断。

7.5 不要一次改变太多关键变量

不要在同一个维护窗口同时做：

• 升级内核；
• 删除全部旧内核；
• 修改 grub 参数；
• 更新显卡驱动；
• 调整磁盘分区。

每次只改变一类关键内容，失败后才能快速定位和回滚。

八、最常见的错误做法

8.1 直接删除内核文件

手工删除 /boot/vmlinuz-*、/boot/initrd.img-* 或 /lib/modules/*，会让包管理器记录与实际磁盘文件不一致。

内核应该通过包管理器安装和卸载。

8.2 在唯一可启动内核上执行自动清理

先检查当前内核和模拟删除列表：

uname -r
sudo apt autoremove --dry-run

8.3 对已挂载根分区直接fsck

文件系统修复应在未挂载状态、recovery mode 或 live 环境中进行。

8.4 黑屏就只重装显卡驱动

黑屏可能与显卡有关，但 (initramfs)、根 uuid 不存在和 vfs panic 显然是不同层的问题。

8.5 把nomodeset当永久方案

它适合临时进入系统和缩小问题范围。长期方案仍然是正确的驱动、模块签名和启动参数。

8.6 只看当前启动日志

使用旧内核成功启动后：

journalctl -b

看到的是当前正常启动。要看上一轮失败记录，应使用：

journalctl -b -1

九、恢复流程速查

可以把整个思路记成一句话：

先保住旧内核，再判断故障层；先修包、模块和 initramfs，最后再动 grub 和默认启动项。

总结

当旧内核无法提供完整操作环境时，恢复路线应该逐级推进：

initramfs shell 检查根设备 → recovery mode 修复包和启动文件 → live usb 挂载原系统 → chroot 重建 initramfs 与 grub

整个过程中，最容易出错的不是命令本身，而是对设备名、uuid、efi 分区、lvm、加密卷和挂载状态判断错误。

恢复成功后不要立刻清理旧内核。先完成冷启动、重启、网络、显卡、磁盘、dkms 和关键外设验证，再决定是否删除故障内核或调整默认启动项。

以上就是linux系统彻底进不去的救援指南(initramfs、recovery与chroot)的详细内容，更多关于linux系统彻底进不去的资料请关注代码网其它相关文章！