【经验分享】Ubuntu 服务器突然断电后出现 Kernel Panic：使用旧内核启动并修复 initramfs
关键词：Ubuntu、Kernel Panic、GRUB、initramfs、unknown-block(0,0)、断电恢复、旧内核启动
一、问题背景
服务器突然断电后，再次开机时无法正常进入 Ubuntu，屏幕显示如下错误：
KERNEL PANIC! Please reboot your computer. VFS: Unable to mount root fs on unknown-block(0,0)这类错误表示 Linux 内核在启动过程中无法找到或挂载根文件系统。
常见原因包括：
- 当前内核对应的
initramfs文件损坏或生成不完整； /boot分区空间不足；- GRUB 启动参数中的根分区 UUID 错误；
- 系统盘没有被 BIOS 或磁盘控制器识别；
- 突然断电导致文件系统或软件 RAID 状态异常；
- 新安装的内核本身存在启动问题。
本次故障中，旧版本内核可以正常启动，因此最终判断为：最新内核对应的 initramfs 很可能在断电后出现异常，而系统盘和根文件系统本身没有严重损坏。
二、进入 GRUB 启动菜单
开机时需要进入 GRUB 菜单。
如果一直按Esc进入了 BIOS，说明按键时间过早。可以退出 BIOS，等待主板 Logo 出现或刚消失时，再快速连续按几次Esc。
进入 GRUB 后，选择：
Advanced options for Ubuntu系统中显示了以下内核：
Ubuntu, with Linux 7.0.0-28-generic Ubuntu, with Linux 7.0.0-28-generic (recovery mode) Ubuntu, with Linux 6.17.0-40-generic Ubuntu, with Linux 6.17.0-40-generic (recovery mode)由于最新的7.0.0-28-generic无法启动，因此选择旧内核：
Ubuntu, with Linux 6.17.0-40-generic先选择普通启动项，不选择recovery mode。
旧内核成功进入系统，说明：
- BIOS 可以识别系统盘；
- GRUB 基本正常；
- 根分区大概率没有严重损坏；
- 问题主要集中在新内核或其 initramfs 文件。
三、确认当前运行的内核
进入系统后执行：
uname-r输出如下：
6.17.0-40-generic说明当前确实是通过旧内核启动的。
四、检查/boot分区空间
在修复 initramfs 之前，先检查/boot是否还有足够空间：
df-h/boot同时查看现有的内核和 initramfs 文件：
ls-lh/boot/vmlinuz-* /boot/initrd.img-*如果/boot已经达到100%，需要先清理旧内核，否则新的 initramfs 可能无法正常生成。
本次恢复过程中/boot空间正常，因此可以直接重建新内核的 initramfs。
五、重建新内核的 initramfs
切换到 root 用户：
sudo-i针对无法启动的内核重新生成 initramfs：
update-initramfs-u-k7.0.0-28-generic然后重新生成 GRUB 配置：
update-grub正常情况下会看到类似输出：
Found linux image: /boot/vmlinuz-7.0.0-28-generic Found initrd image: /boot/initrd.img-7.0.0-28-generic Found linux image: /boot/vmlinuz-6.17.0-40-generic Found initrd image: /boot/initrd.img-6.17.0-40-generic这说明 GRUB 已经重新识别到对应的内核和 initramfs 文件。
完成后重启服务器：
reboot本次重启不再手动选择旧内核，而是让 GRUB 默认启动最新的：
Ubuntu, with Linux 7.0.0-28-generic系统成功进入 Ubuntu，故障恢复。
六、验证修复结果
系统启动后再次检查当前内核：
uname-r如果输出：
7.0.0-28-generic说明新内核已经恢复正常。
进一步验证 initramfs 是否可以被正常解析：
sudolsinitramfs /boot/initrd.img-7.0.0-28-generic>/dev/null\&&echo"initramfs 检查通过"如果看到：
initramfs 检查通过说明生成的 initramfs 文件结构基本正常。
七、检查断电是否留下其他问题
虽然服务器已经能够启动，但突然断电还可能导致软件包、文件系统、RAID 或磁盘状态异常，因此建议继续完成以下检查。
1. 检查软件包状态
sudodpkg--configure-asudoapt-finstallsudodpkg--audit如果dpkg --audit没有输出，通常表示没有处于异常状态的软件包。
更新软件源索引：
sudoaptupdate2. 检查分区空间和 inode
df-hT/ /boot /boot/efi2>/dev/nulldf-i/ /boot2>/dev/null重点确认：
- 根分区没有达到
100%； /boot分区没有达到100%；- inode 使用率没有达到
100%。
3. 检查启动错误日志
查看本次启动中的严重错误：
sudojournalctl-b-perr..alert --no-pager筛选磁盘、NVMe 和文件系统错误：
sudojournalctl-k-b--no-pager|\grep-Ei'I/O error|Buffer I/O|EXT4-fs error|XFS.*corrupt|nvme.*(error|timeout|reset)|blk_update_request'如果第二条命令没有输出，通常是好现象。
如果出现以下关键词，则需要进一步排查：
I/O error EXT4-fs error Buffer I/O error nvme timeout controller reset filesystem corruption需要注意：不要在根分区处于挂载状态时直接运行fsck。
八、检查软件 RAID 状态
如果服务器使用了 Linux 软件 RAID，例如/dev/md0，断电后应检查阵列是否降级或正在同步：
cat/proc/mdstat正常阵列可能显示：
[UUUU]如果显示：
[UU_U]说明有一块成员盘缺失。
如果输出中出现：
recovery resync reshape check说明阵列正在恢复或同步。此时应保持服务器持续供电，不要频繁重启。
查看详细状态：
sudomdadm--detail/dev/md0正常情况下可以看到：
State : clean如果正在同步，则可能显示：
State : clean, resyncing九、检查 NVMe 硬盘健康状态
先查看磁盘设备名：
lsblk-oNAME,SIZE,MODEL,FSTYPE,MOUNTPOINTS安装检查工具：
sudoaptinstallnvme-cli smartmontools查看 NVMe 列表：
sudonvme list假设系统盘是/dev/nvme0，检查 SMART 信息：
sudonvme smart-log /dev/nvme0重点关注：
critical_warning media_errors num_err_log_entries percentage_used比较理想的状态是：
critical_warning : 0 media_errors : 0也可以使用：
sudosmartctl-a/dev/nvme0实际设备名应以nvme list或lsblk的输出为准。
十、不要立即删除旧内核
虽然最新内核已经恢复，但暂时不要删除能够正常启动的：
6.17.0-40-generic它可以作为备用内核。
建议至少满足以下条件后，再考虑清理旧版本：
- 最新内核能够正常启动；
- 连续重启两次均无异常；
- 日志中没有磁盘或文件系统错误；
- 软件 RAID 没有降级；
- NVMe SMART 状态正常。
恢复后暂时不要急着执行：
sudoaptautoremove--purge避免系统自动删除已验证可用的备用内核。
十一、最终恢复流程总结
本次故障的核心恢复流程如下：
服务器突然断电 ↓ 新内核启动时出现 Kernel Panic ↓ 进入 GRUB 的 Advanced options for Ubuntu ↓ 选择旧内核 6.17.0-40-generic ↓ 成功进入系统 ↓ 重建 7.0.0-28-generic 的 initramfs ↓ 更新 GRUB ↓ 重新启动 ↓ 新内核恢复正常对应的核心命令只有几条：
uname-rsudo-idf-h/boot update-initramfs-u-k7.0.0-28-genericupdate-grubreboot
