Proxmox VE (PVE) 内核误删/损坏修复过程记录

不配头图了，这篇文章本不在计划内，开始写这个内容时已是凌晨 2 点 15 分。

本来今天的计划是用我刚购置的 UPS，跟我的 PVE 服务器进行绑定，模拟下断电的关机效果，事情就结束了。

就当我准备安装 UPS 需要的组件前，我擅自更新了 PVE 系统至 9.1.7 版本，更新完后，又擅自相信DeepSeek 给的命令，进行了“垃圾清理”，罪魁祸首如下：

结果直接导致 PVE 重启后无法进入系统，报错如下：

整个人都懵了……要知道，这里面运行了飞牛 NAS、网站的各类服务等，虽有定时备份，但能救回多少，尚未可知，因为手机端没有安装 Gemini，就用元宝拍照问解决办法，结果还给了一些危言耸听、不讲逻辑的判断：

然后，后面给了一堆类似于要重装、要先备份等等一类的话，我当时又懵了，不过细细一想，我就删了垃圾，删个内核我认，怎么还把分区表给变了？

于是立马转向 Gemini，手机拍照，通过隔空投送传至电脑，再一步一步操作，果然靠谱，有惊无险，顺利解决。

DeepSeek 和元宝还有很长路要走啊！

说回正题：

事件过程

我为了接入 UPS，顺手更新了最新版 PVE (Proxmox VE 9.1.7) 服务器时，顺手跑了一条批量清理旧内核的命令。
结果，这条命令把系统里所有的实体内核文件全给扬了！重启机器后，就是报错：

KERNEL PANIC! 
Please reboot your computer. 
VFS: Unable to mount root fs on unknown-block(0,0)

这个典型的 VFS: Unable to mount root fs 报错，通常意味着引导程序虽然启动了，但在指定的路径下找不到操作系统的内核文件或者 initramfs 镜像。

经过几个 AI 的询问，最后 Gemini 给我吃了一颗定心丸，只要硬盘没坏，数据都还在，可以利用 PVE 的安装介质进行“无损重建”。

修复过程

准备工作

准备一个空 U 盘，刚好以前有一个 ventoy 重装系统工具，从官网下载了 PVE 最新版本的 ISO 镜像，放进去就可以了。

具体步骤

步骤1：进入 Debug 调试模式

将制作好的 PVE 安装 U 盘插入电脑，并在 BIOS 中选择从 U 盘启动。
在 PVE 的图形安装菜单中，选择 Install Proxmox VE (Debug mode) 。
屏幕会开始滚动代码，随后会第一次停留在 ~ # 提示符。注意，此时系统只加载了极简环境，不要在这里操作，直接按键盘 Ctrl + D（或输入 exit）让它继续加载。
等待屏幕第二次停下，出现类似 root@proxmox:/# 的提示符时，真正的救援环境才算准备就绪。

步骤 2：挂载原系统分区

需要把硬盘里的残缺系统和必要的虚拟环境挂载到临时目录 /mnt 下。由于 PVE 默认使用 LVM 架构，操作如下：

# 1. 激活 LVM 逻辑卷
vgchange -ay

# 2. 挂载 PVE 的根目录
mount /dev/pve/root /mnt

# 3. 挂载 EFI 引导分区
# 注意：使用 lsblk -f 或 fdisk -l 确认你的 EFI 分区路径。
# 我的系统盘是 NVMe 固态，EFI 分区在第二个，所以是 nvme0n1p2
mount /dev/nvme0n1p2 /mnt/boot/efi

# 4. 挂载系统运行所必需的虚拟目录（直接复制全套）
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run
剩余 11 行代码

步骤3：切入原系统 (Chroot) 并唤醒网络

因为我发现网线等没亮，吓得我以为网卡有故障，后来询问 Gemini 后得知，因在救援模式下，网卡默认是休眠的，需要手动配置网络以便稍后下载内核。

# 切换进原系统环境
chroot /mnt

# 1. 配置临时 DNS，否则无法解析域名
echo "nameserver 8.8.8.8" > /etc/resolv.conf
echo "nameserver 114.114.114.114" >> /etc/resolv.conf

# 2. 查看网卡名称并唤醒它
ip link
# 假设查到的网卡名是 enp3s0，执行以下命令将其启动（此时网口灯应亮起）
ip link set enp3s0 up

# 3. 配置局域网静态 IP 以连通外网
# (假设你的路由器网关是 192.168.31.1，给你自己分配一个 .254 的 IP)
ip a add 192.168.31.254/24 dev enp3s0
ip route add default via 192.168.31.1

# 测试网络是否畅通
ping -c 3 baidu.com
剩余 14 行代码

步骤4：安装真实内核 (核心环节)

网络通畅后，就可以开始重装内核了。这里耽误太长时间，一方面是为了确定版本号，一方面是一直说我已经安装有内核了，其实只是一个类似于快捷方式的存在，真实的内核其实是什么没有的。

在 PVE 中，proxmox-default-kernel 或 proxmox-kernel-6.17 这种包往往只是一个“快捷方式”（元软件包）。如果直接 apt install 它们，系统会认为这些快捷方式已经存在，从而提示 Installing: 0，根本不会去下载真正几百兆的内核镜像。

需要核查出最底层的实体内核包：

# 1. 更新软件源
apt update

# 2. 查询当前默认内核依赖的实体包名
apt depends proxmox-default-kernel
# (在输出中找到带有具体版本号并以 -pve 结尾的包，例如：proxmox-kernel-6.17.13-2-pve)

# 3. 强制重装该实体内核
apt install --reinstall proxmox-kernel-6.17.13-2-pve
剩余 4 行代码

敲下回车后，只要看到 Download size 显示需要下载 100多MB 的文件，就说明成功抓取到了真正的内核。

步骤5：刷新引导并重启

内核安装完成后，通常会自动触发相关的钩子脚本，但为了安全起见，手动执行以下两步将新内核写入引导分区：

# 重新生成 initrd 镜像
update-initramfs -u -k all

# 刷新 PVE 引导列表 (如果提示 Skipping ESP sync 属于正常现象，无需理会)
proxmox-boot-tool refresh

一切妥当，准备退出重启：

# 退出 chroot 环境
exit

# 卸载所有已挂载的目录
umount -l /mnt/dev /mnt/proc /mnt/sys /mnt/run /mnt/boot/efi /mnt

# 重启服务器
reboot
剩余 3 行代码

当屏幕一黑开始重启时，果断拔掉 U 盘，系统成功救活！

PS：AI 使用要慎重啊！国内模型要慎重使用啊！ = =

本文已于 2026年05月02日更新