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 existDropped to a shell!(initramfs)

先执行：

cat /proc/cmdline

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

系统识别到哪些设备，接下来查看：

cat /proc/partitionsls /devls /dev/disk/by-uuid

如果完全找不到目标 UUID，可能存在以下原因：

• 没有加载存储驱动；
• 系统识别不到磁盘；
• 发生了 UUID 变化；
• 加密卷或 LVM 尚未激活；
• 旧 UUID 依然由 GRUB 传入。

1.2 结合硬件选择加载模块

常见示例：

modprobe nvmemodprobe ahcimodprobe virtio_blk

模块不应一次性全部随意加载，而要按实际硬件选择；加载完成后再次检查：

ls /dev/disk/by-uuid

相关模块可能未正确进入 initramfs；设备在加载后出现，便能说明这一点。

1.3 加密卷或 LVM 的场景

可以尝试以下操作，前提是根分区位于 LVM：

lvm pvscanlvm vgscanlvm vgchange -ay

先在 initramfs 中确认存在，再处理 LUKS 加密卷 cryptsetup，随后按照真实映射名称解锁；不同安装方式差异明显，不可照搬不匹配的设备名。

1.4 检查文件系统

目标文件系统必须先处于未挂载状态时，检查操作才是安全的。

以 ext4 为例：

fsck -f /dev/nvme0n1p2

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

不能把 ext4 命令套用于所有环境，因为 LVM、LUKS、Btrfs 与 XFS 各自需要不同的处理工具。

二、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 -aapt-get -f installupdate-initramfs -u -k allupdate-grubdkms 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/efisudo mount /dev/nvme0n1p1 /mnt/boot/efi

如果有独立 /boot：

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

3.3 运行环境的绑定

建议采用递归绑定，以免遗漏 /dev 下的子挂载：

sudo mount --rbind /dev  /mnt/devsudo mount --make-rslave /mnt/devsudo mount -t proc  /proc /mnt/procsudo mount --rbind /sys  /mnt/syssudo mount --make-rslave /mnt/syssudo mount --rbind /run  /mnt/runsudo mount --make-rslave /mnt/run

确认 DNS：

cat /mnt/etc/resolv.conf

不要直接覆盖原有符号链接，该文件在现代 Ubuntu 中往往交由 systemd-resolved 管理。

3.4 切入 chroot

sudo chroot /mnt /bin/bash

首先核实进入后操作的确实是原系统：

ls /bootls /lib/modulesdpkg --auditdkms status

再根据需要修复：

dpkg --configure -aapt-get -f installupdate-initramfs -u -k allupdate-grub

3.5 修复受损的 GRUB

以 UEFI 为例：

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

整块磁盘而非某个分区，通常才是 Legacy BIOS 示例安装 GRUB 的目标：

grub-install /dev/sdaupdate-grub

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

3.6 退出及卸载的正确顺序

离开 chroot：

exit

卸载时反向执行：

sudo umount -R /mnt/run  2>/dev/null || truesudo umount -R /mnt/sys  2>/dev/null || truesudo umount /mnt/proc    2>/dev/null || truesudo umount -R /mnt/dev  2>/dev/null || truesudo umount /mnt/boot/efi 2>/dev/null || truesudo umount /mnt/boot     2>/dev/null || truesudo 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 errsudo journalctl -b -k -p err

6.3 查看单元失败情况

systemctl --failed

6.4 核验 DKMS 状态

dkms status

6.5 核验所需关键模块

lsmod | headlspci -k

分别检查模块信息：

modinfo <module-name>

6.6 核验挂载与磁盘

findmntlsblk -fdf -h

6.7 连续验证至少进行一轮

建议验证：

• 新内核冷启动；
• 能用新内核正常重启；
• 从 GRUB 仍可进入旧内核；
• 显卡、网络、声音均正常；
• 外设与关键磁盘均正常；
• 外部模块均可用，包括 ZFS、NVIDIA、VirtualBox。

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

七、内核下次升级前先行控制风险

7.1 核对等待升级的内容

apt list --upgradable

模拟升级：

sudo apt-get -s upgrade

7.2 查看/boot状态

df -h /bootls -lh /boot

7.3 保存 DKMS 与当前可用内核信息

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

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

至少确认一种无需 SSH 的恢复通道，然后再升级远程服务器内核：

• 串口控制台由云厂商提供；
• iLO、IPMI、iDRAC；
• 虚拟机控制台；
• 救援模式；
• 具备把系统盘接入另一台机器的条件。

远程操作会在内核启动失败时直接中断，条件是仅有 SSH 而没有控制台。

7.5 关键变量不要同时改动太多

同一维护窗口内不要并行处理：

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

为了在失败后快速定位并回滚，每次应仅改动一类关键内容。

八、高频错误操作汇总

8.1 内核文件被直接删除

手工删除 /boot/vmlinuz-*、/boot/initrd.img-* 或 /lib/modules/*，结果是实际磁盘文件与包管理器记录无法对应。

内核的安装和卸载都应通过包管理器完成。

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

当前内核和模拟删除列表需先核验：

uname -rsudo apt autoremove --dry-run

8.3 已挂载根分区上直接运行fsck

未挂载状态、Live 环境或 recovery mode 才是进行文件系统修复的适当环境。

8.4 仅因黑屏便重装显卡驱动

显卡可能导致黑屏，不过 (initramfs)、VFS panic 与根 UUID 不存在显然分属不同问题层面。

8.5 永久使用nomodeset

它适用于临时进入系统并缩小排查范围，长期解决仍依赖正确的驱动、模块签名和启动参数。

8.6 仅检查本轮启动日志

旧内核顺利启动系统以后：

journalctl -b

当前看到的是成功启动记录；上一轮失败记录需要使用：

journalctl -b -1

九、快速查阅恢复流程

步骤	要做什么	常用命令或入口
1	先寻找可启动路径	GRUB 旧内核、recovery、Live USB
2	确认故障阶段	屏幕报错、journalctl -b -1 -k
3	检查基础状态	df -h、dpkg --audit、lsblk -f
4	检查驱动与模块	dkms status、lspci -k、DKMS 日志
5	修复启动文件	update-initramfs、update-grub
6	无法进入系统	Live USB 挂载并 chroot
7	完成验收	网络、磁盘、显卡、模块以及新旧内核

整个处理思路可以概括为一句话：

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

总结

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

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

命令本身并非整个过程最易出错之处，真正的风险是误判 LVM、UUID、设备名、挂载状态、加密卷和 EFI 分区。

是否删除故障内核或调整默认启动项，应等到冷启动、重启、显卡、网络、DKMS、磁盘和关键外设均验证完毕再决定；恢复成功后先保留旧内核。

本文详细说明了Linux系统彻底进不去时如何借助initramfs、recovery与chroot实施救援；如需更多相关资料，可继续查看本站其他Linux系统文章！

相关文章推荐:

• 解决linux系统内核升级后无法进入的问题
• mmap在Linux系统调用中的使用方法与基本概念
• Linux磁盘管理实战全解(挂载、LVM、文件系统与分区)
• 分享用于系统排查Linux下PostgreSQL数据库故障的Shell脚本
• 用systemctl为Linux系统服务设置开机自启动的方法