最近抽空把家里的 Proxmox VE 从 8.x 升级到了 9.x，整个过程比想象中要顺利，但也踩了不少小坑。这篇文章就把我的升级流程和一些心得整理出来，希望能帮到同样打算升级的朋友。
 
一、升级前一定要做的事
 
在动手之前，有几件事必须做好：
 
1. 完整备份所有虚拟机和容器，最好备份到外部存储，并在测试环境验证过能正常恢复。
2. 备份配置文件，尤其是 /etc/pve、/etc/network/interfaces、/etc/passwd 等。
3. 确保系统已更新到最新的 Proxmox VE 8.4（版本号至少 8.4.1）。
4. 如果你用了 Ceph，必须先升级到 Ceph 19.2 Squid，否则不能继续。
5. 根分区至少预留 5 GB 可用空间，最好 10 GB 以上。
6. 如果只有 SSH 访问，强烈建议使用 tmux 或 screen 来防止连接中断。
 
二、运行 pve8to9 检查脚本
 
PVE 8.4 自带了一个非常有用的脚本 pve8to9，它会在升级前后帮你检查潜在问题。建议在整个升级过程中多次运行它：
 

 
这个脚本只会检查不会修改系统，所以放心跑。根据它的提示逐项排查，修复后再跑一次，确认问题已解决。
 
三、迁移/关机正在运行的虚拟机
 
如果是集群环境，升级某个节点前，记得把上面的重要 VM/CT 迁移到其他节点。需要注意的是：
 
从旧版 PVE 迁移到新版 PVE 一定没问题。
从新版 PVE 迁移回旧版 PVE 可能可以，但官方不支持。
 
四、更新 APT 软件源（重点！使用 no-subscription 源）
 
这是升级过程中最关键的一步。先把现有系统更新到最新：
 

 
pveversion 的输出应至少是 8.4.1。
 
1. 把 Debian 基础源替换为 Trixie
 

 
记得检查一下这两个文件，确保没有残留的 bookworm 源，有的话加 # 注释掉。
 
2. 添加 Proxmox VE 9 的 no-subscription 源
 
由于我使用的是免费的 no-subscription 源，需要新建一个 deb822 格式的源文件。直接执行以下命令：
 

 
添加完后，验证源是否生效：
 

 
确认无报错且能看到 trixie 的 no-subscription 源后，删除旧的 PVE 8 源文件（可能在 /etc/apt/sources.list 或 /etc/apt/sources.list.d/pve-install-repo.list 中），再次运行 apt update 和 apt policy 确认旧源已清除。
 
3. 更新 Ceph 源（如果使用了 Ceph）
 
如果你跑着 Ceph 超融合集群，也要切换到新的 no-subscription 源：
 

 
同样验证后删除旧的 ceph.list 文件。如果原来有 backports 行，也请删掉——升级过程未测试过 backports 包的兼容性。
 
4. 刷新包索引
 

 
确保没有任何报错。
 
五、开始升级系统
 
激动人心的时刻到了，运行：
 

 
这一步的耗时取决于磁盘性能，机械硬盘可能要一小时以上，SSD 通常几分钟就能搞定。
 
升级过程中会有几个交互式配置问题，我的处理建议如下：
 
/etc/issue → 选 No（保留当前版本），这个文件每次启动都会自动生成，影响不大。
/etc/lvm/lvm.conf → 如果你没手动改过，选 Yes（使用软件包维护者的版本）。
/etc/ssh/sshd_config → 如果没改过，选 Yes，会迁移掉废弃的 ChallengeResponseAuthentication 选项。
/etc/default/grub → 如果你自定义过内核参数，选 No（保留当前），并仔细对比差异。
/etc/chrony/chrony.conf → 如果没改过，选 Yes。
“重启服务无需询问？” → 默认即可，反正升级完要重启系统。
 

 
六、验证结果并重启
 
升级完成后，再次运行检查脚本：
 

 
如果没有严重问题，就可以重启了：
 

 
一定要重启，即使你之前在 PVE 8 上已经用过 6.14 内核。因为这次的内核是用新的编译器和 ABI 重新构建的，不重启可能导致兼容性问题。
 
七、升级后的注意事项
 
1. 清除浏览器缓存
 
升级完后打开 PVE Web 界面时，记得 强制刷新浏览器：
 
Windows：Ctrl + Shift + R
macOS：⌘ + Alt + R
 
2. 集群环境
 
逐个节点完成升级。
PVE 9 中 HA groups 已弃用，会被自动迁移到 HA rules。如果遇到问题，可以用 journalctl -eu pve-ha-crm 查看日志。
 
3. 可选：现代化源文件格式
 

 
执行后先选 “n” 预览变更，确认没问题再选 “Y” 应用。旧文件会被备份为 .list.bak，验证正常后可以删除。
 
八、我遇到的几个已知坑（重点踩坑记录）
 
1. 升级过程中想删除 proxmox-ve 元包
 
如果你在 Debian 上手动装的 PVE，并且安装了 linux-image-amd64，需要先删掉它：
 

 
2. GRUB 在 UEFI + LVM 下可能启动失败
 
如果是 UEFI 模式且根分区在 LVM 上，执行：
 

 
3. LVM Thin Pool 需要手动修复
 
如果重启后看到类似错误：
 

 
运行以下命令修复：
 

 
4. /etc/sysctl.conf 不再被读取
 
PVE 9 的 systemd-sysctl 不再读取 /etc/sysctl.conf。如果你之前在里面配置了内核参数（比如 IP 转发、rp_filter），请迁移到 /etc/sysctl.d/<编号>–<名称>.conf 中。
 
5. AMD 小主机务必提前安装 CPU 微码（amd64-microcode）
 
如果你使用的是 AMD 芯片的小主机（如 Ryzen 迷你主机），在换源升级前，强烈建议先临时切回 Debian 官方源安装微码补丁。先把源改为如下内容：
 

 
然后执行安装：
 

 
为什么要这么做？
PVE 9 搭载了最新的 6.14 内核，新内核在电源管理、虚拟化（AMD-V）调度以及修复底层硬件漏洞时，高度依赖最新的 CPU 微码（Microcode）。AMD 的小主机/迷你主机对微码版本非常敏感，如果没有提前打上微码补丁，升级重启后极大概率会遇到内核恐慌（Kernel Panic）、随机死机、C-states 电源管理导致的不稳定，甚至直接无法引导。由于 PVE 默认的 no-subscription 源有时可能未包含完整的 non-free-firmware 组件，手动指定官方 Debian 源并安装微码是最稳妥的“保命”操作。
 
6. pve8to9 报错提示 systemd-boot 元包冲突
 
在运行 pve8to9 –full 检测时，我遇到了这个报错：
 

 
解决方法：
使用以下命令彻底移除它并更新 GRUB，之后再次运行 pve8to9 –full 即可顺利通过检验：
 

 
为什么要这么做？
在 Debian 12 (Bookworm) 时代，systemd-boot 是一个包含引导工具的实体包；但到了 Debian 13 (Trixie)，它被拆分了，原来的包名变成了一个“元包（meta-package）”。这个元包自带了一些自动化钩子（hooks），会在系统后续升级时强制将 systemd-boot 设为默认引导加载程序。
然而，绝大多数 PVE 用户（非 ZFS 根分区）使用的是 GRUB 作为引导程序。如果不卸载这个元包，后续升级内核或其他底层包时，它可能会突然跳出来篡改你的引导配置，覆盖掉 GRUB，直接导致重启后找不到系统（变砖）。所以，用 apt purge 彻底移除它，并运行 update-grub 重新生成并巩固现有的 GRUB 引导菜单，是确保升级后能顺利开机的关键。
 
九、总结
 
整体来说，PVE 8 到 9 的升级还是比较顺滑的。我的建议是：
 
永远先备份，这是最重要的！
多次跑 pve8to9，升级前后都跑一次。
耐心处理配置文件的提问，不确定的先保留当前版本。
一定要重启，让新内核完整生效。