第 2 篇 / 共 8 篇

本文来自脱敏知识整理，区分历史记录与实时核验；未经核对请勿直接套用命令。

02｜PVE 安装、软件源、升级与内核维护：避开过时教程

知识分类：系统维护｜2026-10-17 整理｜官方规则已复核；主机当前软件源、引导方式未检查｜生产命令默认禁止自动执行。

一、安装前核对的不是“教程发布日期”

PVE 基于 Debian 与 Linux/KVM。安装时需要确认 CPU 虚拟化能力、可靠的系统盘、RAM、管理网络和物理控制台。BIOS/UEFI 里的 Intel VT-x/AMD-V 通常是虚拟机基础功能所需；VT-d/IOMMU、SR-IOV、Above 4G Decoding 只在相应设备直通方案中评估，不应因为某个视频推荐就全部打开。

从 Proxmox 官方渠道获取匹配平台的 ISO，按该版本官网实际发布的 SHA256校验，不复制旧资料里的哈希值。管理账号要采用强密码和多因素认证；安装过程应填写可收取安全通知的邮箱，不接受“邮箱随便填”作为生产建议。

首次安装时若选择了系统盘并确认格式化，磁盘原数据可能被覆盖。操作前必须准确识别设备型号、容量、序列号和用途，不要根据 /dev/sda 等动态盘符推测磁盘身份。

二、PVE 8.x 与 9.x 的软件源不能混用

知识库的历史案例出现 PVE 8.4。这不是当前在线版本证明。PVE 8 基于 Debian 12 Bookworm；PVE 9 基于 Debian 13 Trixie。版本升级前应核对 pveversion -v、/etc/os-release、APT 的 .list 与 .sources 文件、订阅状态、第三方仓库和发行说明；源的发行代号必须与当前目标版本匹配。

pveversion -v
cat /etc/os-release
apt-cache policy pve-manager
apt list --upgradable

不要照抄旧教程覆盖 /etc/apt/sources.list，也不要一律删除企业源、Ceph 源或加入第三方“加速源”。应根据订阅与实际安装的组件选择官方支持的源，检查 apt update 无错误之后才讨论升级。PVE 官方对受支持的小版本常规更新给出 apt update、apt full-upgrade 的路径；升级、下载和软件包安装都是写操作，必须先备份并获批准。

三、系统启动方式决定内核参数写在哪里

不能把“修改 /etc/default/grub + update-grub”当作所有机器通用方式。

只读核对：

uname -r
proxmox-boot-tool status
cat /proc/cmdline
lsblk -f

设备直通所需的 IOMMU、显卡驱动、DKMS、VF 数量具有 CPU、PCI ID、内核与驱动版本的硬约束。SR-IOV 不是安装一个旧 .deb 后就必然适用于现代主机。历史笔记中的 i915 SR-IOV 补丁、强制 DKMS、内核降级、module_blacklist 均列为实验性历史资料，生产禁止照搬。它们有可能导致宿主无法启动、破坏媒体硬解或使设备失联。

四、维护中的危险习惯与更正

历史做法 更正结论
用 sed 修改 PVE 前端 JS 以去除订阅提示 无助于安全或稳定性，升级可覆盖改动；不列为必要优化
用 dpkg --purge --force-remove-essential 强删内核 高风险，可能破坏启动路径；绝不纳入自动脚本
不核实依赖就安装某个旧版第三方内核 易引入驱动/安全兼容问题；先查版本支持矩阵
`curl ... sh` 直接以 root 执行网络脚本 供应链风险；必须审阅源码、校验来源并测试
所有硬件都使用同一套 CPU 节能参数 不成立；需衡量路由转发性能、功耗、温度和稳定性

五、谨慎的升级 SOP

  1. 确定当前版本、引导加载器、安装方式与仓库来源；记录所有第三方包。
  2. 检查官方版本发行说明、已知问题、硬件驱动和升级路径；跨大版本先运行对应官方预检查器。
  3. 验证 VM/CT 及宿主配置有可恢复备份，关键路由业务准备维护窗口与替代网络。
  4. 提交升级差异及回滚计划，明确离线控制台如何使用。
  5. 经审批后分阶段升级；监测 PVE Web、存储、网桥、虚拟机启动、日志和内核状态。
  6. 失败时按已验证的恢复方案处置，而不是在故障中随机切换内核、反复重启。

关联资料与验证依据

结论：可直接沿用的只有“先确认硬件与备份，再按官方版本维护”的方法，不可照抄多年以前的源、内核与驱动命令。

2026-10-17 第二阶段核验补充（发布前确认）

专题目录← 上一篇下一篇 →