前阵子帮一台老服务器换系统我又把 Ubuntu 22.04 从头到尾折腾了一遍。说实话Ubuntu 22.04 LTS 到现在已经不算“新系统”了但在服务器和嵌入式开发这两个场景里它反而成了最稳的“中间地带”比 20.04 软件新比 24.04 少踩很多兼容性坑很多第三方工具链、离线安装包、安全启动相关的资料也都停在 22.04 上。这篇文章就是把我在 Ubuntu 22.04 上遇到的问题和解决方法整理成一份“可以直接抄作业”的合集涵盖 Server 版下载、基础配置、离线安装 ClamAV帖子里的 clarmav 通常指的就是它、OP-TEE 开发环境 shell 配置等几个高频场景适合运维、嵌入式开发和刚接触 Ubuntu 22 的初学者参考。1. 版本选型与 Server 版下载安装要点1.1 为什么现在还用 Ubuntu 22.04每次新版本发布总有人问“要不要追新”我的观点很明确看场景。24.04 发布后很多底层库默认版本变化比较大比如 OpenSSL、Python 版本和 GCC 工具链行为都改了一些老的嵌入式 SDK 和交叉编译工具链在 24.04 上容易出现 glibc 版本冲突而 Ubuntu 22.04 的软件生态处于一个相对稳定的状态。对于跑生产服务的机器稳定性和可复现性永远比新功能重要。还有一个原因是第三方的离线依赖包。很多工业软件、杀毒引擎、加密模块的离线安装包只适配到 22.04社区验证最多的也是 22.04。比如后文要讲的 ClamAV 离线部署官方发布的 .deb 包在 22.04 上的依赖关系最干净其他版本可能要手动处理 libmspack、libjson-c 这类底层依赖非常折磨人。1.2 Server 版下载的几个关键细节先解决最基础的“Ubuntu 22.04 Server 下载”问题。很多人一上来就搜下载链接却忽略了两件重要的事校验镜像完整性和确认固件文件。我一般会同时下载两个文件ubuntu-22.04.x-live-server-amd64.iso和对应的SHA256SUMS。下载后第一时间执行校验sha256sum -c SHA256SUMS 21 | grep OK这个动作太重要了。ISO 文件体积大下载过程中断或者源站出错都可能导致镜像残缺而这样的镜像在安装到一半时才会报错排查起来极其痛苦。写盘工具方面Linux 环境我直接用ddWindows 下推荐 Rufus。需要注意 Rufus 里有两个模式DD 镜像模式和 ISO 模式。Ubuntu 22.04 的 Server 版建议直接选 DD 模式写入因为它的镜像结构比较特殊ISO 模式可能会做成“启动失败”的盘。装完开机后看不到传统安装界面很正常UEFI Secure Boot 下会直接进 GRUB。如果之前一直用传统 BIOS刚接触 UEFI 会有点不适应但这其实是个好现象说明安全启动体系正常工作了。1.3 安装时顺手做的三个选择安装到“Profile setup”那一步至少把这三个选项改了否则后面会很痛苦主机名不要用默认的ubuntu服务器多了之后全是ubuntu管理混乱。勾选“Install OpenSSH server”哪怕现在用不着以后远程排查会感谢自己。在盘符选择里手动配置 LVM 逻辑卷不要把整个根分区撑满至少留 20 GB 空闲给 Docker 镜像、缓存和快照。安装过程中把 Snap 相关的问题先放一放装完再处理。Ubuntu 22.04 的安装器本身也有点吃内存内存小于 2 GB 的机器装 Server 版会明显慢这是正常现象不要以为是死机。2. 装完系统后的基础配置与软件源问题处理2.1 软件源那份“老生常谈”的正确姿势Ubuntu 22.04 默认使用的是 archive.ubuntu.com 的源在国内环境下速度通常不理想。换源几乎是装完系统后第一件事但这里有一个容易忽略的点22.04 的源配置位置已经不是老的/etc/apt/sources.list为主而是 Ubuntu 24.04 前的过渡版本实际上 22.04 的软件源定义在/etc/apt/sources.list和/etc/apt/sources.list.d/下但不少新工具会选择其中一种。处理时我不会直接删掉原文件而是备份后在/etc/apt/sources.list里替换sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i s/archive.ubuntu.com/mirrors.aliyun.com/g; s/security.ubuntu.com/mirrors.aliyun.com/g /etc/apt/sources.list sudo apt update这里提一句很多人说 22.04 用/etc/apt/sources.list.d/ubuntu.sources这种 deb822 格式其实那是在 24.04 才开始正式主推的。22.04 里你把源写在哪个文件不重要关键是apt update之后的输出里不要出现大量404 Not Found。一旦出现 404基本就是源文件路径和版本代号jammy对不上别瞎调直接恢复备份重来。2.2 必做的系统配置项装完 22.04 Server 后我通常会先做这几件事按优先级排序换源之后先升级内核补丁sudo apt update sudo apt upgrade -y sudo reboot然后调整时区。服务器时区错了日志排查和时间戳对比会非常痛苦sudo timedatectl set-timezone Asia/Shanghai sudo timedatectl set-ntp yes这里有个 Ubuntu 22.04 特有的坑默认的systemd-timesyncd会和 NTP 服务冲突。如果你后来装了ntpdate或者chrony又不小心启用了 systemd-timesyncd时间会反复跳变。排查思路后面统一说。接着关闭休眠挂起。Server 版默认不会自动休眠但如果你是从桌面版改装的最好手动关掉sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target这不是强迫症机房服务器如果因为 lid switch 或者电源策略进入休眠起不来才是大麻烦。2.3 Snap 与 APT 的冲突Ubuntu 22.04 里 Snap 是个绕不开的话题。很多包默认用 Snap 装比如 firefox、certbot而 Snap 版本的软件启动慢、目录路径特殊经常被拿来和生产环境折腾。我的经验是Server 环境里尽量避免用 Snap 安装服务型软件宁可加 PPA 源或者直接下载 .deb 包。如果系统里已经占用了 Snap 防火墙规则snapd 会自动建立一堆 nft 规则而你又在用 Docker 或者 ufw可能遇到端口转发不生效的情况。排查时可以看sudo systemctl status snapd sudo nft list ruleset | grep -i snap如果是 Snap 的接口规则干扰了端口需要停掉对应服务并snap remove相关包。注意不要直接把 snapd 停掉就完事小心加固的过滤策略会让整个网络异常。3. 高频故障排查记录3.1 APT 锁与依赖损坏“Could not get lock /var/lib/dpkg/lock-frontend” 是出现频率最高的报错之一。遇到这种情况先别急着rm -rf先确认是不是有 apt 进程还在跑ps aux | grep -E apt|dpkg如果确实有进程残留再考虑强制解锁sudo fuser -vki /var/lib/dpkg/lock sudo dpkg --configure -a sudo apt --fix-broken install依赖损坏时apt --fix-broken install基本都能解决但如果报错里提到held broken packages多半是手动装过某些底层库。这时候可以用apt-cache rdepends反查别盲目移除。我踩过最重的坑是手滑删了libc6最后只能靠 chroot 恢复。所以这里强调一句任何强制移除操作之前先确认有没有反向依赖。3.2 时间不同步问题速查Ubuntu 22.04 时间问题我用一个表格总结排查顺序现象可能原因处理命令时间延迟几分钟systemd-timesyncd 未开启sudo timedatectl set-ntp true时间跳变且不稳定多个 NTP 服务冲突sudo systemctl disable chrony sudo systemctl restart systemd-timesyncdUTC 和本地时间错乱时区配置错误sudo timedatectl set-timezone Asia/Shanghai重启后时间回退硬件时钟设为本地时间sudo timedatectl set-local-rtc false多数情况下手动执行sudo ntpdate -u ntp.aliyun.com能立即校正但注意这只是临时方案而且要确认 ntpdate 和 systemd-timesyncd 不会同时运行。3.3 磁盘空间清理Ubuntu 22.04 跑久之后/var/log/journal通常能占到好几个 GB这是很多“磁盘满了但找不到大文件”的根源。查法sudo journalctl --disk-usage保留两天的日志就够日常排错了sudo journalctl --vacuum-time2d另外apt的缓存也要定期清sudo apt clean sudo apt autoclean sudo apt autoremove --purge -y对桌面版用户~/snap目录会越来越大。这个目录是 Snap 应用的数据和版本快照有些旧版本不会自动清理可以手动把/snap/*/里的旧版本删掉。大约能省下 2~3 GB。3.4 systemd 服务异常与 journalctl 日志定位22.04 全面使用 systemd很多“服务起不来”的问题其实看日志比猜配置快得多。比如服务一直失败先看整体状态systemctl status 服务名 --no-pager -l但更有效的是直接看最近日志sudo journalctl -u 服务名 --since 10 minutes ago --no-pager想确认是不是配置文件写错了就sudo systemd-analyze verify /etc/systemd/system/xxx.service sudo systemd-analyze blamesystemd-analyze blame可以显示开机时每个单元的耗时启动慢的问题用它定位非常直观。如果某项服务和硬件相关比如网络、蓝牙总在启动时超时多半是 systemd 等待设备超时导致的可以在 grub 里追加systemd.device_wait_timeout20之类的参数缩短等待。4. 离线环境安装 ClamAV关于“clarmav”这件事4.1 “clarmav”到底是什么很多离线部署文档会把“ClamAV”写成“clarmav”其实指的都是同一个开源杀毒引擎。之所以叫法混乱一方面是因为拼音输入法误触另一方面是有些教程作者从 RPM 系转过来对名字不敏感。总之你看到 clarmav 时按 ClamAV 处理就行在 Ubuntu 22.04 环境下它的包名是clamav和clamav-daemon。ClamAV 的用途很实在主流的 CentOS/Ubuntu 服务器会用它对上传目录、邮件附件做扫描。很多内网机器没外网又必须按合规要求安装杀毒软件这就轮到了“离线安装 ClamAV”场景。4.2 在有网机器上准备离线包离线安装的核心思路很简单在另一台相同版本、相同架构、同样装有 Ubuntu 22.04 的机器上下载所有依赖包然后打包拷过去安装。注意“相同架构”这几个字x86_64 的包不能装在 arm64 上。在有网机器上执行sudo apt update apt-cache depends clamav-daemon # 先看依赖树 sudo apt-get install --download-only -y clamav clamav-daemon clamav-freshclam默认情况下 apt 会把下载的 .deb 放在/var/cache/apt/archives/。但这个目录可能不全因为有些依赖之前已经装过。为了稳妥我一般会在干净的容器里重新下载依赖cd /tmp apt-get download $(apt-cache depends --recurse --no-recommends --no-suggests --no-conflicts --no-breaks clamav-daemon | grep -E ^[a-zA-Z0-9.-]$)执行完之后把/tmp下所有 .deb 打包tar czf clamav-offline-ubuntu22.tar.gz *.deb然后把这个 tar 包拷贝到内网目标机器。4.3 内网机器安装与病毒库更新内网机器上解压后直接安装tar xzf clamav-offline-ubuntu22.tar.gz sudo dpkg -i *.deb如果报依赖错误先别慌用下面命令再补一下sudo apt --fix-broken install离线环境下的坑在病毒库。ClamAV 如果没有病毒库基本等于空壳而 freshclam 需要联网下载。我的做法是在有网机器上先手动更新病毒库然后拷贝库文件过去sudo freshclam ls /var/lib/clamav/得到daily.cvd、main.cvd、bytecode.cvd后拷贝到内网机器的相同目录sudo cp main.cvd daily.cvd bytecode.cvd /var/lib/clamav/ sudo chown clamav:clamav /var/lib/clamav/*.cvd之后重启服务sudo systemctl restart clamav-daemon clamav-freshclam内网机器建议把 freshclam 的自动更新关掉或者改成本地镜像地址否则它每次启动都会尝试联网然后超时徒增日志噪声。离线安装这类工具我最大的体会是不要试图在目标机器上解决所有依赖把“有网环境准备包”这一步做干净后面安装基本是水到渠成。5. OP-TEE 开发环境 shell 配置问题处理5.1 OP-TEE 环境里出现“shell”字样时在讲什么OP-TEEOpen Portable Trusted Execution Environment是 Arm TrustZone 技术下的开源安全世界实现一般跑在安全侧Secure World。做 OP-TEE 开发时“shell”有两种完全不同的含义很多新手就在这上面混淆第一种是编译构建环境里的 shell也就是你执行make、repo sync、运行build/common.mk时所在的 Linux 终端。这里的“OP-TEE shell”问题多半指编译环境变量、工具链路径、终端卡住不退出等。第二种是运行时进入的安全终端也就是通过 UART 串口或者xtest测试套件打开的 OP-TEE OS 内部控制台。这里如果别人让你“进 OP-TEE shell”通常指的是先进入 U-Boot再启动 OP-TEE最后在 secure world 终端里敲命令。在 Ubuntu 22.04 上我遇到最多的是第一种环境配置问题。因为 OP-TEE 编译依赖的 Python 版本、工具链路径和 Ubuntu 22.04 默认环境经常会打架。5.2 安装依赖顺序与工具链选择OP-TEE 官方文档推荐的编译环境在 22.04 上需要提前装一批包我整理一下sudo apt install -y git android-tools-adb bc bison build-essential ccache curl \ flex g-multilib gcc-multilib git gnupg gperf imagemagick lib32ncurses-dev \ lib32readline-dev lib32z1-dev libc6-dev-i386 libcap-dev libcrypto-dev \ libncurses5-dev libssl-dev python3-pip repo shellcheck u-boot-tools \ xz-utils zip zlib1g-dev有两点要注意第一22.04 默认 Python 是 3.10OP-TEE 里一些老脚本用print语句的会有兼容问题建议把python-is-python3装上避免“找不到 python 命令”的尴尬第二如果编译时提到找不到libncurses.so.5说明你缺 32 位兼容库Ubuntu 22.04 里需要单独处理具体看报错来装。5.3 编译时最典型的两个报错我常在 Ubuntu 22.04 遇到的 OP-TEE 编译报错有两个。第一个是aarch64-linux-gnu-gcc: command not found。这个好解决装交叉编译工具链sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu第二个是/usr/bin/env: python: No such file or directory。Ubuntu 22.04 默认只带python3不带python。官方快速开始里很多脚本写死了#!/usr/bin/env python所以要么建软链接要么装python-is-python3sudo apt install python-is-python3还有一部分人会在repo sync阶段内存占用过大导致 OOM。这个和 Ubuntu 22.04 的默认内存分配策略有关如果机器只有 8 GB 内存建议关掉一些无关进程或者用--depth1浅克隆减少仓库体积。5.4 进入 OP-TEE shell 后的常见现象如果开发板已经启动通过串口进入 OP-TEE 终端最常见的问题是输入没反应或回显乱码。先检查串口工具里波特率是不是设对了绝大多数开发板默认 115200 8N1但也有些板子用 921600这个必须查硬件手册。另外一个经验OP-TEE 终端和 Linux 终端混在一起输出时不要急着敲命令先按几次回车确定当前提示符是#还是/ #。不同的提示符对应的 shell 环境不同误操作反而会让板子看起来像“卡死”。一旦出现“刷屏”的情况按CtrlAK可以杀掉当前串口会话具体取决于你用的终端工具然后重新连接。如果 OP-TEE 内部测试套件xtest跑不过或崩溃在 Ubuntu 22.04 上先核对内核配置确认CONFIG_TEEy和CONFIG_OPTEEy都打开了不然驱动层直接就报错。和桌面发行版不同编译内核时这两个选项经常因为“依赖没选”而被跳过检查配置时建议直接搜索.config文件。6. 日常维护避坑细节与心得6.1 防火墙、Docker 和网络的小坑Ubuntu 22.04 的 UFW 默认规则对 Docker 很不友好。Docker 安装时会直接操作 iptables而 UFW 管理的是另一套规则两者经常导致主机上的端口映射失效。典型表现容器起来了、端口监听了但外部就是访问不到。遇到这种情况先看 Docker 的映射端口有没有监听sudo ss -tlnp | grep 容器端口如果监听正常再看 UFW 状态sudo ufw status verbose我的处理方案是不把 UFW 的 Docker 相关网段一一放开而是直接在/etc/docker/daemon.json里设置iptables: true让 Docker 自己管理端口映射同时 UFW 只限制主机本身的入站流量。如果你非要在 UFW 里配合 Docker最省事的办法是把 Docker 网段加入允许列表sudo ufw allow from 172.16.0.0/12这只是临时方案生产环境还是要搞清楚流量路径否则出了问题一堆规则互相干扰。6.2 内核更新后第三方模块失效Ubuntu 22.04 每次升级内核第三方内核模块NVIDIA 驱动、VirtualBox、某些网卡驱动经常会失效。这不是玄学是新内核的 module 版本校验变了。排查命令dkms status凡是显示installed但实际加载失败的重装对应驱动即可。不要直接删旧内核至少保留一个可用的旧内核因为新内核在某些老旧服务器上可能一个initramfs的坑就让你直接进不去系统。如果要手动清理旧内核先看当前用的哪个uname -r dpkg --list | grep linux-image然后删除与自己当前内核版本不同的旧内核即可。切勿用通配符*全删这是我身边真实发生过的惨案。6.3 导出和备份配置的习惯Ubuntu 22.04 和所有 Linux 发行版一样最重要的不是系统本身而是配置。我强烈建议装完环境后就做一次配置备份不用很复杂一个命令就行tar czf ubuntu2204-config-backup.tar.gz /etc/netplan /etc/ssh /etc/systemd/system /etc/docker 2/dev/null || true这个压缩包放在非系统盘重装后恢复配置时能省大量时间。像/etc/netplan里的网络配置改错了可能 ssh 连不上、机器直接失联这时候手头有备份会从容很多。后备察修改网卡配置前永远准备一个定时恢复任务。Ubuntu 22.04 的 netplan 配置在 apply 之后会立即生效如果远程连不上最稳妥的办法是用timeout 30包一层sudo timeout 30 netplan apply这样即使把网络改坏了重启或者超时后配置会回滚不至于把自己锁在机器外面。这个技巧来自我一次深夜改 IP 改到失联的血泪教训。6.4 日志与监控的日常习惯最后说一个容易被忽略的点Ubuntu 22.04 默认的日志轮转正常情况下够用但你一跑起来的大型服务多了之后/var/log/syslog和journal都会快速膨胀。建议给系统装一个最基本的监控脚本定时检查磁盘、内存和服务状态#!/bin/bash # 放到 /usr/local/bin/syscheck.sh df -h | grep -E ^/dev|overlay free -h systemctl --failed --no-pager journalctl --disk-usagecron 里每 10 分钟跑一次并把输出追加到/var/log/syscheck.log有异常时输出重定向会帮你保留现场。这个习惯在服务器上比装任何监控系统都直接排查问题时能快速看到故障前系统发生了什么。我个人在实际操作中的体会是Ubuntu 22.04 的大多数问题都不是系统本身的 bug而是环境差异和管理习惯造成的。日常使用中把备份、日志、版本选择这三件事做好很多“疑难杂症”根本不会出现。上面这些内容是我在真实服务器和开发板上都验证过的做法你照着处理的时候如果遇到细节上的区别多对比一下版本号往往就能找到答案。后续如果要继续深挖可以再往“内核裁剪”“Ubuntu 22.04 容器化部署”这两个方向扩展那些是更接近生产系统的内容。