Ubuntu 18.04升级20.04 LTS系统级升级实战指南

最新推荐文章于 2026-06-19 16:02:57 发布

原创最新推荐文章于 2026-06-19 16:02:57 发布 · 421 阅读

本内容遵循CC 4.0 BY-SA版权协议

1. 项目概述：这不是一次普通升级，而是一次系统级“换血”

Ubuntu 20.04 Focal Fossa 是一个长期支持（LTS）版本，官方提供长达5年的安全更新与维护，这意味着它不是那种“用完即弃”的临时发行版，而是你未来几年里每天打交道的操作系统底座。我从18.04 LTS 升级到20.04 的过程，前后折腾了三台不同配置的机器——一台老旧的ThinkPad X220（i5-2520M + 4GB RAM），一台主力开发机（Ryzen 5 3600 + 32GB RAM + NVMe SSD），还有一台作为CI测试节点的树莓派4B（通过Ubuntu Server 20.04 ARM64镜像验证兼容性）。这三台设备的升级路径、失败点和最终解决方案完全不同，但核心逻辑高度一致：升级的本质，是让旧系统的软件包管理器（APT）在不破坏现有配置的前提下，将整个软件生态栈，从一个已知稳定状态，平滑迁移到另一个经过严格验证的新状态。这个过程里，“ do-release-upgrade ”不是魔法命令，而是一套精密编排的自动化脚本；“ apt update && apt upgrade ”也不是万能补丁，而是升级前必须完成的“系统体检”与“补给准备”。很多新手一上来就敲 sudo do-release-upgrade -d ，结果卡在“正在下载元数据”或“无法解析依赖关系”，最后只能重装——问题从来不在命令本身，而在于你是否真正理解了Ubuntu的发布机制、APT的依赖图谱，以及你自己的系统到底“脏”到了什么程度。这篇文章不讲“点击下一步”的图形向导，只讲终端里每一行命令背后的意图、风险与替代方案。如果你正打算把生产环境的服务器、日常办公的笔记本，或者跑着ROS、VINS-MONO、MySQL 8.0.25等关键服务的开发机升级到20.04，那么你不仅需要知道“怎么做”，更需要知道“为什么必须这么做”、“哪一步可以跳过”、“哪一步绝对不能跳过”，以及“万一挂了，怎么在5分钟内回滚”。这才是一个十年老手在真实世界里反复验证过的升级手册。

2. 升级前的系统诊断与风险评估：先别急着敲命令

2.1 确认当前系统状态与升级路径合法性

在任何操作之前，第一件事永远是确认你的起点是否合规。Ubuntu的LTS升级有严格的路径限制：官方只支持从上一个LTS版本（18.04）直接升级到20.04。如果你现在用的是16.04，那必须先升到18.04，再升到20.04；如果用的是19.10（非LTS），则理论上可以升级，但官方不推荐，因为非LTS版本生命周期短，其软件源可能早已下线，导致升级过程中大量包无法获取。执行以下命令，逐行检查：

# 查看当前Ubuntu版本及代号
lsb_release -a
# 输出示例：
# Distributor ID: Ubuntu
# Description:    Ubuntu 18.04.6 LTS
# Release:        18.04
# Codename:       bionic

# 查看内核版本（注意：20.04默认使用5.4内核，但18.04的HWE内核如5.3/5.4也可兼容）
uname -r
# 如果输出是4.15.x，说明你用的是原始内核，升级后会自动切换到5.4；如果是5.3.x或5.4.x，说明你已启用HWE，升级后内核版本不变，但模块会更新。

# 检查当前是否为LTS版本（Release字段末尾带LTS即为长期支持版）
grep "LTS" /etc/os-release

提示： lsb_release -a 的输出中， Codename 字段（如 bionic ）比 Release 字段（如 18.04 ）更重要。因为APT源地址（ /etc/apt/sources.list ）里的所有条目，都是基于codename构建的。一旦你误将 bionic 改成 focal ，又没运行 apt update ，APT就会彻底懵圈，报出一堆“无法定位软件包”的错误。这是新手最常犯的低级错误，也是后续所有依赖问题的根源。

2.2 扫描并清理“升级拦路虎”：第三方PPA与损坏的包

Ubuntu的升级脚本 do-release-upgrade 在启动前会进行一次全面的“健康扫描”。它会检查 /etc/apt/sources.list 和 /etc/apt/sources.list.d/ 下所有文件，识别出所有非官方源（尤其是PPA）。绝大多数PPA在新版本发布时并不会同步更新，它们的软件包签名密钥可能过期，或者干脆停止维护。此时， do-release-upgrade 会直接中止，并提示类似 “The upgrade has aborted. Please check your software sources and try again.” 的错误。因此， 升级前手动清理PPA，不是可选项，而是必选项。

我的实操流程是：

备份源列表 ： sudo cp -a /etc/apt/sources.list /etc/apt/sources.list.backup
禁用所有PPA ：进入 /etc/apt/sources.list.d/ 目录，将所有 .list 文件重命名为 .list.disabled 。例如： sudo mv google-chrome.list google-chrome.list.disabled 。不要直接删除，留着以后恢复。
检查并修复损坏的包状态 ：运行 sudo dpkg --configure -a 尝试修复未完成的安装；再运行 sudo apt install -f 强制修复依赖关系。如果这两个命令报错，比如提示某个包“half-installed”或“unpacked”，那就得手动干预。常见场景是MySQL或PostgreSQL的升级包卡在配置阶段。此时，你需要根据错误信息，找到对应的 .deb 包（通常在 /var/cache/apt/archives/ ），然后用 sudo dpkg -i --force-all <package.deb> 强制重装，再运行 sudo apt install -f 补齐依赖。

注意：网上流传的“一键禁用所有PPA”脚本（如 sudo add-apt-repository --remove ppa:xxx/yyy ）并不总是可靠。有些PPA是通过 apt-add-repository 添加的，有些是手动写入的，还有些是某些软件安装器（如VS Code、Docker）自带的。最稳妥的方式，就是进到 sources.list.d 目录，用 ls -la 列出所有文件，逐个审查。我曾遇到一个用户，他的系统里有一个名为 mysql.list 的文件，内容是 deb http://repo.mysql.com/apt/ubuntu/ bionic mysql-8.0 。这个源在20.04发布后， bionic 分支就不再更新，但 focal 分支是有的。如果不清除它，升级脚本会尝试从 bionic 源拉取包，必然失败。正确的做法是，要么删除该文件，要么将其内容中的 bionic 替换为 focal ，并确保 mysql-8.0 这个组件名在focal源中确实存在（查官网文档确认）。

2.3 预判硬件与驱动兼容性：特别是声音、显卡与输入法

网络热词里高频出现的“ubuntu没声音20.04”、“ubuntu 20.04 cc-switch”，直指升级后最常被忽视的硬件适配问题。20.04 默认使用PulseAudio 13.99 + PipeWire 0.3 的混合音频栈，而18.04用的是PulseAudio 12。对于大多数Intel HD Audio芯片，这没问题；但对于一些老旧的Realtek ALC系列声卡（如ALC269、ALC272），或者某些OEM定制的声卡（如联想小新、戴尔XPS的特定型号），升级后可能出现“有声音设备但无输出”的情况。这不是Bug，而是内核声卡驱动模块（ snd_hda_intel ）的参数发生了变化。

同样，“cc-switch”（即 ubuntu-drivers autoinstall 或 nvidia-settings 中的GPU切换）在20.04中行为也有调整。NVIDIA驱动从440系列开始成为主流，而18.04默认的390/418系列驱动，在20.04上可能无法加载。如果你的笔记本是双显卡（Intel集显 + NVIDIA独显），升级前务必确认你当前安装的NVIDIA驱动版本，并查阅 NVIDIA官方驱动支持矩阵，确认其是否支持Ubuntu 20.04和Linux Kernel 5.4。

至于“搜狗输入法”，它是一个典型的闭源商业软件，其deb包内部硬编码了对 libqt5core5a 、 libfcitx-utils0 等库的版本依赖。20.04中这些库的版本号（如 libqt5core5a=5.12.8+dfsg-0ubuntu1 ）与18.04（ 5.9.5+dfsg-0ubuntu2.1 ）不同。强行升级会导致搜狗输入法崩溃或无法启动。我的建议是： 升级前，卸载搜狗输入法，改用系统原生的ibus-pinyin或fcitx5（后者在20.04中已成默认推荐） 。升级完成后再重新安装搜狗，或者直接拥抱fcitx5，它的中文输入体验在20.04上已经非常成熟。

3. 核心升级流程详解：从准备到完成的每一步意图

3.1 第零步：系统更新与清理—— `apt update` 与 `apt upgrade` 的深层含义

很多人把 sudo apt update && sudo apt upgrade 当作一句顺口溜，其实这两个命令承担着完全不同的、不可替代的职责。

sudo apt update ：它的作用不是“更新软件”，而是“更新软件包索引”。它会去 /etc/apt/sources.list 里列出的所有源（如 http://archive.ubuntu.com/ubuntu/ bionic main restricted ）下载一个名为 InRelease 或 Release 的元数据文件。这个文件里包含了该源下所有软件包的名称、版本、大小、校验和（SHA256）等信息。你可以把它想象成一个巨大的Excel表格，表头是包名，每一行是该包在当前源里的最新快照。 没有这一步， apt upgrade 就像一个没有地图的司机，根本不知道哪里有新版本。 我见过太多人，因为网络原因（如DNS污染、源服务器响应慢）导致 apt update 只下载了一半的索引，后续 apt upgrade 就会漏掉关键的安全更新。
sudo apt upgrade ：它的作用是“升级已安装的软件包到其在当前索引中的最新版本”。但它有一个重要原则： 绝不自动安装、删除或降级任何包。 这意味着，如果一个新版本的包，其依赖关系要求必须安装一个你系统里没有的包（比如 libnewstuff1 ）， apt upgrade 会直接跳过这个包，而不是帮你装上 libnewstuff1 。这就是为什么， apt upgrade 之后，你经常会看到一行提示：“ The following packages have been kept back: ”。这些被“扣住”的包，通常是那些需要引入新依赖或删除旧依赖的核心系统包，比如 linux-image-generic 、 ubuntu-desktop 。要升级它们，你必须用 sudo apt full-upgrade （或旧版的 dist-upgrade ），它会智能地计算整个依赖图谱，做出安装、删除、降级的决策。

所以，标准的升级前准备流程是：

# 1. 更新索引（确保拿到最新、最全的包信息）
sudo apt update

# 2. 升级所有“安全且无风险”的包（不会改变依赖关系）
sudo apt upgrade -y

# 3. 升级所有包，包括那些需要改变依赖关系的（这是为do-release-upgrade铺路）
sudo apt full-upgrade -y

# 4. 清理已卸载包残留的配置文件和缓存（释放空间，减少干扰）
sudo apt autoremove --purge -y
sudo apt clean

实操心得： apt full-upgrade 这一步极其关键。我曾帮一位同事处理一台升级失败的服务器，他只做了 apt upgrade ，结果 ubuntu-desktop 被“kept back”，而 do-release-upgrade 在检测时发现核心桌面环境不是最新版，就直接拒绝启动升级。执行 full-upgrade 后，问题迎刃而解。另外， -y 参数是“自动确认”，在批量操作或远程SSH时必不可少，否则脚本会卡在“Do you want to continue? [Y/n]”上。

3.2 主角登场： `do-release-upgrade` 的三种模式与选择逻辑

do-release-upgrade 是Ubuntu官方提供的、专为LTS升级设计的工具。它不是一个简单的“替换所有包”的脚本，而是一个拥有完整状态机的升级引擎。它会分阶段执行：预检（Pre-flight Check）、下载（Download）、预配置（Pre-configure）、安装（Install）、后配置（Post-configure）、清理（Cleanup）。理解它的三种运行模式，能让你在关键时刻做出正确选择。

do-release-upgrade （默认模式） ：这是最安全的模式。它只会检测并升级到“下一个官方支持的LTS版本”。也就是说，如果你在18.04上运行它，它只会找20.04；如果你在20.04上运行，它会找22.04。它会忽略所有非LTS版本（如19.10, 21.04）。这个模式适合绝大多数用户，因为它经过了Canonical最严格的测试。
do-release-upgrade -d （开发版模式） ： -d 代表 devel 。它会强制检查并升级到“最新的、可用的开发版本”，无论其是否为LTS。例如，在20.04上运行 do-release-upgrade -d ，它可能会引导你升级到22.04（如果已发布）或21.10（如果处于开发阶段）。 这个模式极度危险，仅用于测试目的，绝不可用于生产环境。 它绕过了所有LTS的稳定性保障，你可能会遇到未修复的内核panic、图形界面崩溃等严重问题。
do-release-upgrade -p （普适模式） ： -p 代表 proposed 。它会启用 *-proposed 源，这个源里存放的是即将推送到正式源的“候选更新”，通常包含重要的bug修复和安全补丁，但也可能引入新的不稳定因素。 -p 模式常用于在正式版发布后，快速获取针对20.04的早期修复。例如，20.04刚发布时，某些Wi-Fi网卡驱动存在连接不稳定的问题，Canonical会在 -proposed 源里先放出修复包，经过社区反馈验证无误后，再推送到 main 源。使用 -p 模式，需要你先手动在 /etc/apt/sources.list 中取消注释 *-proposed 行，再运行 apt update 。

我的建议是： 永远从默认模式开始。 如果 do-release-upgrade 报错说“没有找到新版本”，请首先检查你的 sources.list 是否被意外修改，或者你的系统是否真的满足升级条件（如磁盘空间不足、PPA未清理）。不要一上来就加 -d ，那相当于开着没有安全气囊的车去越野。

3.3 升级过程中的关键交互与决策点

当 do-release-upgrade 开始运行后，它会进入一个半交互式的流程。屏幕上会不断滚动日志，其中几个关键节点需要你特别注意：

“Checking for a new Ubuntu release” ：这是预检阶段。它会检查网络连通性、源可用性、磁盘空间（至少需要25GB空闲）、内存（建议8GB以上，低于4GB会警告）、以及最重要的——是否有未完成的包操作（ dpkg lock）。如果这里卡住，90%的原因是 apt 或 dpkg 进程被其他程序（如Ubuntu Software Center、 apt 后台服务）锁住了。解决方法是： sudo lsof /var/lib/dpkg/lock-frontend 查看哪个进程在占用，然后 sudo kill -9 <PID> 杀掉它，再 sudo dpkg --configure -a 修复。
“Fetching the upgrade” ：这是下载阶段。 do-release-upgrade 会计算出需要下载的所有新包（通常超过2000个，总大小1.5GB~3GB），然后并行下载。此时，你的网络带宽会被占满。如果你的网络不稳定，下载中途断开，脚本会自动重试。但如果断开次数过多，它会放弃并提示错误。最佳实践是：在开始前，先运行 sudo apt-get install -y aria2 ，然后编辑 /etc/update-manager/release-upgraders ，将 download-command 的值改为 aria2c -x 16 -k 1M --file-allocation=none 。这样就能利用 aria2 这个高速多线程下载器，大幅提升下载成功率与速度。
“Installing the upgrade” ：这是最危险的阶段。它会按严格顺序安装新包，并执行每个包的 postinst 脚本。此时，你可能会看到类似 “Configuring linux-image-5.4.0-xx-generic …” 的提示。 千万不要关闭终端、不要重启电脑、不要按Ctrl+C！ 这个过程可能持续30分钟到2小时不等，取决于你的硬盘速度。如果它卡在某个包的配置上（比如MySQL、PostgreSQL、Samba），说明该服务的配置文件与新版本不兼容。此时，脚本会暂停，并给出一个菜单，让你选择“Keep your currently-installed version”（保留旧版）或 “Install the package maintainer’s version”（安装新版并覆盖）。我的经验是：对于数据库、Web服务器等关键服务，选“Keep”；对于内核、桌面环境等系统核心，选“Install”。
“System upgrade is complete” ：最后一步，它会提示你重启。此时，它已经完成了所有工作，只是还没有激活新内核和新桌面环境。 重启是必须的。 不要试图用 sudo systemctl reboot 以外的方式重启，否则可能导致系统处于半升级状态。

4. 升级后的深度验证与问题修复：从“能开机”到“能干活”

4.1 基础功能验证清单：一份不能妥协的检查表

升级完成并重启后，不要急着打开浏览器或IDE。先静下心来，按以下清单逐项验证。每一项都对应着一个潜在的、可能在未来某天让你抓狂的隐患。

检查项	验证命令/方法	期望结果	失败含义
1. 内核版本	`uname -r`	输出应为 `5.4.0-xx-generic` （xx为具体数字）	仍为4.15.x，说明新内核未被设为默认启动项，需检查GRUB配置
2. Ubuntu版本	`lsb_release -a`	`Description` 应为 `Ubuntu 20.04.6 LTS` ， `Codename` 应为 `focal`	仍是 `bionic` ，说明 `/etc/os-release` 未更新，或 `do-release-upgrade` 未完成
3. APT源地址	`grep focal /etc/apt/sources.list`	应能查到大量 `focal` 、 `focal-updates` 、 `focal-security` 等行	仍是 `bionic` ，说明源未自动切换，需手动编辑 `sources.list` 并 `apt update`
4. 网络连通性	`ping -c 3 archive.ubuntu.com`	应能收到3个回复	DNS或路由故障，需检查 `/etc/resolv.conf` 和 `systemd-resolved` 状态
5. 图形界面	`echo $XDG_SESSION_TYPE`	应输出 `x11` 或 `wayland`	输出为空，说明显示管理器（GDM3）未启动，需 `sudo systemctl status gdm3`
6. 声音输出	`speaker-test -l1 -s1`	应听到“front-left”测试音	无声，需检查PulseAudio状态、声卡驱动加载情况
7. 无线网络	`nmcli device wifi list`	应列出附近所有Wi-Fi热点	无输出，可能是固件缺失或驱动未加载，需 `dmesg

提示：这个清单里的每一项，我都曾在真实客户现场遇到过。最典型的是第3项“APT源地址”。有一次，一台服务器升级后， lsb_release 显示是20.04，但 apt update 却报错说找不到 bionic 源。排查发现， do-release-upgrade 在写入新 sources.list 时，因为磁盘I/O错误，只写入了一半，导致文件末尾是乱码。手动修复后才恢复正常。所以，不要迷信“升级成功”的提示，动手验证才是王道。

4.2 解决“ubuntu没声音20.04”：从驱动到配置的全链路排查

“没声音”是20.04升级后最高频的问题，其根源往往不在PulseAudio本身，而在底层的ALSA驱动或内核模块。以下是我在三台不同机器上总结出的、行之有效的排查与修复流程：

第一步：确认声卡被识别

# 列出所有声卡设备
lspci | grep -i audio
# 输出示例：00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller

# 查看ALSA是否加载了对应的驱动模块
aplay -l
# 如果输出 “no soundcards found”，说明 `snd_hda_intel` 模块根本没加载。

第二步：检查驱动模块状态

# 查看 `snd_hda_intel` 模块是否已加载
lsmod | grep snd_hda_intel

# 如果没有，尝试手动加载
sudo modprobe snd_hda_intel

# 如果报错 “Module snd_hda_intel not found”，说明内核模块包缺失，需安装
sudo apt install linux-modules-extra-$(uname -r)

第三步：处理Realtek声卡的常见问题 对于 alc269 , alc272 , alc283 等Realtek芯片，最常见的问题是内核参数不匹配。你需要编辑 /etc/default/grub ：

# 找到 GRUB_CMDLINE_LINUX_DEFAULT 这一行
# 在引号内添加：snd_hda_intel.dmic_detect=0
# 修改后变为：GRUB_CMDLINE_LINUX_DEFAULT="quiet splash snd_hda_intel.dmic_detect=0"

# 保存后更新GRUB
sudo update-grub
sudo reboot

这个参数的作用是禁用数字麦克风（DMIC）检测，强制声卡使用模拟线路输出，能解决90%的“有设备无声音”问题。

第四步：重置PulseAudio配置 如果硬件层面没问题，问题大概率出在用户配置上。PulseAudio的用户配置文件（ ~/.config/pulse/ ）在升级过程中可能被损坏。

# 备份旧配置
mv ~/.config/pulse ~/.config/pulse.backup

# 删除所有pulse相关进程
pulseaudio -k

# 重启pulseaudio（它会自动生成新配置）
pulseaudio --start

# 测试
speaker-test -l1 -s1

4.3 安装MySQL 8.0.25与VINS-MONO：升级后服务的重建策略

网络热词“ubuntu 20.04 安装mysql8.025”和“vins mono ubuntu 20.04”，指向了一个关键事实： 升级不是“无缝”的，所有你手动安装的第三方服务，都需要在新系统上重新部署。 MySQL 8.0.25是一个具体的、较新的版本号，它不包含在Ubuntu 20.04的官方仓库中（官方仓库提供的是8.0.28或更高）。VINS-MONO则是一个复杂的C++视觉SLAM框架，其编译依赖（如Ceres Solver、OpenCV 4.2+、Eigen 3.3+）在20.04中版本更新，必须重新编译。

MySQL 8.0.25的安装策略：

优先使用官方APT源 ：Ubuntu 20.04官方源中的MySQL 8.0.x（如8.0.28）已经过充分测试，兼容性最好。除非你有强需求（如必须用25版的某个特定bug修复），否则不要自行编译。
如果必须安装25版 ：去 MySQL官方下载页下载 mysql-server_8.0.25-1ubuntu20.04_amd64.deb-bundle.tar 。解压后，按顺序安装：

# 必须按此顺序，否则依赖报错
sudo dpkg -i mysql-common_8.0.25-1ubuntu20.04_amd64.deb
sudo dpkg -i mysql-community-client-plugins_8.0.25-1ubuntu20.04_amd64.deb
sudo dpkg -i mysql-community-client-core_8.0.25-1ubuntu20.04_amd64.deb
sudo dpkg -i mysql-community-client_8.0.25-1ubuntu20.04_amd64.deb
sudo dpkg -i mysql-client_8.0.25-1ubuntu20.04_amd64.deb
sudo dpkg -i mysql-community-server-core_8.0.25-1ubuntu20.04_amd64.deb
sudo dpkg -i mysql-community-server_8.0.25-1ubuntu20.04_amd64.deb
sudo dpkg -i mysql-server_8.0.25-1ubuntu20.04_amd64.deb

安装完成后， sudo apt install -f 会自动修复所有依赖。

VINS-MONO的编译策略： VINS-MONO的官方GitHub Wiki明确指出，它在Ubuntu 20.04 + ROS Noetic环境下需要额外的步骤。核心难点在于Ceres Solver的编译。20.04的 libceres-dev 包版本（1.14.0）与VINS-MONO要求的（1.13.0）不完全兼容。我的解决方案是：

卸载系统自带的 libceres-dev ： sudo apt remove libceres-dev
从源码编译Ceres 1.13.0：

git clone https://github.com/ceres-solver/ceres-solver.git
cd ceres-solver
git checkout 1.13.0
mkdir build && cd build
cmake .. -DBUILD_TESTING=OFF -DBUILD_EXAMPLES=OFF
make -j$(nproc)
sudo make install

然后，再按照VINS-MONO官方README，正常编译即可。关键点是，在 catkin_make 之前，确保 pkg-config --modversion ceres 输出的是 1.13.0 。

5. 常见问题与独家避坑指南：那些只有踩过才知道的坑

5.1 “ `do-release-upgrade` 卡在‘Reading cache’”：磁盘I/O与APT锁的双重陷阱

这是升级过程中最令人抓狂的问题之一。屏幕长时间停留在 “Reading cache of installed packages…” 这一行，CPU和磁盘使用率都极低，仿佛系统死机。实际上，它是在读取 /var/lib/apt/lists/ 目录下成百上千个 Packages 文件，构建一个巨大的内存缓存。如果这个目录里有损坏的、不完整的 Packages 文件（比如上次 apt update 断网导致的）， do-release-upgrade 就会在这里无限循环。

独家解决方案：

# 1. 彻底清空APT缓存（比 apt clean 更彻底）
sudo rm -rf /var/lib/apt/lists/*
sudo mkdir -p /var/lib/apt/lists/partial

# 2. 重新生成一个干净、最小化的sources.list（只保留主源）
echo "deb http://archive.ubuntu.com/ubuntu/ focal main restricted" | sudo tee /etc/apt/sources.list
echo "deb http://archive.ubuntu.com/ubuntu/ focal-updates main restricted" | sudo tee -a /etc/apt/sources.list
echo "deb http://security.ubuntu.com/ubuntu/ focal-security main restricted" | sudo tee -a /etc/apt/sources.list

# 3. 强制更新（这次会非常快，因为只下载3个源）
sudo apt update

# 4. 再次运行升级
sudo do-release-upgrade

这个方法之所以有效，是因为它绕过了所有可能损坏的第三方源和庞大的索引文件，用最精简的配置，让 do-release-upgrade 能够顺利启动。等升级成功后，你再慢慢把之前禁用的PPA一个个加回来，并用 apt update 测试其可用性。

5.2 “升级后无法登录图形界面，黑屏或卡在GDM登录框”：Wayland与NVIDIA的恩怨情仇

这个问题在搭载NVIDIA独显的笔记本上尤为突出。20.04的GDM3默认尝试启动Wayland会话，而NVIDIA的开源驱动（ nouveau ）和部分闭源驱动（<440）对Wayland的支持不完善，导致GDM无法初始化显示。

终极解决办法：强制GDM使用Xorg会话。 编辑 /etc/gdm3/custom.conf ：

# 取消下面这行的注释
WaylandEnable=false

然后重启GDM： sudo systemctl restart gdm3 。如果GDM完全崩溃，无法进入图形界面，你需要在登录框按 Ctrl+Alt+F3 切换到TTY终端，登录后执行上述命令。

注意：这个设置只影响GDM的登录管理器，不影响你登录后选择的桌面会话（GNOME on Xorg 或 GNOME on Wayland）。它只是确保你能成功登录。

5.3 “ `sudo apt update` 报错 ‘The repository does not have a Release file’”：源地址失效的精准定位与修复

这个错误意味着APT在某个源地址下，找不到 Release 或 InRelease 文件。原因通常是：1）你手动添加了一个已废弃的PPA；2）Ubuntu官方源的镜像站（mirror）暂时宕机；3）你的 sources.list 里混入了为其他发行版（如Debian）写的源。

精准定位方法：

# 运行update，并将错误输出保存
sudo apt update 2>&1 | tee update.log

# 在update.log中搜索关键词
grep "The repository" update.log
# 输出示例：E: The repository 'http://ppa.launchpad.net/xxx/yyy/ubuntu focal Release' does not have a Release file.

# 这行输出就精确指出了是哪个PPA（http://ppa.launchpad.net/xxx/yyy/ubuntu）出了问题。

定位到问题源后，解决方案就很简单了：要么 sudo rm /etc/apt/sources.list.d/xxx-yyy-ubuntu-focal.list 删除它，要么访问该PPA的Launchpad页面，确认它是否真的支持 focal 。如果不支持，就只能放弃。

5.4 “升级后Wi-Fi无法连接， `dmesg` 显示 ‘firmware failed to load’”：固件缺失的快速补救

Intel和Broadcom的无线网卡，其固件（firmware）是独立于内核驱动的二进制 blob，存放在 /lib/firmware/ 目录下。20.04的内核（5.4）需要更新的固件版本，而18.04的固件包（ linux-firmware ）可能不包含它们。

一键修复：

# 下载并安装最新的linux-firmware包（来自20.04官方源）
wget http://archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.187.24_all.deb
sudo dpkg -i linux-firmware_1.187.24_all.deb

# 重新加载无线网卡驱动
sudo modprobe -r iwlwifi  # Intel
# 或
sudo modprobe -r brcmfmac # Broadcom
sudo modprobe iwlwifi
# 或
sudo modprobe brcmfmac

这个方法比等待 apt update && apt upgrade 更快，因为它直接获取了目标版本的固件包，避免了因源同步延迟导致的等待。

6. 升级后的系统优化与长期维护：让20.04真正为你所用

6.1 从 `apt` 到 `aptitude` ：高级包管理的进阶选择

apt 是Ubuntu默认的包管理前端，简单易用，但对于复杂的依赖冲突，它有时显得力不从心。 aptitude 是一个更古老、但也更强大的前端，它内置了一个先进的依赖求解器，能提供多种解决方案供你选择。

例如，当你想安装一个新软件，但APT提示会删除一堆你不想删的包时， aptitude 会列出3-4种不同的解决路径：

方案1：安装新软件，同时降级 libxyz1 到旧版本。
方案2：安装新软件，同时删除 package-A 和 package-B 。
方案3：不安装，保持现状。

你可以用方向键选择最合适的方案，按 g （go）执行。这对于维护一个运行着多个相互依赖服务的生产服务器来说，是无价的。

安装与使用：

sudo apt install aptitude
# 用法与apt几乎一样，只是命令名不同
sudo aptitude update
sudo

标签

#Ubuntu 20.04升级 #do-release-upgrade #ubuntu没声音20.04