- baijamin2026-09-0153389
家用N100跑的PVE,跑了一个ikuai,openwrt,debian12。没开公网访问,看到铺天盖地的pve 0 day漏洞,所以我需要升级最新版本吗,怎么无损升级有教程不。 ^-^
2026.9.1 22:49更新,全程codex 5.6 SOL 高 自动升级,从8.1.10升级到8.4.21最后升级到9.2.11,全程未干预仅手动重启了两次proxmox,中间有备份到飞牛。从开始到结束消耗了20%周额度。
主楼 - 丿啦灬啦啦2026-09-0120542
官网就有教程,随便问主流ai都能回答的没有幻觉
- baijamin2026-09-0153389
- 丿啦灬啦啦2026-09-0120542
多个ai交叉验证,你把一个ai给的方案发给另一个ai
- TakeEasy2026-09-0114631
让codex搞
- baijamin2026-09-0153389
发布于2026/9/1 20:59:45
让codex搞@丿啦灬啦啦 #4 发布于2026/9/1 21:00:27
@baijamin #2 多个ai交叉验证,你把一个ai给的方案发给另一个ai我看看让它尝试一次,希望他别犯傻
- TakeEasy2026-09-0114631
早就完全托管了,不知道多久没ssh过,感觉比网上写的几把教程靠谱多了
- pen-pik2026-09-017183
我现在也是在考虑要不要升级
- baijamin2026-09-0153389
- pen-pik2026-09-017183
主要是我的pve,早期配置的时候,网络结构改了不少,还有硬件直通啥的,现在好赖是正常跑着类,怕给升炸咯 ^-^
- baijamin2026-09-0153389
发布于2026/9/1 21:04:42
@baijamin #7 主要是我的pve,早期配置的时候,网络结构改了不少,还有硬件直通啥的,现在好赖是正常跑着类,怕给升炸咯 ^-^我也是怕炸 ^-^ 不过我已经让codex研究着无损升级方案了
- pen-pik2026-09-017183
- armyjun2026-09-017522
不涉及内核都好说
- miko2026-09-0122127
- 我是校长啊2026-09-0112888
我的怎么是9.1.1 ^-^ ^-^
- 東方不败2026-09-0177183
我的pve已经all in boom了两次了,这次不随便动内核了
- 我是校长啊2026-09-0112888
这个结果反而是好事:pve-apt-hook 阻止了这次操作,所以 PVE 并没有被卸载。
关键在这里:
REMOVING:
corosync
libknet1t64
...
proxmox-ve
pve-cluster
pve-manager
qemu-server
APT 认为你安装旧的 libknet1 会导致当前 PVE 9 的一大批核心包被删除。于是 Proxmox 自带的保护机制拦截了操作。
而:
dpkg --audit
没有任何输出,说明当前 dpkg 包状态没有处于半安装/损坏状态。
现在不要做这两件事
不要:
touch /please-remove-proxmox-ve
更不要:
apt purge proxmox-ve
否则真的会把 PVE 核心组件往卸载方向推进。
你前面这台机器是:
Proxmox VE 9.2.0
pve-manager 9.2.11
kernel 6.17.2-1-pve
所以你现在的问题本质上是:
PVE 9 使用的是 libknet1t64,而你手动要求安装旧的 libknet1。
APT 为了满足你的明确要求,计算出了一个非常危险的依赖解决方案:删除新版 libknet1t64 以及整个 PVE 依赖链。
这不是正常的修复方法。
先执行这个
apt policy libknet1 libknet1t64
再执行:
dpkg -l | grep -E 'libknet|corosync|proxmox-ve'
把这两条的完整输出贴给我。
我先确认你现在到底是 libknet1t64 什么版本,以及为什么系统里会出现 libknet1 可安装但会触发整个 PVE 删除。
目前先不要再安装/卸载任何 PVE、corosync、libknet 相关包。
小心啊,一步步来的,也差点boom了 ^-^
