更新与大版本升级

PVE 有两种完全不同的「更新」，混为一谈是出事的开始。

类型	例子	风险	频率
小版本更新	8.2 → 8.3，安全补丁	低，偶尔需要重启	每月
大版本升级	8.x → 9.x（Debian 12 → 13）	高，是一次发行版升级	每两三年

两种都会中断服务

小版本更新如果动了内核，需要重启宿主机——所有客户机都会停。大版本升级期间更是整机不可用。

两种都要选维护窗口，都要先确认备份可用。

小版本更新

节奏

建议每月一次。积累太久再更新，一次要装的包太多，出问题不好定位。

流程

先看有什么更新：

apt update
apt list --upgradable

Web UI 也可以：节点 → Updates → Refresh，会列出可更新的包和变更说明。

然后更新：

apt full-upgrade

必须用 full-upgrade

PVE 的包依赖经常需要安装新包或移除旧包。普通 apt upgrade 会把这些「保留」（held back），导致更新不完整，长期下来会积累成一个很难处理的状态。

官方文档一贯推荐 apt full-upgrade（等价于 apt dist-upgrade）。

什么时候需要重启

看输出里有没有这些包：

• proxmox-kernel-* 或 pve-kernel-* → 需要重启
• systemd、核心库 → 建议重启

确认当前运行的内核和已安装的内核是否一致：

# 正在运行的
uname -r

# 已安装的
proxmox-boot-tool kernel list 2>/dev/null || dpkg -l | grep proxmox-kernel

两者不一致说明装了新内核但还没重启。

重启前的动作

# 1. 确认备份最近跑过且成功
#    数据中心 → 备份 → 任务日志

# 2. 正常关闭所有客户机（而不是让重启去强制停）
#    Web UI 逐台 Shutdown，或者：
for id in $(qm list | awk 'NR>1 {print $1}'); do qm shutdown $id; done
for id in $(pct list | awk 'NR>1 {print $1}'); do pct shutdown $id; done

# 3. 确认都停了
qm list; pct list

# 4. 重启
reboot

用 tmux 或 screen 跑长时间的操作

SSH 断线会中断正在执行的命令。更新和升级这类操作，先开一个 tmux 会话再跑：

tmux new -s upgrade
# 断线后重连
tmux attach -t upgrade

这一条在大版本升级时是必须的——那个过程可能持续很久。

重启之后

pveversion -v
systemctl --failed
qm list; pct list

确认没有失败的服务，客户机按 Start at boot 设置正常启动。

大版本升级

这是一次发行版升级

PVE 8 → 9 同时也是 Debian 12 → 13。它会替换系统上几乎所有的包，改变配置文件格式（比如 APT 源从 .list 变成 .sources），可能改变默认行为。

不能直接 apt full-upgrade 就完事。 有完整的官方流程，必须照着走。

前提条件

开始之前，全部满足：

1. 当前已经是上一个大版本的最新小版本。 从 8.4 升 9 是支持的路径，从 8.0 直接升不是。先 apt full-upgrade 到最新的 8.x。
2. 备份可用且验证过。 不是「有备份」，是最近做过恢复演练。
3. /etc/pve 已归档。
4. 有物理控制台或带外管理。 升级中途出问题，网络可能起不来。
5. 磁盘空间充足。 一次大版本升级要下载和解压大量包，/ 分区至少留出几个 GB 到十几个 GB 的余量。先 df -h / 确认。
6. 时间窗口充足。 按小时计，不是按分钟。

第一步：跑官方检查工具

PVE 为每次大版本升级提供一个检查脚本。从 8 升 9：

pve8to9 --full

这个工具是升级流程的核心

它会检查几十项内容：软件源配置、存储状态、集群 quorum、正在运行的客户机、已知的不兼容配置、空间是否足够、有没有用到被移除的特性。

输出分三类：

• PASS —— 没问题
• WARN —— 需要你看一眼，判断是否影响
• FAIL —— 必须先解决，不能继续升级

把所有 FAIL 处理掉，把所有 WARN 都读一遍并理解，再往下走。 这个工具报出来的问题，都是升级过程中真的会出事的。

反复跑这个命令，直到没有 FAIL。

第二步：停掉客户机

虽然理论上某些场景可以在线升级，但在单机环境下，建议把所有客户机正常关闭。升级过程中宿主机的状态不稳定，运行中的客户机可能遇到 IO 问题。

for id in $(qm list | awk 'NR>1 && $3=="running" {print $1}'); do qm shutdown $id; done
for id in $(pct list | awk 'NR>1 && $2=="running" {print $1}'); do pct shutdown $id; done

确认全部停止后再继续。

第三步：更新软件源

把 Debian 和 PVE 的源都从旧代号改到新代号（例如 bookworm → trixie），同时 PVE 9 的源格式变成了 deb822。

这一步的细节以官方升级文档为准

源文件的路径、格式和密钥环名称在版本之间会变。本站不提供可直接复制的完整命令，因为写死的版本代号和路径很快会过时，照抄一份过时的命令是升级失败的常见原因。

请对照官方 Wiki 上对应版本的升级页面（搜索 Upgrade from 8 to 9 之类的条目）操作。配置软件源一文解释了格式的差异，可以配合阅读。

改完之后：

apt update

第四步：执行升级

apt dist-upgrade

过程中会问配置文件冲突

升级会多次询问「配置文件已被本地修改，是保留你的版本还是用维护者的版本」。

原则：你没改过的文件，用维护者的新版本（通常是默认选项）。你改过且知道为什么改的，保留你的版本，但记下来，升级完要重新检查那些改动在新版本下是否还有意义。

拿不准时选择查看差异（通常有个 D 选项），看完再决定。

这个过程可能持续很久。这就是为什么要在 tmux 里跑。

第五步：重启并验证

reboot

起来之后：

# 1. 版本正确
pveversion -v

# 2. 没有失败的服务
systemctl --failed

# 3. 存储都在
pvesm status

# 4. 网络正常
ip -4 addr show

# 5. 客户机列表完整
qm list; pct list

然后逐台启动客户机并验证，不要一次全开。先开最不重要的那台，确认正常再开下一台。

万一升级失败

大版本升级失败很难「降级回去」

Debian 不支持降级。系统卡在升级中途的状态时，通常的出路是：

1. 继续修复：多数情况下问题是某个包的依赖冲突，apt -f install 或手动处理能解决。看 apt 的报错，通常说得很清楚。
2. 重装 + 恢复备份：装一台新的 PVE 9，从备份恢复所有客户机。这就是为什么前提条件里备份排在最前面。

没有第三条路。 这也是「备份没验证过就不要开始升级」的原因。

自动更新要不要开

PVE 默认会装 unattended-upgrades 之类的机制来自动装安全更新（具体行为随版本不同）。

取舍：

• 开着：安全补丁及时，但可能在你没准备的时候改动系统。
• 关掉：完全可控，但容易拖着不更新。

家庭环境建议保持默认，但每月手动检查一次。关键是不要出现「半年没更新」的情况——那比自动更新的风险大得多。

检查结果

给自己定一个节奏：

频率	做什么
每月	apt update && apt list --upgradable，看有没有重要更新
每月	跑一遍健康检查清单
每季度	做一次恢复演练
大版本发布后	不要急着升。等几个小版本，看社区反馈，再规划升级

不要追新

PVE 大版本刚发布时，各种边缘场景的问题还没暴露完。家庭环境等 x.1 或 x.2 再升级，是稳妥的做法。当然也不要拖到旧版本停止维护——那时候安全更新就没有了。

延伸阅读

• 健康检查清单
• 配置软件源
• 恢复演练