某个深夜我收到监控告警一台跑了好几年的业务机器还在用 Debian 10buster而它面对的外部 API 早就开始要求新 TLS 协议内核老、软件旧安全更新也已走到尽头。摆在面前的选择很简单要么重装成 Debian 13trixie要么把这条已经跨了三个大版本的升级链路走通。先说结论从 Debian 10 升到 Debian 13官方只支持逐级升级也就是 buster → bullseye → bookworm → trixie 这样一路走。直接改源到 13 再full-upgrade大概率会遇到依赖冲突、源 404、内核模块丢失最后还是要回到重装这条路。这篇文章来自我把一台老机器完整升到 Debian 13 的全过程记录包括升级路径、每一步的命令、以及常规升级文档里没写的坑。适合手头攒着老系统、又不想重装机器的运维朋友参考。1. 升级路径的底层逻辑为什么必须逐级走 buster→bullseye→bookworm→trixie1.1 Debian 官方为什么不支持跨大版本直接升级很多人第一次干这事时会觉得Linux 升级不就是换一下 sources.list 里的版本代号然后apt full-upgrade吗我当年也这么想过直到在论坛看见一堆人大版本跳级后丢系统。Debian 的包管理器本身是反对跳级升级的。apt full-upgrade虽然会重新评估依赖关系但它并不具备跨三个大版本的迁移知识。软件包在 Debian 10 里依赖的是旧版 glibc、旧版 OpenSSL、旧版 systemd到了 Debian 13库版本、配置路径、服务管理方式都变了。这种跨度不是简单把包换新就能覆盖的。官方从 Debian 9 开始就一直建议逐版本升级并且每升级到一个新的稳定版后先运行一段时间、确认服务正常再继续下一跳。我见过有人把 buster 直接改成 trixie 之后apt 报出一堆The following packages have unmet dependenciesaptitude 都救不回来最后还得手工拆包。所以别跳乖乖走官方路径。1.2 四个版本的代号、发布周期与 LTS 时间线计划升级前首先得知道你手里这块系统到底处在哪个时间点。Debian 每个版本都有标准支持期和 LTS 支持期过了 LTS 之后会进入 archive 状态普通镜像源里就找不到更新了。我用一张表把这条路径上的版本情况理一下版本代号发布年份标准支持结束LTS 结束在我这次升级时的状态Debian 10buster201920222024 年中已归档须切 archive 源Debian 11bullseye202120242026 年左右仍在 LTS正常源可用Debian 12bookworm202320262028 年左右当前稳定分支Debian 13trixie20252030 附近未定最新稳定分支注意第一行这是很多教程不会专门提醒的Debian 10 的 LTS 结束之后普通更新源里的 buster 目录会被移到 archive.debian.org。如果你还在用老的deb.debian.org拉 buster 的包apt update会直接报 404。所以升级的第一步不是急着切 bullseye而是先把 buster 的源切到 archive。1.3 逐级升级、重装、容器迁移三条路怎么选我也必须先泼一点冷水跨三个大版本升级不是零风险操作。如果你的机器只是临时环境、无状态服务重装反而是最高效的如果业务跑在容器里把镜像拉到新系统上重新部署也省事。但如果你有一堆手工配置、数据库、老内核模块、特殊驱动必须保留原系统那逐级升级就是唯一合理路径。逐级升级的优点是保留系统盘上几乎所有东西用户、服务、数据库文件、配置文件、自定义脚本。缺点是耗时长得按顺序跑三轮完整的发行版升级每轮都要处理配置冲突和包替换。我做这次升级的时候保留了全部 4TB 数据盘只对系统盘做了快照最终业务数据零损失光这一点就值回时间成本了。2. 动手之前的体检不检查这些升级必然翻车2.1 备份不该只复制一份配置文件说一句很多运维都听烂了但依旧会犯的话跨大版本升级这种事备份要做全而且必须验证备份能恢复。我见过的翻车现场里最可惜的就是只 tar 了/etc结果升到一半数据库起不来手里却没有数据库文件备份。我的备份清单是这样列的系统配置/etc整目录最重要的是/etc/apt、/etc/systemd、/etc/network或 netplan 相关配置。包管理器状态/var/lib/dpkg、/var/lib/apt/extended_states用于出问题之后重建本地包状态。业务数据MySQL、PostgreSQL、Redis 各自用官方工具导出目录文件用rsync同步到另一台机器。系统盘全量快照如果宿主机支持 LVMlvcreate -s -L 20G -n upgrade_snap /dev/你的卷组/系统逻辑卷几秒就能做一份快照升级翻车直接lvconvert --merge回到原始状态。备份完一定要做一次恢复演练。别嫌麻烦至少把/etc解压到临时目录确认结构完整数据库 dump 文件用gzip -t验证一下没有中途损坏。2.2 第三方软件源排查这段决定你apt update会不会 404跨版本升级最大的实际障碍根本不是 Debian 官方源而是你自己加过的第三方源。Docker 的官方源、Certbot 的官方源、某些厂商的私有源都只在特定 Debian 版本下维护。你一改 codename这些源就会在apt update时报 404甚至有部分源会因为你误用新版路径把不该装的包拉进来。升级之前的排查命令ls -la /etc/apt/sources.list.d/ grep -rh ^deb /etc/apt/sources.list /etc/apt/sources.list.d/如果发现第三方源先别删反正同一套源在升级过程中也用不上。我的做法是把它们统一移动到/etc/apt/sources.list.d/disabled/目录下并在文件后缀加.disabled。这样升级全程只用 Debian 官方源升完系统稳定之后再逐个评估要不要恢复。另外还要检查有没有被 hold 住的包apt-mark showhold有的话记下来确认是故意 hold比如内核、驱动还是以前误操作 hold 的。升级时被 hold 的包不更新有时候会导致依赖断掉很麻烦。2.3 磁盘空间、/boot 容量与引导方式检查大版本升级过程中要下载几百 MB 到几个 GB 的包解开之后占的空间更大。我一般要求/至少有 5GB 可用空间/boot至少有 500MB 可用空间。如果/boot太小内核升级时可能写不进去导致升级中断。检查命令df -h / df -h /boot还要确认引导方式是 BIOSLegacy还是 UEFI[ -d /sys/firmware/efi ] echo UEFI || echo BIOSUEFI 的机器如果开了 Secure Boot升级时要注意内核和 shim 是否签名。Debian 官方源里的包基本都处理好了但第三方 DKMS 模块在 Secure Boot 下可能要重新签 MOK这一步很容易被漏掉。最后看一眼当前内核和已安装内核数量uname -r dpkg -l | grep linux-image如果/boot里装了七八个旧内核建议升级前先清理一批只留当前内核和最近一版内核减少后续升级占用的空间。3. 第一跳从 buster 到 bullseye归档源的正确姿势3.1 先把 buster 切到 archive 源并做完最后一轮稳定更新前面说了现在的 Debian 10 已经归档apt update之前必须先把主源切过去。/etc/apt/sources.list写成下面这样deb [check-valid-untilno] http://archive.debian.org/debian buster main contrib non-free deb [check-valid-untilno] http://archive.debian.org/debian-security buster/updates main contrib non-free注意[check-valid-untilno]这一段。归档仓库的 Release 文件里Valid-Until 时间早已过期apt 会认为这个源不合法而拒绝拉取索引加上这个选项就是告诉 apt 别检查有效期。这是 buster 阶段最容易卡住新手的点。切换之后sudo apt update sudo apt -y upgrade --without-new-pkgs这里故意不用full-upgrade而是在换到 bullseye 之前只做一次已安装包的常规升级。目的是把 buster 能解决的安全修复先打上减少跨版本时叠加的变量。如果你手头这台机器已经很久没更新这一步可能会跑几分钟耐心等。3.2 切到 bullseye 并执行官方推荐的两段式升级最朴素的做法是直接改版本代号。如果你在国内我建议直接切成国内镜像源速度比官方源稳定得多。我这次用的是清华源/etc/apt/sources.list改成deb http://mirrors.tuna.tsinghua.edu.cn/debian bullseye main contrib non-free deb http://mirrors.tuna.tsinghua.edu.cn/debian-security bullseye-security main contrib non-free deb http://mirrors.tuna.tsinghua.edu.cn/debian bullseye-updates main contrib non-free然后执行sudo apt update sudo apt -y upgrade --without-new-pkgs sudo apt -y full-upgrade第一段upgrade --without-new-pkgs的目的是只升级当前已安装的包不引入新的依赖包等这一步顺利完成再执行full-upgrade处理真正的发行版级依赖变化。这个顺序是 Debian 官方升级文档一直推荐的两段式能明显降低中途出现依赖炸弹的概率。升级过程中 debconf 会弹出一堆配置界面比如服务重启方式、配置覆盖确认。建议务必要人盯着屏幕不要在这个阶段跑成无人值守因为某些服务的配置询问需要人工确认。3.3 这一跳最经典的翻车场景第三方源与 dpkg 被锁我这次升级时在 bullseye 阶段遇到的第一类问题就是apt update报 404。查了一下是/etc/apt/sources.list.d/docker.list还在指 buster解决很简单升级期间把它移走等升完再换新源恢复。第二类问题是 dpkg 中断。有时候full-upgrade跑到一半会停下来提示dpkg was interrupted, you must manually run sudo dpkg --configure -a。这是之前某个包安装失败的残留状态。处理方式很机械sudo dpkg --configure -a sudo apt -f install sudo apt full-upgrade还有一类比较隐蔽的是 exim4 或 postfix 的配置询问。Debian 里很多邮件服务包在升级时会弹mail server configuration界面很多人没注意直接回车结果把自己原有的发信配置覆盖了。升级前先备份/etc/exim4或者/etc/postfix这是经验之谈。第一跳结束之后先重启一次系统确认uname -r显示的是 bullseye 内核基本服务都正常再进第二跳。4. 第二跳从 bullseye 到 bookworm最难啃的是默认行为变化4.1 改动最大的是 OpenSSL 3、non-free 固件目录和 apt-key 退役从 bullseye 升到 bookworm 的时候大家普遍觉得最难的不是命令而是各种默认行为的变化。首先OpenSSL 从 1.1 换到了 3.x。这意味着很多老程序里硬编码的 TLS 1.0、1.1 连接默认会被拒绝用老协议连外部系统的脚本可能突然全挂。如果你在机器上跑着老版本 PHP、Python 2 写的爬虫、一些没有持续维护的内部工具升级前要审计它们的出站连接能改协议就改协议。其次bookworm 开始把固件从 non-free 组件中拆分出来了新增了non-free-firmware组件专门放 WiFi、网卡、GPU 这类固件。源里如果不加non-free-firmware无线网卡固件可能不会装上导致升级后无线网卡识别不到。再次apt-key被官方逐步废弃很多以前用apt-key add添加的第三方源密钥在 bookworm 里会失效。如果你之前给某些源添加过签名密钥升级后那些源会报Key is stored in legacy trusted.gpg keyring之类的警告。正确的做法是把密钥文件转到/etc/apt/keyrings/用signed-by方式引用。4.2 bookworm 的升级触发点与命令细节升级源继续改成 bookworm国内源写法要带上non-free-firmwaredeb http://mirrors.tuna.tsinghua.edu.cn/debian bookworm main contrib non-free non-free-firmware deb http://mirrors.tuna.tsinghua.edu.cn/debian-security bookworm-security main contrib non-free non-free-firmware deb http://mirrors.tuna.tsinghua.edu.cn/debian bookworm-updates main contrib non-free non-free-firmware然后执行sudo apt update sudo apt -y upgrade --without-new-pkgs sudo apt -y full-upgrade书面上看起来和上一跳一样但这次full-upgrade需要特别注意屏幕上的将要被删除的包清单。如果某个包因为依赖关系被标记为删除而你又知道这个包是业务依赖的就别硬着头皮回车。先停下来查一下为什么被删保住它再去升级。我这次还遇到一个典型场景Python 包里有几个是pip3装的系统 Python 从 3.9 升到 3.11 之后这些 pip 包直接找不到了。因为 system Python 升级后 site-packages 路径变了。事前知道这个规律就能提前准备好重装这些 pip 包的清单。4.3 生产环境里的两个提醒KVM 虚拟机和 certbot 插件如果你在 Debian 上跑 KVM 虚拟机升级到 bookworm 时要格外留意。我的实际经历是升级完成后systemctl status libvirtd显示正常但virsh list --all看不到任何虚拟机。原因并不是虚拟机丢了而是 qemu 升级后需要重新加载内核模块并且/var/lib/libvirt里的配置在升级时被要求过融合。处理办法很简单sudo systemctl restart libvirtd sudo virsh list --all如果重启 libvirtd 后还是看不到先检查/etc/libvirt/libvirt.conf的权限问题确认当前用户在 libvirt 用户组里。另一个高发场景是 Certbot。很多人装了 certbot 官方源或 pip 版又配了阿里云 DNS 插件做域名验证。升级前 certbot 可能还能跑升级后 openssl、dns 解析库一变插件就崩了。升级完先跑一下sudo certbot --version sudo certbot certificates能正常列出证书就没事如果报模块缺失优先用 apt 装回官方 certbot再重新安装对应插件旧的/etc/letsencrypt目录不要动证书文件会自动恢复识别。bookworm 这轮升级涉及的服务配置变化最多我建议升级后给系统 2 到 3 天的观察期确认没有后台任务报错再走第三跳。5. 第三跳从 bookworm 到 trixieDebian 13 的源与变化清单5.1 trixie 的国内镜像源该怎么写到了最后一跳如果你已经走到这一节说明前面两跳都挺过来了。Debian 13trixie作为当前的最新稳定分支国内各镜像站都已经同步得很完整了。清华、阿里、中科大我都试过速度差别主要看运营商但我个人实测清华源从更新到拉包都比较稳。/etc/apt/sources.list建议写成deb http://mirrors.tuna.tsinghua.edu.cn/debian trixie main contrib non-free non-free-firmware deb http://mirrors.tuna.tsinghua.edu.cn/debian-security trixie-security main contrib non-free non-free-firmware deb http://mirrors.tuna.tsinghua.edu.cn/debian trixie-updates main contrib non-free non-free-firmware如果你更喜欢用官方源就写https://deb.debian.org/debian但国内直连官方源经常跑不满带宽升级包又多还是镜像站舒服。5.2 第三次执行标准升级流程源切到 trixie 之后继续执行老一套sudo apt update sudo apt -y upgrade --without-new-pkgs sudo apt -y full-upgrade虽然形式相同但到这一跳我已经养成了一个习惯在任何full-upgrade之前先看一眼apt list --upgradable的数量级。如果从 bookworm 升级到 trixie可升级包有几百上千个这是正常的但如果可升级包数量明显少得离谱就要怀疑源是否切错了或者有没有 hold 包在挡路。升级过程中如果遇到configuration file /etc/xxx的询问请看清楚是保留现有配置还是使用维护者新版本。对于系统重要配置我通常保留现有对于明显是版本升级要求的格式调整才选维护者版本。用眼睛扫一遍再回车比事后翻/etc底下那一堆.dpkg-dist文件要省事得多。5.3 升级后网络接口名、内核模块这些容易被忽略的差异第三跳升完重启之后最容易出问题的反而不是包本身而是系统的predictable network interface names行为变化。很多从老版本一路升上来的机器网卡名可能从eth0变成enpXsY或者从enpXsY变成另一个名字。如果你在/etc/network/interfaces或者 systemd-networkd 里写死了旧接口名升级后网络会直接起不来SSH 也连不上。我的建议是在最终重启前趁系统还能登录先备份接口配置并确认升级后的 rules 文件有没有变化ip a cat /etc/network/interfaces ls /etc/systemd/network/如果发现接口名要变最稳妥的办法是在系统升级、重启之前就主动改好配置别等到断连之后再通过带外方式去修。另一个容易忽略的是硬件驱动。热搜里很多人问debian 安装 intel killer e5000 网卡驱动这种事其实在老系统上好好的网卡驱动升级到新内核后反而有可能加载失败。你可以用dmesg | grep -i ethernet看看有没有模块报错。如果内核自带模块不行就要去装对应厂商提供的 DKMS 包而且装之前要确保系统已经按要求安装了编译工具链。6. 收尾工作重启前的检查和升级后的系统清理6.1 把 SSH 会话保活别把自己锁在外面跨版本升级最尴尬的场景是full-upgrade执行到一半SSH 连接断了或者是重启后 SSH 服务没起来你对着一个黑屏的远程机器束手无策。执行最终重启之前我习惯先做几件事sudo systemctl enable --now ssh sudo systemctl status ssh确认 SSH 服务已设置为开机自启。如果之前装了fail2ban、防火墙规则升级后要检查是否放行了新接口名。然后我会用tmux或screen把升级会话挂起来防止终端窗口意外关闭导致升级中断。重启命令就老老实实用sudo systemctl reboot重启之后先确认版本号cat /etc/debian_version uname -a看到13开头的版本号这颗心才真正放下来。6.2 旧内核、孤立依赖与残留配置文件的清理版本确认无误后别急着删东西先让系统跑一阵。但如果旧内核堆了一堆确实会影响/boot后续更新我会在确认新内核稳定后清理sudo apt autoremove --purge sudo apt clean dpkg --auditdpkg --audit会列出有问题的半安装包如果输出为空说明包状态健康。还要检查一下是否有残留的.dpkg-old和.dpkg-dist文件find /etc -name *.dpkg-* -type f这些文件是包升级时对配置文件的备份往往隐藏着新版软件不兼容旧配置的线索。比如系统服务起不来先去这些文件里对比新旧配置差异很多问题一眼就能定位。升级完之后之前临时禁用的第三方源也要处理。逐个把源目录里的.disabled文件恢复重新装回对应版本的密钥和源然后apt update看看有没有 404。确认一切正常才算真正完成了一次完整升级。6.3 桌面和驱动类高频问题的排查顺序升级完成之后桌面环境用户通常会遇到一批看似毫不相关的问题。我看到很多人在问输入法切换、WPS 字体、Steam runtime 这些事它们确实是升级之后的高频求助点但解决办法大多不在升级动作本身而是新系统缺少旧环境里的库和配置。我的排查顺序是先看系统日志确认基础服务正常再处理桌面输入法。搜狗输入法如果在 Debian 13 里切换不过去先检查im-config是否还指向 fcitx再跑fcitx-diagnose看有没有组件缺失。WPS 字体乱码通常不是 WPS 的问题而是系统缺中文字体装fonts-noto-cjk后执行fc-cache -f刷新一下就行。Steam 的 runtime 行为变化按官方文档重新校验即可不建议用跳过 runtime 的方式来绕过问题那样只会把兼容性隐患推迟到后面。这些问题的共同点是升级只是换了一套系统底座应用层的东西还得按新底座的规矩重新适配。这也是跨大版本升级最消耗时间的地方摆正心态逐个排查都不算难。7. 跑了三跳升级之后我最后想说的几件事如果你准备照着这条路径升级我再分享几个实际操作的体会。第一别指望一次full-upgrade就一路畅通。我这次升级前后花了差不多一天时间其中大量时间不是花在命令执行上而是花在处理配置文件询问、排查第三方源、恢复应用依赖上。给自己预留足够时间不要在赶进度的时候操作。第二升级过程中保持只开一个终端做升级操作不要在同一个会话里同时跑其他 apt 命令。apt 的锁机制虽然能让并行命令排队但多个进程抢锁容易造成状态混乱等想起来的时候已经是 dpkg 中断现场了。第三每一跳升级完成之后都写一份简单的升级记录内容包括升级前版本号、升级后版本号、做了哪些源切换、动了哪些配置、出现过哪些报错、怎么解决的。三跳下来你手里的这份记录会变成一台机器最宝贵的系统档案以后再升级或排障都能直接翻出来用。第四最不济的情况也要留好系统盘快照。跨版本升级最坏的结果不是报错而是某一步升级后内核起不来。只要快照还在回到升级前的状态只需要一条命令。这次从 Debian 10 到 Debian 13 的升级过程其实没有什么黑魔法核心就是按照官方路径逐级走、别跳版本、提前排除第三方源、处理配置冲突。系统装完那一刻我看着cat /etc/debian_version输出的 13才觉得老机器终于跟上了时代。
