Ubuntu 26.04 升级别乱按：Agent 一句话托管，人工路线也一次讲透

发布时间: 2026-05-12

Ubuntu Linux LTS 升级 do-release-upgrade Agent Codex Claude OpenClaw HermesAgent

先说结论

Ubuntu 22.04 / 24.04 升级到 26.04，最重要的不是记住某一条命令，而是先搞清楚升级路径。22.04 LTS 不能直接跳到 26.04 LTS，必须先升级到 24.04 LTS，再从 24.04 LTS 进入 26.04 LTS。并且截至 2026-05-12，Ubuntu 26.04 LTS 虽然已经正式发布，但 24.04 LTS 到 26.04 LTS 的常规 LTS 升级提示通常要等 26.04.1 之后才会面向普通 LTS 用户开放；官方计划里的 26.04.1 Point Release 日期是 2026-07-09。生产机器建议等常规升级路径打开，测试机或评估机才考虑显式使用提前升级参数。

如果你已经在使用 Code、Claude、OpenClaw、HermesAgent 这类 Agent，完全可以用一句话把升级任务交出去，让它先做检查、备份、升级和验证，节省大量重复操作时间。但这句话不能只写“帮我升级 Ubuntu”，而要把安全边界、升级路径、备份、业务验证和回滚要求说清楚。本文会给出可以直接复制的 Agent 提示词，也会给出完全人工执行的步骤。

本文不会出现任何真实主机名、内网地址、账号、密钥、Token、业务系统名称或私人路径。所有命令都使用通用占位符，例如 <HOST>、<SERVICE>、<BACKUP_DIR>。你可以把它们替换成自己的环境值。

Ubuntu 26.04 升级的两条路线

图 1：升级可以交给 Agent 托管，也可以人工执行；但两条路线都必须从备份、检查和验证开始。

1. 先把一个误区说清楚：这不是 apt upgrade

很多人第一次做 Ubuntu 大版本升级时，会把下面几件事混在一起：

apt update：刷新软件包索引。
apt upgrade：升级当前发行版里的软件包。
apt full-upgrade 或 apt dist-upgrade：在当前发行版内做更完整的软件包升级，允许新增或移除依赖。
do-release-upgrade：把系统从一个 Ubuntu 发行版升级到下一个发行版。

从 22.04 到 24.04，从 24.04 到 26.04，属于第四种。它不是把包升级到最新版这么简单，而是切换整套发行版：软件源、基础库、内核、Python、systemd、OpenSSL、桌面环境或服务器组件都会跟着进入新版本。你看到的命令可能只有一条，但背后做的是一次系统迁移。

所以这件事不能用“执行一个命令，看它跑完”来理解。更合理的视角是：这是一场小型变更窗口。升级前要确认路径、备份、空间、第三方源、内核和业务状态；升级中要处理交互提示；升级后要确认系统版本、服务启动、端口监听、日志、第三方软件和业务功能。命令只是中间那一步。

2. 当前官方规则：22.04 不能直接到 26.04

Ubuntu 官方文档对升级路径的原则很明确：只支持顺序升级。LTS 用户可以从一个 LTS 升级到下一个 LTS；如果你要到更后面的 LTS，就要逐级走。

Ubuntu LTS 升级路径

图 2：22.04 到 26.04 不是一步跳过去，而是先到 24.04，再从 24.04 到 26.04。

具体到这次：

Ubuntu 22.04 LTS 用户：先升级到 Ubuntu 24.04 LTS。
Ubuntu 24.04 LTS 用户：再升级到 Ubuntu 26.04 LTS。
如果你现在是 25.10 这类中间版本，路径会不同，要按相邻版本升级。
如果你不想做多次原地升级，也可以备份数据后重装 26.04，再恢复应用和数据。

这也是为什么网上一些“22.04 一键升 26.04”的说法要非常谨慎。它们可能实际做了两段升级，可能是换源硬改，可能是先跨到中间版本，也可能只是适合测试机。对服务器、工作站、开发环境、Homelab 核心节点来说，跳过官方路径通常不是省时间，而是在把风险挪到不可预期的地方。

还有一个时间点要注意：截至本文写作时，也就是 2026-05-12，26.04 LTS 已经在 2026-04-23 发布，但官方桌面升级文档仍提示 LTS 到最新 LTS 的常规升级会在第一个 point release 后开放。26.04 的 release schedule 里，26.04.1 Point Release 写的是 2026-07-09。因此，普通生产环境的稳妥策略是等 26.04.1 后再走常规 do-release-upgrade；测试机可以显式提前升级，但要接受风险。

这不是保守，而是 LTS 升级的正常节奏。第一个 point release 之前，很多企业和团队会先在测试机、灰度节点、非关键节点上验证应用兼容性，等问题收敛后再批量升级。

3. 什么时候应该升级，什么时候应该重装

原地升级的优点是省事：系统保留用户、软件包、配置、服务、日志、目录结构和大部分运维习惯。缺点也很明显：旧系统里积累的第三方源、手工安装包、残留配置、历史内核、旧服务文件、Python venv、Docker 旧数据、驱动和 DKMS 模块，都可能在升级时变成障碍。

我一般这样判断：

适合原地升级：普通服务器、开发机、配置较多但可备份的 Homelab 节点、已经自动化管理的 VM、云主机、服务数量不多且能接受维护窗口的机器。
更适合重装：系统被长期手工改过、第三方源很多、驱动链路复杂、根分区太小、业务容器已经完全数据卷化、机器本身可以快速重建。
必须先演练：数据库主机、存储节点、网关、防火墙、CI/CD 核心节点、唯一入口机、无人值守远程机器。

重装不是失败。对很多容器化服务来说，最稳的做法反而是：备份 /etc、业务数据、Compose 文件、systemd 单元、证书和密钥；新装 26.04；恢复服务；验证无误后切流。它比背着十年历史包袱做原地升级更干净。

但本文重点仍然是原地升级，因为这是大多数人最想做、也最容易踩坑的场景。

4. 方案 A：一句话交给 Agent，但要把边界写清楚

现在很多人已经把 Code、Claude、OpenClaw、HermesAgent、Codex、OpenCode 这类 Agent 放进日常运维工作流。升级系统这种重复步骤多、检查项多、日志多的任务，很适合交给 Agent 辅助执行。

但是，这里有一个关键区别：

坏提示：帮我把这台机器升级到 Ubuntu 26.04。

好提示：请先检查当前 Ubuntu 版本、官方升级路径、磁盘空间、备份状态、第三方源、held packages、关键服务和远程控制台可用性；确认满足条件后再升级到 Ubuntu 26.04 LTS；升级过程中保留日志，不要删除业务数据；升级后验证版本、内核、服务、端口、日志和业务健康检查；最后给出证据和遗留风险。

第一句话只表达目标，没有安全边界。Agent 可能会直接执行升级，也可能用不合适的参数，还可能在升级后只看 lsb_release 就宣布完成。第二句话把任务拆成了可验证的流程：先检查，再执行，再验证，再汇报。

Agent 托管升级的正确交接方式

图 3：让 Agent 升级系统时，重点不是“它会不会敲命令”，而是它会不会按检查点工作。

4.1 可以直接复制的 Agent 提示词

下面这段可以直接给 Agent 使用。你只需要把占位符替换成自己的机器信息。为了避免泄露隐私，示例里不写真实地址。

请帮我把 Ubuntu 主机 <HOST> 从当前 LTS 升级到 Ubuntu 26.04 LTS。

要求：
1. 先只做检查，不要直接升级。
2. 检查当前版本、内核、架构、磁盘空间、/boot 空间、内存、网络连通性、DNS、软件源、第三方源、PPA、held packages、dpkg/apt 状态、reboot-required、关键服务、Docker/数据库/反向代理等业务状态。
3. 判断官方支持的升级路径：如果当前是 22.04 LTS，必须先到 24.04 LTS，再到 26.04 LTS；如果当前是 24.04 LTS，确认 26.04 LTS 常规升级是否已经开放。如果未开放，请停止并说明是否需要等待 26.04.1 或显式使用提前升级参数。
4. 升级前创建备份或确认已有可恢复备份。不要删除业务数据、数据库、容器卷、证书、密钥或用户文件。
5. 升级时保留完整日志，建议在 tmux/screen/控制台中执行。遇到配置文件提示时先展示 diff 和建议，不要盲目覆盖。
6. 升级后必须重启，并验证：lsb_release、/etc/os-release、uname -a、systemctl --failed、关键服务状态、关键端口、应用健康检查、apt update、journalctl 错误。
7. 最后输出一份报告：原版本、目标版本、执行命令、关键提示选择、验证证据、失败项、需要我手工处理的事项。

这段提示词的重点是第一条：先只做检查，不要直接升级。
如果 Agent 的能力足够，它会先给你一份预检查报告；如果能力不足，它至少会被这个边界拦住，不会一上来就改系统。

4.2 Agent 预检查应该看什么

你可以要求 Agent 先运行这些只读命令：

lsb_release -a
cat /etc/os-release
uname -a
dpkg --print-architecture
df -h
df -h /boot || true
free -h
apt-mark showhold
sudo dpkg --audit
sudo apt update
sudo apt -s full-upgrade
systemctl --failed
systemctl list-units --type=service --state=running --no-pager
find /etc/apt/sources.list /etc/apt/sources.list.d -maxdepth 1 -type f -print

如果是服务器，还应该让它记录关键业务：

ss -lntup
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}' 2>/dev/null || true
sudo journalctl -p warning..alert -n 100 --no-pager

这些命令不会完成升级，但能暴露很多问题：根分区太小、/boot 太小、包管理器半配置、第三方源不可达、服务已经失败、Docker 容器异常、系统本来就需要重启。不要在这些问题没处理前升级，否则升级失败时你很难判断是新版本引入的问题，还是旧系统本来就坏。

4.3 Agent 升级时最容易犯的错

把升级交给 Agent，并不意味着你可以完全不看。最容易犯的错有这些：

看到 do-release-upgrade -d 就默认同意。-d 在某些时段用于提前进入新版本升级路径，生产环境不应随便使用。
配置文件提示时一路默认。默认通常是保留旧配置，但有些包需要新配置才能适配新版本；反过来，盲目接受新配置也可能覆盖你手工改过的 SSH、网络、Nginx、数据库参数。
只验证系统版本，不验证业务。lsb_release -a 显示 26.04 只是系统层成功，不代表应用层成功。
升级后立即清理旧包。应该先验证业务，再清理；如果刚升级完就删除一堆包，回滚和排障会更难。
在唯一 SSH 会话里升级。远程机器最好使用 tmux/screen，并确保有云控制台、虚拟机控制台、IPMI、Proxmox 控制台或本地显示器这类备用入口。

Agent 最有价值的地方是帮你执行大量检查和记录，不是替你承担变更责任。你仍然要决定维护窗口、备份策略、是否提前升级、配置文件如何选择、业务是否允许中断。

5. 方案 B：完全人工升级步骤

下面是人工升级路线。你可以把它当成操作手册，也可以把它拆给 Agent 逐项执行。

人工升级检查清单

图 4：人工升级的关键不是命令多复杂，而是不要漏掉升级前后检查。

5.1 确认当前版本和目标路径

先看当前版本：

lsb_release -a
cat /etc/os-release
uname -a

如果是 22.04 LTS：

22.04 LTS -> 24.04 LTS -> 26.04 LTS

如果是 24.04 LTS：

24.04 LTS -> 26.04 LTS

如果当前不是 LTS，例如 25.10，则要按相邻版本路径处理。不要只看网上某篇教程里的命令，要看你的系统现在实际处在哪个发行版。

5.2 备份，尤其是不可再生数据

备份要覆盖四类东西：

用户数据：业务目录、上传文件、数据库 dump、容器数据卷。
系统配置：/etc、systemd unit、Nginx/Apache、SSH、cron、网络配置。
部署文件：Compose 文件、环境变量模板、脚本、证书续期配置。
回滚入口：VM 快照、云盘快照、裸机镜像、备份恢复文档。

一个简单的配置备份示例：

sudo mkdir -p <BACKUP_DIR>
sudo tar --xattrs --acls -czf <BACKUP_DIR>/etc-before-ubuntu-upgrade.tar.gz /etc
dpkg --get-selections > <BACKUP_DIR>/dpkg-selections.txt
apt-mark showmanual > <BACKUP_DIR>/apt-manual-packages.txt
systemctl list-unit-files > <BACKUP_DIR>/systemd-unit-files.txt

如果有数据库，不要只备份目录。根据数据库类型做逻辑备份或一致性快照。例如 PostgreSQL、MySQL、MariaDB、MongoDB 都有各自的推荐方式。容器服务也不要只备份 docker ps 输出，真正重要的是 volume、bind mount、配置文件和镜像版本。

5.3 检查磁盘、包状态和第三方源

升级会下载大量软件包，也会临时保留旧包。根分区和 /boot 空间不足是常见失败原因：

df -h
df -h /boot || true
free -h

检查包管理器是否健康：

sudo dpkg --audit
sudo apt update
sudo apt -f install
sudo apt-mark showhold

如果有 held packages，要理解为什么被 hold。内核、驱动、数据库、浏览器、容器运行时被 hold，都可能影响升级。不要机械地全部 unhold，也不要机械地全部保留。

列出软件源：

find /etc/apt/sources.list /etc/apt/sources.list.d -maxdepth 1 -type f -print -exec sed -n '1,120p' {} \;

Ubuntu 升级过程中通常会禁用第三方源和 PPA。禁用不是坏事，反而是为了减少冲突。你应该提前知道哪些软件来自第三方源，升级后再逐个恢复适配 26.04 的版本。

5.4 更新当前系统到最新状态

先在当前版本内更新到最新：

sudo apt update
sudo apt full-upgrade

服务器文档里还建议在做发行版升级前处理 phased updates，可以使用：

sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true

如果提示需要重启，先重启：

if [ -f /run/reboot-required ]; then
  sudo reboot
fi

重启回来后，再确认版本和服务：

lsb_release -a
systemctl --failed
sudo apt update

不要在当前系统已经半坏的状态下进入大版本升级。

5.5 在可靠会话里启动升级

远程服务器建议先开 tmux 或 screen：

tmux new -s ubuntu-upgrade

然后安装升级工具：

sudo apt install update-manager-core

确认 LTS 提示策略：

grep -R '^Prompt=' /etc/update-manager/release-upgrades

LTS 机器通常应该是：

Prompt=lts

启动升级：

sudo do-release-upgrade

如果你在 2026-05-12 这样的时间点从 24.04 LTS 升级到 26.04 LTS，常规路径可能会提示没有新版本。这不是命令错了，而是 LTS 升级门槛还没对普通用户打开。你有两个选择：

生产环境：等待 26.04.1 后再执行常规 sudo do-release-upgrade。
测试环境：明确接受风险后，才考虑使用提前升级参数。

提前升级常见写法是：

sudo do-release-upgrade -d

这里必须强调：-d 不应该成为生产环境的默认命令。它适合评估、测试、提前验证兼容性，或者在你明确知道当前 release upgrader 状态时使用。对业务机器来说，能等常规路径打开就等常规路径。

5.6 处理交互提示

do-release-upgrade 是交互式工具。你可能会看到：

是否开始升级。
有多少包会安装、升级、删除。
第三方源被禁用。
配置文件与新版本不同。
是否删除 obsolete packages。
是否重启。

配置文件提示最需要耐心。一般不要盲目选 Y 覆盖，也不要永远选 N 保留。推荐先看 diff：

D     show the differences between the versions

如果是你手工改过的 SSH、Nginx、数据库、网络、系统限制参数，通常要保留旧配置，再手工合并新版本变化。如果是系统默认文件且你没有改过，可以接受包维护者版本。遇到 GRUB、内核、引导相关提示时要更谨慎，尤其是多磁盘、软 RAID、云主机和虚拟化环境。

5.7 从 22.04 升级到 26.04 的两段流程

如果当前是 22.04 LTS，第一段先做：

sudo apt update
sudo apt full-upgrade
sudo reboot
sudo do-release-upgrade

完成后重启，确认已经到 24.04：

lsb_release -a
cat /etc/os-release
systemctl --failed
sudo apt update

不要马上继续第二段。至少要确认：

SSH 能登录。
网络正常。
关键服务能启动。
日志没有明显错误。
第三方源没有错误地指向旧版本。
/boot 和根分区还有足够空间。

然后再从 24.04 到 26.04。若常规 LTS 升级还未开放，生产环境在这里暂停；测试环境才考虑显式提前升级。

5.8 升级后的验证

升级完成并重启后，先确认系统层：

lsb_release -a
cat /etc/os-release
uname -a
sudo apt update
sudo apt list --upgradable
systemctl --failed

再看日志：

sudo journalctl -p warning..alert -b --no-pager | tail -n 200
sudo dmesg -T | tail -n 100

检查端口和业务：

ss -lntup
systemctl status <SERVICE> --no-pager
curl -I http://127.0.0.1:<PORT>/health

Docker 主机还要看：

docker ps
docker compose ps
docker logs --tail=100 <CONTAINER>

如果你有监控系统，不要只看本机命令。应该从外部访问一次：网页能否打开，API 是否返回正常，证书是否正常，定时任务是否恢复，反向代理是否仍然转发正确。

5.9 恢复第三方源和清理

升级后，第三方源往往被禁用。不要立即把旧的 jammy 或 noble 源原样打开。先确认对应软件是否支持 26.04，再切到正确发行版代号或官方新版安装方式。

查看被禁用的源：

grep -R "disabled on upgrade" /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null || true

确认无误后再清理：

sudo apt autoremove --purge
sudo apt autoclean

清理旧内核时要保守。至少保留当前正在运行的内核和一个可回退内核。清理前先看：

uname -r
dpkg -l 'linux-image*' | awk '/^ii/{print $2}'

6. 常见问题和处理思路

6.1 `do-release-upgrade` 提示没有新版本

先看你当前是不是 LTS。如果是 24.04 LTS，并且时间还早于 26.04.1 普通开放窗口，那么没有提示是正常现象。生产环境等待；测试环境再考虑 -d。如果是 22.04 LTS，则你应该先看是否能升到 24.04 LTS。

6.2 第三方源报错

先禁用第三方源，完成系统升级，再找支持 26.04 的源。不要为了让 apt update 不报错，就把发行版代号硬改成目标版本。源是否支持新版本，要看软件供应方是否发布了对应仓库。

6.3 `/boot` 空间不够

先查看当前内核和已安装内核。清理明显不用的旧内核，但不要删当前内核。云主机、加密磁盘、多启动系统和特殊引导环境要更谨慎。

6.4 配置文件提示不知道怎么选

先看 diff。配置文件是你改过的，就优先保留旧版，再把新配置里必要的字段合并进去；如果你没改过，通常可以接受维护者版本。对 SSH、网络、GRUB、防火墙、数据库配置要格外谨慎。

6.5 升级后服务启动失败

不要先回滚。先看：

systemctl status <SERVICE> --no-pager
journalctl -u <SERVICE> -b --no-pager

很多失败来自配置语法变化、依赖包名变化、Python/Node/Ruby 版本变化、OpenSSL 安全策略变化、旧 PPA 包残留、权限或 AppArmor 行为变化。先把错误钉住，再决定是修配置、升级应用、恢复旧包还是回滚。

7. 我会采用的推荐策略

如果是个人测试机、临时 VM、可随时重装的开发环境，可以用 Agent 辅助提前升级，目的就是尽快发现兼容性问题。

如果是生产服务器、家庭核心服务、NAS 旁路服务、监控、网关、数据库、反向代理、CI/CD、远程入口机，我建议这样做：

现在先把 22.04 升到 24.04，或者确认 24.04 当前状态健康。
建一台测试机或克隆 VM，提前演练 24.04 到 26.04。
记录所有配置文件选择、第三方源变化和业务修复点。
等 26.04.1 后，再对真实机器执行常规 do-release-upgrade。
使用 Agent 做预检查、日志记录、升级执行和验证汇报，但关键确认点由人决定。

这样做看起来慢一点，但实际更省时间。因为升级失败最耗时的不是命令本身，而是失败后你不知道失败在哪一层。提前演练和清单化，会把不可控问题变成可重复步骤。

8. 最后给一份最短人工命令清单

如果你只想要一份浓缩版，可以按下面思路执行。注意：这不是替代上面的解释，而是给熟悉 Linux 的人做复查。

# 1. 确认版本
lsb_release -a
cat /etc/os-release

# 2. 备份配置和软件包清单
sudo mkdir -p <BACKUP_DIR>
sudo tar --xattrs --acls -czf <BACKUP_DIR>/etc-before-upgrade.tar.gz /etc
dpkg --get-selections > <BACKUP_DIR>/dpkg-selections.txt
apt-mark showmanual > <BACKUP_DIR>/apt-manual-packages.txt

# 3. 检查状态
df -h
df -h /boot || true
sudo dpkg --audit
apt-mark showhold
systemctl --failed

# 4. 更新当前系统
sudo apt update
sudo apt full-upgrade
sudo reboot

# 5. 启动升级
tmux new -s ubuntu-upgrade
sudo apt install update-manager-core
sudo do-release-upgrade

# 如果常规 LTS 路径尚未开放，生产环境应停止等待；
# 测试机在明确接受风险后才考虑：
# sudo do-release-upgrade -d

# 6. 升级后验证
lsb_release -a
cat /etc/os-release
uname -a
sudo apt update
systemctl --failed
ss -lntup
sudo journalctl -p warning..alert -b --no-pager | tail -n 200

如果当前是 22.04，先按这套流程升到 24.04；验证稳定后，再按同样原则从 24.04 进入 26.04。不要试图把两段升级压成一次“神奇命令”。

参考来源

本文写作时核对了以下公开资料，时间为 2026-05-12：

Ubuntu 26.04 LTS release notes：https://documentation.ubuntu.com/release-notes/26.04/
Ubuntu 26.04 release schedule：https://documentation.ubuntu.com/release-notes/26.04/schedule/
Ubuntu Desktop upgrade documentation：https://documentation.ubuntu.com/desktop/en/latest/how-to/upgrade-ubuntu-desktop/
Ubuntu Server upgrade documentation：https://documentation.ubuntu.com/server/how-to/software/upgrade-your-release/
Ubuntu 24.04 LTS release notes：https://documentation.ubuntu.com/release-notes/24.04/