1. 从Ubuntu 18.04到22.04一次跨越两个LTS版本的升级决策如果你还在用Ubuntu 18.04现在可能是时候考虑升级了。这个发布于2018年的长期支持版本其官方支持已经在2023年4月结束。这意味着除非你购买了付费的扩展安全维护服务否则你的系统将不再接收任何安全更新和关键修复。对于一个需要稳定运行的生产环境或日常开发机来说这无疑是一个潜在的风险源。而Ubuntu 22.04 LTS作为最新的长期支持版本不仅带来了长达五年的官方支持还集成了更新的内核、更现代的桌面环境、对新型硬件的更好支持以及大量软件包的更新。从18.04直接跳到22.04中间跨越了20.04这个版本这并非官方推荐的常规升级路径但通过一些特定的方法是完全可行且经过大量用户验证的。这篇文章我将结合自己多次在不同场景下执行此类升级的经验为你梳理出一条清晰、稳妥的升级路线并重点分享那些官方文档里不会写的“坑”和应对技巧。2. 升级前的全面评估与准备工作在按下升级命令之前盲目的操作是灾难的开始。一次成功的系统升级七分靠准备三分靠执行。对于从18.04到22.04这样的大跨度升级准备工作尤为重要。2.1 环境与数据备份你的安全网这是最重要、没有之一的一步。无论升级过程描述得多么平滑你都必须假设最坏的情况升级失败系统无法启动。完整系统备份对于物理机或虚拟机最稳妥的方式是使用像Clonezilla这样的工具对整个磁盘或系统分区进行镜像备份。对于云服务器充分利用云服务商提供的快照功能。在升级前创建一个完整的系统盘快照一旦升级出现问题你可以分钟级回滚到升级前的状态这是成本最低的后悔药。关键数据备份即使有系统备份个人数据也应单独备份。这包括家目录(/home/你的用户名)这里存放了你的所有配置文件、文档、下载内容等。可以直接打包压缩备份到外部存储或另一个分区。服务数据如果你在系统上运行了MySQL、PostgreSQL、Docker容器等确保你知道它们的数据存储在哪里通常是/var/lib/mysql,/var/lib/postgresql,/var/lib/docker等并进行导出或目录备份。配置文件重点备份/etc目录特别是你修改过的服务配置文件如nginx, apache2, ssh等。可以使用命令sudo tar -czvf etc_backup.tar.gz /etc进行打包。应用清单记录运行dpkg --get-selections installed_packages.list将当前系统所有已安装的软件包列表导出到一个文件。这不会备份软件本身但在全新安装后它可以作为恢复软件环境的参考。不过要注意跨大版本时很多软件包名和版本会发生巨大变化此列表仅供参考。2.2 系统状态检查与问题修复一个“带病”的系统进行升级失败率会急剧升高。在升级前请确保你的18.04系统处于一个相对健康的状态。更新当前系统首先确保你的18.04系统已经更新到最新状态。这能解决许多已知的依赖问题和冲突。sudo apt update sudo apt upgrade sudo apt dist-upgrade运行dist-upgrade时请仔细看它会做什么有时它会处理一些内核或关键库的升级。清理无用包使用sudo apt autoremove清理不再需要的依赖包。也可以使用sudo apt clean清理下载的软件包缓存但这会在升级初期重新下载大量包根据你的网络情况决定是否执行。检查磁盘空间大版本升级过程会下载大量软件包并进行解压安装。确保你的根分区至少有10-15GB的可用空间。使用df -h命令检查。解决“锁”问题如果之前有apt或dpkg进程异常中断可能会留下锁文件导致升级工具无法运行。如果遇到类似“无法获得锁 /var/lib/dpkg/lock-frontend”的错误可以尝试删除锁文件需谨慎确保没有其他包管理进程在运行sudo rm /var/lib/apt/lists/lock sudo rm /var/lib/dpkg/lock-frontend sudo rm /var/lib/dpkg/lock2.3 升级路径规划直接跳跃还是分步走从Ubuntu 18.04 LTS升级到22.04 LTS官方的do-release-upgrade工具通常设计为一次只升级到下一个LTS版本即18.04 - 20.04。如果你想直接跳到22.04需要修改工具的升级策略设置。方法一分两步走最稳妥这是官方推荐且支持度最好的路径。先升级到20.04等系统完全稳定、所有服务验证无误后再从20.04升级到22.04。这样做的好处是每次升级的变动相对较小出现问题容易定位和回滚。缺点是耗时较长需要经历两次完整的升级过程。方法二修改配置直接升级到22.04通过修改/etc/update-manager/release-upgrades文件将Prompt的值从lts改为normal可以尝试让系统识别到22.04作为可用升级。但请注意这并非官方为18.04设计的标准路径可能会遇到更多不可预见的依赖和冲突问题。本文后续将主要介绍这种方法因为它更符合“从18.04升级到22.04”这个直接需求但我会同时指出其中比常规升级更多的风险点。3. 执行升级核心步骤与实时监控准备工作就绪后我们就可以开始执行升级操作了。整个过程可能需要1到3个小时具体取决于你的网速、硬件性能和已安装软件的数量。请确保设备连接稳定电源网络通畅。3.1 配置升级管理器以允许大版本跳跃首先我们需要告诉系统我们想要升级到的目标版本是22.04而不是默认的下一个LTS20.04。编辑升级管理器配置文件sudo nano /etc/update-manager/release-upgrades找到Promptlts这一行将其修改为Promptnormal。normal模式会检查所有可用的新版本而lts模式只检查下一个LTS版本。保存并退出编辑器。注意这个操作是让系统“看到”22.04升级选项的关键。但这也意味着升级工具会尝试应用一个非标准的升级路径在过程中需要你更加警惕。3.2 启动升级进程现在可以运行官方的升级工具了。首先再次更新软件源列表确保信息是最新的sudo apt update运行升级命令sudo do-release-upgrade如果你是通过SSH连接到服务器进行升级强烈建议使用screen或tmux会话防止网络中断导致升级过程被杀掉造成系统损坏。命令如下sudo apt install screen -y screen -S upgrade sudo do-release-upgrade运行screen后即使你断开SSH连接升级进程也会在后台继续。之后可以通过screen -r upgrade重新连接回会话。3.3 升级过程中的关键决策点升级工具启动后会进行一系列检查然后开始下载软件包。在这个过程中你会遇到几个需要交互确认的环节确认新版本工具会提示你发现了Ubuntu 22.04 “Jammy Jellyfish”并询问是否开始升级。输入y并回车继续。处理过时的配置文件这是升级中最容易出问题也最需要人工干预的环节。当工具检测到系统中某个软件的配置文件在新版本中发生了变化无论是格式还是默认值它会停下来问你如何处理。通常有三个选项Y或I安装软件包维护者的版本即用全新的默认配置覆盖你当前的配置。选择这个会丢失你所有的自定义配置N或O保持你当前本地的版本不更新配置文件。这可能导致新软件无法正常运行因为配置格式可能已不兼容。D显示差异看看新旧配置文件具体有什么不同。Z启动一个shell让你可以手动查看和编辑文件。我的经验是对于像/etc/ssh/sshd_config,/etc/nginx/nginx.conf这类你明确做过大量修改的核心服务配置优先选择N保留本地版本。升级完成后再根据新版本的配置模板手动合并你的修改。对于你不确定或者没改过的配置可以选择Y用新版本覆盖。在遇到每个提示时如果不确定先选D查看差异再做决定。这个过程可能会反复出现几十次需要耐心处理。重启提示所有软件包安装、配置完成后工具会提示需要重启系统以使用新内核和完成升级。确认重启。4. 升级后的验证、问题排查与修复系统重启后你应该会进入Ubuntu 22.04。但工作还没结束现在进入关键的“验伤”和“康复”阶段。4.1 基础系统验证首先进行一些基础检查检查版本运行lsb_release -a和cat /etc/os-release确认系统版本已是22.04。检查内核运行uname -r内核版本应该已经更新到5.15或更高。检查网络确保网络连接正常可以ping通外网。检查用户环境登录你的普通用户账户检查桌面环境如果是桌面版是否正常终端是否可以打开。4.2 常见问题与解决方案跨两个大版本升级几乎必然会遇到一些兼容性问题。下面是一些最常见的问题及其处理思路。问题一软件源列表错误导致apt update失败升级后旧的18.04软件源如bionic可能还残留在/etc/apt/sources.list或/etc/apt/sources.list.d/目录下的某些文件中。这会导致sudo apt update时报错“Release file for ... is not valid yet”或找不到仓库。解决手动检查并修改所有源文件。将文件中所有出现的bionic替换为jammy。你可以使用以下命令进行全局查找和替换操作前建议备份sudo sed -i s/bionic/jammy/g /etc/apt/sources.list sudo sed -i s/bionic/jammy/g /etc/apt/sources.list.d/*.list然后再次运行sudo apt update。问题二第三方PPA源失效你之前为18.04添加的很多个人软件包存档可能不提供22.04的版本。这会导致apt update时大量“404 Not Found”错误。解决最根本的方法是在升级前就禁用或移除这些PPA。升级后可以逐一检查并处理。你可以直接注释掉/etc/apt/sources.list.d/目录下对应PPA的.list文件或者使用sudo add-apt-repository --remove ppa:ppa_name/ppa来移除。对于你仍然需要的软件去其官网查找是否提供了支持22.04的新PPA或安装方式。问题三图形界面GUI相关问题桌面版桌面环境崩溃或无法登录这通常与显卡驱动有关。Ubuntu 22.04默认使用了更新的显示服务器和内核旧的专有显卡驱动可能不兼容。解决尝试在登录界面按CtrlAltF2切换到TTY命令行界面。先卸载旧的显卡驱动如果你之前安装过然后安装Ubuntu 22.04推荐的开源驱动或从显卡官网下载对应22.04的新版驱动。对于NVIDIA用户可以尝试sudo apt purge *nvidia* sudo apt install nvidia-driver-535 # 安装一个较新的通用版本驱动 sudo reboot应用程序图标丢失或主题错乱升级可能破坏了用户级别的主题或图标缓存。解决尝试重建图标缓存和GTK缓存sudo update-icon-caches /usr/share/icons/* gtk-update-icon-cache或者直接切换回默认主题再切换回来。问题四服务启动失败某些在18.04上运行良好的服务如自定义的systemd服务、数据库、Web服务器可能在22.04上因为库依赖、配置文件格式或默认行为改变而无法启动。解决查看日志使用sudo journalctl -u service_name.service -xe或sudo systemctl status service_name.service查看具体的错误信息。检查依赖错误信息常常会提示缺少某个.so库文件。这通常是因为该库在22.04中版本更新或已被其他包替代。你可以尝试安装新版本的库或者使用apt-file search libxxx.so来查找提供该库的软件包。审查配置文件如果升级时你选择了保留旧配置文件很可能它与新版本软件不兼容。去/usr/share/doc/package_name/下找到新版本的配置样例与你的旧配置进行对比合并。问题五Python环境混乱Ubuntu 18.04默认带Python 3.6而22.04默认是Python 3.10。如果你系统里有很多依赖于特定Python版本的工具或脚本例如一些旧的pip安装的CLI工具它们可能会全部失效。解决不要动系统的Python3/usr/bin/python3是系统管理用的不要尝试降级或移除它。使用python3.10在命令行中现在应该使用python3.10和pip3.10来调用新版本的Python和pip。为旧项目使用虚拟环境对于必须运行在Python 3.6下的项目强烈建议使用pyenv或virtualenv创建一个独立的3.6环境而不是去修改系统环境。重新安装pip包对于通过pip安装的全局工具如awscli,ansible等很可能需要你用pip3.10重新安装一次。4.3 性能与稳定性优化升级完成后建议进行一些优化操作让系统运行得更顺畅。清理旧内核和缓存升级后旧的内核版本仍然会保留在系统中占用/boot分区空间。可以安全地移除它们sudo apt autoremove --purge这个命令会移除不再需要的旧内核包和依赖。你也可以使用uname -r查看当前运行的内核然后使用dpkg --list | grep linux-image列出所有内核镜像手动删除旧的。重建软件包数据库有时升级后包管理器的状态可能会有一些小问题。运行以下命令进行修复sudo dpkg --configure -a sudo apt install -f监控系统资源升级后的一两天内多关注一下系统的资源使用情况使用htop,nmon等工具看看是否有异常进程或内存泄漏确保所有自定义的服务都按预期运行。5. 针对特定场景的升级补充说明根据你使用Ubuntu的具体场景可能还需要关注一些特殊方面。服务器无GUI环境对于纯命令行服务器升级过程通常更平滑因为少了图形界面这个复杂变量。核心关注点在于服务配置如前所述重点处理/etc/下的服务配置文件。防火墙规则Ubuntu 22.04默认使用nftables作为iptables的后端但iptables命令依然可用。如果你的防火墙脚本直接操作iptables通常兼容。但如果涉及更底层的规则建议检查一下。定时任务检查crontab -e中的任务确保脚本路径和解释器如#!/bin/bash仍然有效。开发环境开发工具链的变动可能是最大的挑战。GCC/Clang版本22.04提供了更新的编译器。如果你的项目有严格的编译要求可能需要调整CMakeLists.txt或Makefile。Docker如果使用Docker确保Docker服务在升级后正常启动。可能需要重新安装Docker或调整存储驱动22.04可能使用overlay2。Node.js/Python/Java版本这些运行时的版本在22.04中都有较大提升。使用版本管理工具如nvm,pyenv,sdkman是管理多版本共存的最佳实践可以避免系统升级带来的冲击。桌面环境下的特殊应用如果你依赖一些通过Snap或Flatpak安装的软件它们通常与系统版本无关升级后应能正常工作。但通过deb包或自己编译安装的软件就需要重新安装或编译以适应新的库环境。从Ubuntu 18.04升级到22.04虽然步骤清晰但绝对不是一个“一键无忧”的过程。它更像是一次系统的“大修”考验的是你对系统的了解程度和事前准备是否充分。我个人的经验是对于生产服务器如果有条件更推荐采用备份数据、全新安装22.04、然后迁移数据和配置的方式这样能得到一个最干净、最稳定的系统。但对于已经深度定制、安装了大量软件的个人开发机或测试环境通过本文描述的升级路径则能最大程度保留你的工作环境。无论选择哪条路充分的备份都是你敢于执行任何操作的最大底气。升级完成后享受新系统带来的更快速度、更好兼容性和更长的支持周期吧。