【经验分享】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针对无法启动的内核重新生成 initramfsupdate-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\echoinitramfs 检查通过如果看到initramfs 检查通过说明生成的 initramfs 文件结构基本正常。七、检查断电是否留下其他问题虽然服务器已经能够启动但突然断电还可能导致软件包、文件系统、RAID 或磁盘状态异常因此建议继续完成以下检查。1. 检查软件包状态sudodpkg--configure-asudoapt-finstallsudodpkg--audit如果dpkg --audit没有输出通常表示没有处于异常状态的软件包。更新软件源索引sudoaptupdate2. 检查分区空间和 inodedf-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-EiI/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
