1. 问题现象与初步判断先说结论Ubuntu 19.04 的sudo apt-get upgrade提示失败绝大多数情况不是你的操作问题而是这个版本本身已经走到了生命周期的尽头。19.04 属于短期支持版本代号 Disco Dingo官方只维护 9 个月到 2020 年 1 月就停止维护了。一旦停止维护软件源里的仓库会被官方移除或迁移到旧版本归档服务器这时候你执行apt-get update或者apt-get upgrade自然就会遇到各种 404、仓库无法解析、依赖冲突的报错。我在实际排查这类问题时发现很多人第一步就被报错信息带偏了。看到404 Not Found就以为是网络问题看到Unable to correct problems就认为是依赖损坏其实根源往往只有一个源失效。所以这篇文章会把整个排查过程、原理、解决方案从头到尾捋一遍尤其是针对 19.04 这种已经停止维护的系统到底应该怎么处理才最稳妥。2. 错误日志逐行拆解先看一个典型的报错场景执行sudo apt-get update sudo apt-get upgrade后终端会输出类似这样的内容Hit:1 http://archive.ubuntu.com/ubuntu disco InRelease Err:2 http://security.ubuntu.com/ubuntu disco-security InRelease 404 Not Found [IP: 91.189.88.152 80] Reading package lists... Done W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/disco-security/InRelease 404 Not Found E: Some index files failed to download. They have been ignored, or old ones used instead.接着执行 upgrade 时Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done E: Unable to correct problems, you have held broken packages.这两段日志看起来像是两个问题其实是同一个根源。第一段告诉你源仓库地址已经失效第二段告诉你因为包索引不完整依赖关系无法正确解析。很多人看到you have held broken packages就开始折腾dpkg --configure -a、apt --fix-broken install这些命令在正常情况下确实能解决依赖问题但在源已经404的情况下apt 根本拿不到正确的包列表修复自然无从谈起。2.1 为什么 19.04 的源会失效Ubuntu 的版本分为两种长期支持版LTS和短期支持版普通版本。19.04 属于短期支持版官方维护周期只有 9 个月。维护期结束后主仓库archive.ubuntu.com里的disco目录会被移除安全仓库security.ubuntu.com里的disco-security目录会被移除所有指向这些目录的源地址都会变成 404有一个很关键的点容易被忽略即使你用的是国内镜像源比如阿里云、清华源镜像站为了保持和官方一致也会同步移除这些失效目录。所以如果你换了国内源还是一样报错不用怀疑是镜像源的问题这是版本生命周期决定的。2.2 如何确认系统版本和源配置排查第一步先确认自己是不是真的在用 19.04lsb_release -a输出No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 19.04 Release: 19.04 Codename: disco然后查看源配置文件cat /etc/apt/sources.list以及ls /etc/apt/sources.list.d/很多情况下源配置可能不止一个文件sources.list.d目录下还可能有第三方仓库的.list文件这些文件同样需要检查。3. 解决方案一切换到旧版本归档源如果你的诉求是让这台 19.04 系统继续能安装软件、更新包最直接的方案是切换到 Ubuntu 官方提供的旧版本归档服务器。这个服务器的域名是old-releases.ubuntu.com专门存放已经停止维护的版本。3.1 备份原有源配置动手改之前先把原始配置备份一下。这不是走形式而是方便你随时回滚sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak如果sources.list.d目录下有第三方源文件也一并备份sudo cp -r /etc/apt/sources.list.d /etc/apt/sources.list.d.bak3.2 编辑源列表文件用你习惯的编辑器打开sudo vim /etc/apt/sources.list将文件中所有archive.ubuntu.com和security.ubuntu.com替换为old-releases.ubuntu.com。如果你之前改过国内镜像源比如mirrors.aliyun.com也需要一并替换成old-releases.ubuntu.com。替换后的完整源列表大致长这样deb http://old-releases.ubuntu.com/ubuntu/ disco main restricted universe multiverse deb http://old-releases.ubuntu.com/ubuntu/ disco-updates main restricted universe multiverse deb http://old-releases.ubuntu.com/ubuntu/ disco-security main restricted universe multiverse这里有一个细节值得注意旧版本归档服务器上disco主仓库和disco-updates、disco-security这几个路径都是存在的但disco-backports和disco-proposed不一定完整。所以源列表里我建议只保留主仓库、updates、security 这三类不要贪多。3.3 更新索引并升级执行sudo apt-get update正常情况下应该能正常拉取索引了。然后再执行sudo apt-get upgrade如果一切顺利系统会列出可升级的软件包。这里我要提醒一句一个已经停止维护的系统跨了这么长时间后再升级涉及的包数量可能非常多而且部分软件的新版本依赖的是更新版本的系统库升级过程中有可能会遇到新的依赖冲突。3.4 实际操作中的注意点切换到旧归档源之后还有几个坑需要提前预防第一apt-get update过程中如果出现Hash Sum mismatch错误不要慌通常是因为镜像缓存不一致执行sudo apt-get clean然后重新 update 即可。第二如果升级过程中提示某个包需要先卸载才能升级不要盲目执行apt remove。先看清楚这个包的依赖关系确认不会影响系统关键组件再动手。第三旧归档源的速度一般如果你在海外或者网络环境一般下载速度可能会比较慢。这种情况下可以尝试用apt-get的-o Acquire::http::Dl-Max-Speed参数限制下载速度避免长时间占用带宽。4. 解决方案二升级到仍受支持的系统版本如果你不需要一直停留在 19.04更推荐直接升级到仍然受支持的版本。这里说的升级不是指apt upgrade这种包级别升级而是指do-release-upgrade这种版本级别升级。4.1 为什么推荐升级而不是一直修修补补19.04 停止维护意味着不再有安全更新不再有 bug 修复新的软件包不会进入官方源。即使你切换到旧归档源能正常安装软件也只是修好了“能装包”的问题“安全性”这个核心问题依然没有解决。长期把一台机器跑在停止维护的系统上一旦暴露在公网漏洞风险会随时间推移越来越大。如果你这台机器只是本地开发用的不暴露公网那切换到旧归档源继续用一段时间是可以接受的。但如果它是服务器、生产环境或者需要访问公网我的建议很明确尽早升级。4.2 通过 do-release-upgrade 升级的正确姿势19.04 之后的下一个版本是 19.10Eoan19.10 也已经停止维护了所以直接从 19.04 升级到 19.10 意义不大。更合理的路径是跨版本升级到 20.04 LTS。直接执行sudo do-release-upgrade大概率会提示没有找到新版本因为 19.04 到 20.04 需要先升级到 19.10再升级到 20.04逐级走。而且 19.04 生命周期结束后官方升级通道可能已经关闭需要加-d参数或者手动修改配置来强制执行。我踩过的坑是停维护版本直接跨版本升级中途很容易因为源失效、依赖冲突、第三方源不兼容而中断。升级失败后系统可能处于半升级状态这时候反而更麻烦。所以如果你决定升级优先考虑方案 4.3 的备份重装。4.3 备份重装最稳妥的路线如果说旧归档源是“续命”那么备份重装就是“重生”。我个人的实践体会是对于已经停止维护的系统与其费劲升级不如把重要数据备份出来然后全新安装 20.04 LTS 或 22.04 LTS。步骤很清晰备份/home目录下的个人文件备份/etc下的关键配置比如 nginx 配置、ssh 配置、数据库配置用dpkg --get-selections导出已安装软件列表全新安装新系统用dpkg --set-selections配合apt-get dselect-upgrade恢复软件安装清单软件列表恢复的命令dpkg --get-selections /tmp/package-list.txt装好新系统后dpkg --set-selections /tmp/package-list.txt sudo apt-get dselect-upgrade这个方法能做到“软件清单完整还原”但不建议无脑全量恢复因为有些旧版本的软件在新系统上可能已经有更新的替代版本全量恢复反而会引入版本冲突。建议只恢复自己真正需要的应用软件系统自带的基础组件让它用新系统的默认版本。5. 常见问题与排查技巧实录5.1 换源后仍然提示 404这种情况最典型的原因是两个一是sources.list里虽然改了主域名但sources.list.d目录下还残留着第三方源文件二是源列表里混进了disco-backports或disco-proposed这类归档源上没有的目录。排查方式sudo grep -r disco /etc/apt/sources.list /etc/apt/sources.list.d/把输出里所有包含disco的源地址都看一下凡是域名不是old-releases.ubuntu.com的全部替换或注释掉然后把backports和proposed相关的行注释掉。5.2 执行 upgrade 时提示无法锁定 dpkg如果你开了多个终端或者之前有 apt 进程异常退出可能会遇到E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)这不算疑难杂症执行sudo rm /var/lib/dpkg/lock-frontend sudo rm /var/lib/dpkg/lock sudo rm /var/cache/apt/archives/lock然后重新执行sudo apt-get update sudo apt-get upgrade。需要注意的是删除锁文件之前先用ps aux | grep apt和ps aux | grep dpkg确认没有正在运行的 apt/dpkg 进程。如果确实有进程在跑等它结束或者用sudo kill结束掉。直接删锁文件虽然多数情况下没事但不检查进程就删有可能破坏正在进行的安装事务。5.3 提示“you have held broken packages”怎么处理这是 apt 最经典也最让人头疼的报错之一。在 19.04 的场景下根源绝大多数是源失效导致包索引不完整而不是真的“包被 hold 了”。所以处理顺序应该是先确认源配置是否正确参考第 3 节确认是否能正常apt-get update再尝试sudo apt --fix-broken install如果还不行查看具体是哪个包冲突用apt-cache policy 包名查看候选版本举一个实际遇到的例子某次升级过程中系统提示libssl1.1和openssl版本冲突。我检查后发现是因为旧归档源里这两个包的版本号更新顺序不一致导致 apt 无法解析出满足所有依赖的版本组合。处理方法是手动指定版本安装sudo apt-get install libssl1.11.1.1-1ubuntu2.1然后再执行sudo apt-get upgrade问题就解决了。5.4 第三方软件源导致的依赖混乱19.04 年代比较流行的一些第三方源比如某些 PPAPersonal Package Archive在系统停止维护后会变得非常尴尬——它们的软件包是为 19.04 构建的但维护者可能早就停止更新了。这些 PPA 在apt-get update阶段通常会报 404虽然不影响系统核心功能但会干扰你的判断。处理方式在sources.list.d目录下找到对应的.list文件用#注释掉或者直接删除。然后重新执行sudo apt-get update确认没有任何Err输出后再继续 upgrade。如果某个 PPA 里的软件你确实还需要可以到 Launchpad 上查看该 PPA 是否提供了其他 Ubuntu 版本的构建包如果有手动下载.deb文件用dpkg -i安装即可。6. 快速排查清单为了方便后续遇到类似问题时能快速定位我把整个排查路径整理成一张速查表。现象原因处理方案apt-get update出现 404软件源指向已移除的仓库切换为old-releases.ubuntu.com归档源apt-get upgrade提示 held broken packages包索引不完整依赖解析失败先修复源再apt --fix-broken installapt-get update出现 Hash Sum mismatch镜像缓存不一致sudo apt-get clean后重新 update无法获取 /var/lib/dpkg/lockapt/dpkg 进程残留或异常退出确认无 apt 进程后删除锁文件有第三方源持续报错PPA 停止维护仓库已失效注释或删除对应.list文件更新后软件版本过旧归档源不再提供新版本备份数据后全新安装新版本系统这张表覆盖了 90% 以上的常见场景。如果你按照这个路径走完还是没能解决问题那大概率是某个特定软件包自身的依赖关系太复杂这时候就需要针对具体报错信息逐条排查了。7. 一些兜底建议最后分享几点我在实际维护旧系统过程中的个人体会。不要因为系统还能开机就觉得“没啥问题”。一个停止维护的系统表面上看能正常运行但背后的安全隐患和软件生态断供是真实存在的。如果你只是临时用一下切换到旧归档源完全够用如果是长期使用真的建议花半天时间做一次备份重装。在操作 apt 之前养成看日志的习惯。/var/log/apt/目录下会有history.log和term.log里面记录了每次 apt 操作的详细输出。遇到问题时先翻日志往往比在网上搜报错信息更高效。还有一个小技巧修改源文件后先用sudo apt-get update验证不要直接就去执行upgrade。update 成功是 upgrade 的前提如果 update 阶段就有错误报出来先解决掉再说。很多人图快update 看到几个 WARNING 就跳过结果 upgrade 阶段出问题又回头来查源白白浪费时间。如果你手头也是 19.04 或者其他已经停止维护的 Ubuntu 版本希望这篇文章能帮你少走一些弯路。按着第 3 节的步骤切换归档源或者按第 4 节的思路规划升级路径基本都能把问题解决掉。