Linux内核升级后无法启动的解决方案

前言

Ubuntu 更新内核后若无法启动，最稳妥的做法是先保留进入系统的通道，而不是立即删除内核、重装驱动或不断强制关机。

本文主要处理可以正常启动的仍是旧内核的情况。先定位启动链，再按顺序核查包管理状态、失败日志、/boot 空间、Secure Boot、DKMS、GRUB 参数、根文件系统 UUID 与 initramfs。

处理原则：先用旧内核恢复可操作环境，再根据证据修复新内核。旧内核在新内核完成验证前不要删除。

以下问题是本文的解决重点：

• 从 GRUB 进入旧内核，以应对新内核启动失败；
• 定位故障阶段，判断属于驱动、initramfs、内核还是 GRUB；
• 为指定内核重新生成 GRUB 与 initramfs；
• 对 UUID、进行核验fstab 与 root= 启动参数；
• 解决由 Secure Boot、headers 或 DKMS 引发的模块故障。

一、理解启动链：判断报错所在层级

Ubuntu 从开机通电到进入桌面，大致需要经过以下阶段：

启动阶段	主要工作	常见故障表现
UEFI/BIOS	寻找启动项并完成硬件初始化	Ubuntu 启动项缺失或启动盘未找到
GRUB	传入启动参数并呈现内核菜单	选项有误、菜单损坏或 GRUB 菜单缺失
Linux Kernel	基础设备、内存与 CPU 的初始化	Kernel Panic、选定内核即刻重启
initramfs	寻找根文件系统并装入早期驱动	掉进 (initramfs)、根分区挂载失败、UUID 无法找到
systemd 与根文件系统	启动服务，同时挂载磁盘	emergency mode、fstab 挂载失败
驱动与桌面	外部模块、网卡与显卡的加载	VirtualBox/NVIDIA 模块不可用、无线网卡消失或黑屏

应先判断故障阶段，再选择相应工具。

• 若 GRUB 菜单缺失：核查 GRUB 与 UEFI 启动项；
• 进入 (initramfs)：先核验 initramfs、存储驱动、UUID 与根分区；
• 进入 emergency mode：重点查看 /etc/fstab 以及 systemd 中的失败单元；
• 若桌面显示前黑屏：后续考虑显示管理器、显卡模块与 nomodeset；
• 检查 Secure Boot、headers 与 DKMS，以处理新内核下消失的网卡或虚拟化模块。

这项判断虽然简单，却能减少后续大量无效操作。

二、先用仍可启动的旧内核进入系统

2.1 显示 GRUB 菜单

开机时尝试按住，适用于传统 BIOS 机器 Shift，通常在 UEFI 机器上需要连续按 Esc。固件启动速度因电脑而异，因此可能要尝试数次才能把握按键时机。

进入后从 GRUB 选择：

Advanced options for Ubuntu

例如，新旧内核以及对应的 recovery mode 一般都会列出：

• Ubuntu, with Linux 6.x.y-new-generic
• Ubuntu, with Linux 6.x.y-new-generic (recovery mode)
• Ubuntu, with Linux 6.x.y-old-generic
• Ubuntu, with Linux 6.x.y-old-generic (recovery mode)

先选择以普通方式启动旧内核的选项。只要旧内核仍能进入系统，后续检查与修复就会容易许多。

2.2 核实目前实际运行的内核

系统进入后优先执行：

uname -r

不要仅依据 GRUB 菜单中的选择，uname -r 显示的才是当前实际运行版本。

列出系统内已经安装的内核包：

dpkg -l 'linux-image-*' | grep '^ii'

然后检查 /boot 中是否同时保留新旧内核文件：

ls -lh /boot

重点关注：

• vmlinuz-<version>：内核镜像；
• initrd.img-<version>：initramfs 与之对应；
• config-<version>：内核配置；
• System.map-<version>：记录符号映射。

2.3 保留旧内核作为临时保障

此时的旧内核并非“占空间的旧文件”，它其实是系统最关键的恢复入口。

清理应等到至少满足这些条件：

• 连续启动新内核均正常；
• 虚拟化模块、磁盘、显卡与网络均正常；
• dkms status 没有异常；
• 可靠回退项在 GRUB 中依旧可见；
• /boot 根文件系统和均未报错。

先检查模拟结果，再进行自动清理：

sudo apt autoremove --dry-run

只有确认唯一可用旧内核与当前运行内核都不会被删除，才能决定是否执行：

sudo apt autoremove

不要在唯一能够启动的内核上做“自动清理实验”。

三、保留证据，别只看报错的最后一屏

3.1 核查历次启动记录

切换至旧内核后执行：

journalctl --list-boots

输出将列出最近多次启动记录，当前启动一般为 0，上一次为 -1，再上一次为 -2。

调取前一次启动的内核日志：

sudo journalctl -b -1 -k

仅查看错误级别：

sudo journalctl -b -1 -p err

检索高频关键字：

sudo journalctl -b -1 -k | grep -Ei 'panic|error|fail|timeout|nvme|ata|ext4|xfs|btrfs|firmware|nvidia|dkms'

journal 可能来不及写入日志，因为故障发生过早；这种情况下，云服务器串口日志、initramfs shell 输出和屏幕报错具有同等重要性。

3.2 以当前成功启动作为比较基准

调取正在运行的旧内核启动信息：

sudo dmesg -T | less

固件、模块、根分区和存储是观察重点：

sudo dmesg -T | grep -Ei 'nvme|ata|root|firmware|module|secure|iommu'

旧内核可以识别而新内核无法识别的设备，通常就是重要线索。

3.3 核验包管理有无被中断

包可能因磁盘写满、网络异常或内核升级期间断电而留下“尚未完成配置，但包已解压”的状态。

首先检查：

sudo dpkg --audit

继续完成未结束的配置：

sudo dpkg --configure -a

修复依赖：

sudo apt-get -f install

先保证软件源和网络可用，再运行需要下载软件包的命令。

3.4 核验根分区与/boot的可用空间

/boot 新内核包可能已安装，但 initramfs 没有完整生成；内核升级失败经常源于空间不足。

df -h /boot /

inode 也需随后核查：

df -i /boot /

如果更新期间出现：

No space left on device

不要只检查 / 的可用空间，单独挂载的 /boot 可能已经没有空间。

排查到这里时，先别急着重建所有东西。先确认磁盘空间、包状态和新内核目录完整，否则后面的 update-initramfs 仍会失败。

四、重建新内核的 initramfs 和 GRUB

4.1 initramfs 的具体职责

真正的根文件系统在内核刚运行时尚未挂载。作为临时早期用户空间，initramfs 通常装有以下内容：

• 磁盘识别所依赖的存储驱动；
• 用于 LUKS、RAID、LVM 等的工具；
• 驱动根文件系统所需内容；
• 根分区挂载所依赖的脚本；
• 启动流程转交真正根文件系统所需的逻辑。

以下问题可能在文件系统驱动、加密卷、LVM、VirtIO、AHCI 或 NVMe 未正确进入 initramfs 时出现：

Gave up waiting for root file system deviceALERT! UUID=... does not existKernel panic - not syncing: VFS: Unable to mount root fs

4.2 核实准备处理的内核版本

查看模块目录：

ls /lib/modules

假定故障内核为 6.x.y-new-generic，可预先定义变量：

NEW_KERNEL='6.x.y-new-generic'

确认相应目录存在：

test -d "/lib/modules/$NEW_KERNEL" && echo "modules directory exists"

随后核验 initrd 与内核：

ls -lh "/boot/vmlinuz-$NEW_KERNEL"        "/boot/initrd.img-$NEW_KERNEL"

4.3 重建或更新 initramfs

对现有 initramfs 进行更新：

sudo update-initramfs -u -k "$NEW_KERNEL"

对应 initrd 若完全缺失，可执行创建：

sudo update-initramfs -c -k "$NEW_KERNEL"

-u 表示更新，-c 代表创建。不要因为“重来一次”而直接手工删除 /boot/initrd.img-*，以免实际文件和包管理状态更难对应。

完成后进行检查：

ls -lh "/boot/initrd.img-$NEW_KERNEL"

4.4 核验关键模块是否位于 initramfs 中

lsinitramfs "/boot/initrd.img-$NEW_KERNEL" | less

检索 LVM、加密及常见存储组件：

lsinitramfs "/boot/initrd.img-$NEW_KERNEL"   | grep -Ei 'nvme|ahci|virtio|dm-crypt|cryptsetup|lvm'

这里不能只因“没搜到一个名字”便判断模块缺失并不可靠：驱动可能已直接编入内核，文件名也未必符合预期。更稳妥的是比较：

lspci -k

还要比较旧内核相应 initramfs 中的内容。

4.5 再次构建 GRUB 菜单

sudo update-grub

类似输出在正常情况下会出现：

Found linux image: /boot/vmlinuz-...Found initrd image: /boot/initrd.img-...

对应 initrd 若未找到，即使已有内核镜像，也应先处理 initramfs 的生成错误。

五、核验启动参数、fstab 与根文件系统 UUID

5.1 查明真正使用的 UUID

lsblk -f

或者：

sudo blkid

查看系统配置：

cat /etc/fstab

重点核对：

• 根分区 /；
• /boot；
• /boot/efi；
• swap 或 resume= 对应分区；
• 额外数据盘。

克隆磁盘、恢复快照、重建文件系统、调整 LVM、替换硬盘或手工修改分区，都可能导致 UUID 变化。

长期在 fstab 内写死应尽量避免 /dev/sdaX、/dev/nvme0n1pX。UUID 通常更加稳定，而名称可能随着设备枚举顺序的变化而改变。

5.2 检查 GRUB 传递的root=

grep -n "linux.*root=" /boot/grub/grub.cfg | head

grub.cfg 不宜长期直接手动修改，因为一般由工具生成。需要修正 /etc/default/grub、/etc/fstab 或相关脚本，之后再运行：

sudo update-grub

5.3 临时编辑 GRUB 参数

先从 GRUB 菜单选定启动项，随后按 e，找到以 linux 开头的那一行。

临时诊断可采用这些操作：

• 删除 quiet splash，让详细启动日志直接显示出来；
• 加入 nomodeset，用来确认是否停在显卡模式设置阶段；
• 检查 root=UUID=... 与实际根分区是否一致；
• 检查错误的 resume=、显卡参数、模块黑名单或 IOMMU。

配置不会被自动写回，因为临时修改仅对当前这次启动生效。

nomodeset 它能协助进入系统并明确排查方向，但通常不能作为显卡问题的最终处理方案。

六、DKMS：新内核安装后驱动为何没有跟上

6.1 内核版本与 DKMS 模块的绑定关系

DKMS 用于 NVIDIA、ZFS、VirtualBox 以及部分网卡驱动。模块并非随内核镜像自然存在，而是必须分别针对每一个内核版本构建。

检查状态：

dkms status

可能看到：

module/version, old-kernel, installedmodule/version, new-kernel, added

added、built 和 installed 属于不同情况。目标版本通常要达到，才能让该模块在新内核下正常工作 installed 状态。

6.2 查看 DKMS 的构建日志

日志通常位于：

/var/lib/dkms/<module>/<version>/build/make.log

查找全部日志：

sudo find /var/lib/dkms -name make.log -type f -print

查看最近的错误：

sudo tail -n 120   /var/lib/dkms/<module>/<version>/build/make.log

常见原因：

• 新内核缺少 headers；
• 驱动版本与新的内核 API 不兼容；
• 构建环境与编译器版本无法匹配；
• 未签名模块被 Secure Boot 拦截；
• /boot 或 /var 空间不足；
• 配置包的流程发生中断。

6.3 重新构建前安装 headers

核验 headers：

dpkg -l "linux-headers-$NEW_KERNEL"

缺少时进行安装：

sudo apt install "linux-headers-$NEW_KERNEL"

重新构建：

sudo dkms autoinstall -k "$NEW_KERNEL"

完成后重建 initramfs 和 GRUB：

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

6.4 Secure Boot 也可能让模块“存在但无法加载”

查看状态：

mokutil --sb-state

查看内核日志：

sudo dmesg | grep -Ei 'secure boot|verification failed|module verification'

即使模块文件已经生成，加载仍可能失败；此时原因未必是编译，而可能来自信任链和签名。

唯一的处理方式并不是关闭 Secure Boot。具体方案应根据机器安全要求、驱动来源及 MOK 签名流程确定。

总结

旧内核仍可启动时，系统文件、日志和包管理工具都能正常使用，修复条件其实很好；此时不要急于删除新内核，也不要同时执行所有修复命令。

更稳妥的顺序是：

通过旧内核进入系统 → 保存故障日志 → 磁盘空间与包状态检查 → 重新生成 initramfs → 核对 UUID 和 GRUB 参数 → 修复 DKMS → 再次测试新内核

至少保留一个经过启动验证的旧内核，然后才算完成修复。若旧内核、桌面环境与普通模式均无法进入，则应改用 Live USB + chroot、recovery mode 或 initramfs shell；操作方法将在下篇介绍。

以上详细介绍了Linux内核升级后无法启动的解决方案，更多Linux内核升级后启动失败的相关资料请关注本站其他文章！

推荐阅读:

• 实现Linux系统内核升级的三种方式
• 解决linux系统因内核升级而无法进入的问题
• linux操作系统升级内核的完整过程
• 手动升级deepin linux内核的方法