拿到一台 Ubuntu 20.04 服务器第一件事是什么绝大多数人都会先跑apt update然后被默认源折磨得没脾气。官方源在国内的连接质量并不稳定依赖安装经常半路超时好不容易把源换好继续安装某个包时又冒出一句No LSB modules are available.。这句话看着吓人实际上就是一个可选模块缺失属于换源之后顺手能修掉的小问题。结合我日常处理 Linux 服务器时的习惯我把 Ubuntu 20.04 修改 apt 源的关键操作整理成可以直接照抄的步骤每条命令都解释清楚为什么这么做再花篇幅讲明白No LSB modules报错到底怎么回事、该装哪个包以及改源之后最容易踩的四个坑。适合刚接触 Linux 的初学者也适合那些想弄清楚“改源”背后原理的运维朋友。1. 一条命令敲下去之前先搞清 sources.list 到底在管什么1.1 默认源的链路与“慢”的本质Ubuntu 的 apt 默认从官方源下载软件包20.04 版本默认写入的是archive.ubuntu.com和security.ubuntu.com两个域名。官方 CDN 在国外的响应速度受国际出口带宽、运营商路由策略、机房地理位置多重影响。很多人遇到的“卡在 1% 不动”“连接超时”“error 101”基本都是这个链路里某个环节引起的。改源的目的不是让系统变得“更高级”而是把软件包下载终点换成国内同步速度更快的镜像地址。镜像站在绝大多数情况下和官方源保持同步路径结构也一致只是服务器放在国内走国内网络更快。所以改源的实质就是替换/etc/apt/sources.list文件里的域名和路径前缀。1.2 sources.list 一行一行拆开看先看一个最典型的 20.04 源写法deb http://archive.ubuntu.com/ubuntu/ focal main restricted universe multiverse这行看起来长其实拆开只有四个部分字段含义常见取值deb表示二进制软件包仓库deb如果写 deb-src 则是源码包仓库URL软件包仓库的实际地址官方或镜像站的 ubuntu 目录发行版代号哪个系统版本使用的仓库focal、focal-updates、focal-security组件仓库里的软件分类main、restricted、universe、multiversefocal是 Ubuntu 20.04 的代号这个不能写错。写成bionic就是 18.04 的仓库系统会直接去下载不匹配的软件包元数据轻则报错重则装坏依赖。focal-updates是持续更新的软件包focal-security是安全补丁focal-backports是向后移植的新版本。组件部分main是官方维护的自由软件restricted是官方维护的非自由软件universe是社区维护的自由软件multiverse是社区维护的非自由软件。20.04 的官方源默认会把这四个组件全部启用但我在很多精简过的教程里见过只写main restricted的写法会导致装一些常用软件时报“无法定位软件包”。后面会专门处理这个问题。1.3 为什么改源之前先备份是最低消费修改任何系统配置文件第一条原则永远是备份。/etc/apt/sources.list这个文件特别容易手滑比如多敲一个空格、LOCATION 写错、把focal打成focal/apt 的行为会变得很不可控。备份不是为了仪式感是为了给自己留一条 10 秒内回到原点的路。备份建议用带时间戳的方式sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak.$(date %F)这样不仅保留了原始内容还能看出是什么时候备份的。恢复老配置只需要把备份文件覆盖回去sudo cp /etc/apt/sources.list.bak.$(date %F) /etc/apt/sources.list很多高手还会额外备份/etc/apt/sources.list.d/目录因为这个目录里的.list文件同样会被 apt 读取。如果你装过某些第三方软件仓库改源时很容易漏掉这个目录导致新旧源混在一起。2. 把源换成国内可用的镜像地址——两种落地方案2.1 方案A用 sed 对官方域名做全局替换如果你希望保留源文件里原有的结构只换域名最稳的方法是sed全局替换。先备份再执行替换sudo sed -i s#archive.ubuntu.com#mirrors.region.example.com#g /etc/apt/sources.list sudo sed -i s#security.ubuntu.com#mirrors.region.example.com#g /etc/apt/sources.list我用#作为分隔符而不是常见的/因为 URL 里本身就带斜杠。如果还用/分隔整个命令会变得像转义地狱读起来非常痛苦。-i表示原地修改g表示替换这一行里所有匹配项不只是第一个。这里你看到的mirrors.region.example.com是关键占位符。实际操作时把它换成你本地网络访问速度最好的镜像地址。挑选标准后面我会说这里先记住路径结构即可。替换完成后用下面命令检查效果grep -E ^(deb|deb-src) /etc/apt/sources.list正常输出里应该看不到任何archive.ubuntu.com或security.ubuntu.com全部变成你的镜像域名。sed的优点是快、可重复执行缺点是如果原始文件里本来就有奇怪的路径或多余组件替换完还是带着问题。2.2 方案B直接重写 sources.list 并补齐四个组件对于希望从头控制源文件内容的人我更喜欢直接重写整个文件。先把旧文件备份然后用编辑器打开sudo vim /etc/apt/sources.list把内容清空后粘贴以下模板deb http://mirrors.region.example.com/ubuntu/ focal main restricted universe multiverse deb http://mirrors.region.example.com/ubuntu/ focal-updates main restricted universe multiverse deb http://mirrors.region.example.com/ubuntu/ focal-backports main restricted universe multiverse deb http://mirrors.region.example.com/ubuntu/ focal-security main restricted universe multiverse # deb-src http://mirrors.region.example.com/ubuntu/ focal main restricted universe multiverse # deb-src http://mirrors.region.example.com/ubuntu/ focal-updates main restricted universe multiverse四行分别对应基础仓库、更新仓库、向后移植仓库、安全更新仓库。focal-security我刻意没有省略因为安全补丁非常重要很多精简教程只顾主仓库导致系统长期收不到安全更新。deb-src行我全部注释掉这是源码包仓库普通使用场景用不到留着反而会让apt update多拉一份源码索引。如果你搞编译开发再取消注释也不迟。这里必须强调一件事mirrors.region.example.com是示意地址不要真的填进去。国内可用镜像一般分两类一类是云厂商提供的开源镜像站一类是高校维护的软件镜像。挑选时我不看名气只看三个硬指标指标原因是否支持 HTTPS明文 HTTP 在传输过程容易被篡改软件包校验虽能发现异常但没必要冒险同步频率越频繁越好否则你会遇到软件包索引里有、但下载时报 404本地可访问速度用curl -I猜一下响应时间或者直接跑一次apt update感受延迟另外注意路径细节。有的镜像站在 URL 后面要求写/ubuntu/有的要求写/ubuntu有的还区分ubuntu和ubuntu-security两个路径。实际使用时最好打开镜像站首页找到“ubuntu 源使用帮助”页面看它给出的 20.04 写法长什么样直接复制比手敲可靠得多。2.3 更新索引并确认改源生效的实证标志无论用哪种方案写完文件之后都必须刷新软件包索引sudo apt updateapt update不是把软件装上而是拉取每个仓库的Packages索引文件。这些索引记录了仓库里有哪些软件包、什么版本、依赖什么后面apt install就是根据这个索引去定位软件包。如果源写错这一步就会直接暴露问题。改源成功、网络通畅的情况下apt update的输出应该是几条Get和Hit交替出现最后以Reading package lists... Done结束无报错。看到下面这些特征基本可以放心Get:1 http://mirrors.region.example.com/ubuntu focal InReleaseGet:2 http://mirrors.region.example.com/ubuntu focal-updates InReleaseHit表示文件没变化Get表示实际下载了新数据如果出现大段Err或W: ... 404 Not Found先检查文件里的路径末尾有没有该加的斜杠再检查代号是不是focal不要急着重装系统。3. 遇到 “No LSB modules are available” 时到底少了什么3.1 触发场景与报错来源的完整关系很多人在跑service --status-all查看系统服务时输出开头多出一行No LSB modules are available.之后才是一堆服务状态。也有人是在跑lsb_release -a时看到同样的话。产生原因要从 LSB 说起。LSB 是 Linux Standard Base 的缩写目的是让不同发行版之间在初始化脚本、发行版信息、命令行为上保持某种一致性。Ubuntu 的service命令在处理 SysV 初始化脚本时会尝试读取 LSB 信息来判断脚本应该如何启动、停止。如果系统里缺少提供 LSB 运行时支持的软件包service就找不到完整的模块信息于是打印出这么一句提示。最小化安装的 Ubuntu 20.04、Docker 容器里裁剪过的镜像、被人手工删过/etc/lsb-release的系统最容易触发这个报错。它本身不会让系统崩溃但会污染脚本输出还可能让依赖lsb_release命令的第三方安装脚本直接失败。3.2 lsb-release、lsb-base、lsb-core 三兄弟的区别修复之前先把三个看起来很像的包理清楚软件包作用是否解决 No LSB moduleslsb-release提供/usr/bin/lsb_release命令和/etc/lsb-release文件能解决大部分报错lsb-base提供 LSB 初始化脚本基础支持比如/lib/lsb/init-functions有它更完整lsb-core一组 LSB 核心运行时集合包含版本检测等更多内容报错严重时可装其实lsb-release是最常见的缺口。它提供的那条lsb_release命令是很多初始化框架检测系统发行版信息的关键工具。缺了它脚本拿不到 Codename、Release、Description只能提示模块不可用。lsb-base是运行基础它提供/etc/init.d/lsb脚本的支持文件某些 SysV 服务在启动时依赖这些函数。如果一个系统连lsb-base都没有光装lsb-release也可能不够。lsb-core更像是集成包会把 LSB 相关的核心模块一起装好一般用于做到“以后别再报错”的目的。3.3 安装 LSB 模块的完整步骤与验证先用更新后的源刷新索引这一步尤其重要——如果你拿的是刚改完源还没来得及apt update的终端直接安装大概率会失败sudo apt update sudo apt install lsb-release装完后重新执行lsb_release -a输出应该不再是那行单句报错而是完整的发行版信息Distributor ID: Ubuntu Description: Ubuntu 20.04.6 LTS Release: 20.04 Codename: focal如果重新执行service --status-all仍然出现No LSB modules那就再装lsb-base和lsb-core顺序不重要一次装齐更省事sudo apt install lsb-base lsb-core装完再次验证。这一步贵在让完整的 LSB 环境落地而不是只装一个名字看起来像的那个包。这个修复为什么在标题里被标成“可选”因为service命令本身对系统服务的管理并不完全依赖 LSB 模块SysV 脚本的start/stop/status逻辑照样能跑。报错只是少了发行版识别层面的信息不会直接导致系统停机。但对于写脚本自动化运维的人多一行脏输出就多一分误判风险所以我还是建议顺手装掉。4. 改源之后常见的四个报错定位思路一次讲清4.1 NO_PUBKEY公钥过期或未导入时的解决方案改源后跑apt update最常听到的报错是W: GPG error: http://mirrors.region.example.com/ubuntu focal InRelease: The following signatures couldnt be verified because the public key is not available: NO_PUBKEY XXXXXXXXXXXXXXXX出现这个问题的原因有两种一是新换的镜像仓库发行了一套不同的签名密钥而本地没有导入二是系统时间不对导致密钥验证过期。前者更常见。处理思路是找到报错里NO_PUBKEY后面的那串十六进制密钥 ID把公钥手动导入sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys XXXXXXXXXXXXXXXXkeyserver.ubuntu.com是官方公钥服务器导入之后再跑一次sudo apt updateW 警告应该消失。需要提醒一句apt-key在 Ubuntu 20.04 上还能正常用但如果后续升级到新版本建议改用/etc/apt/keyrings/目录管理密钥这是后话。4.2 404 Not Found抱错 focal 与 focal-security 的最小复现另一个高频问题是Err:5 http://mirrors.region.example.com/ubuntu focal-security/main amd64 Packages 404 Not Found [IP: 127.0.0.1]404 说明这个 URL 在镜像服务器上不存在。常见原因是镜像站没有同步某个仓库或者路径写法不对。比如有的镜像站把安全更新放在单独的/ubuntu-security/路径下和安全源本身是两回事。排查步骤按顺序来检查发行版代号确实是focal不是jammy或bionic打开浏览器直接访问报错的 URL看到目录列表说明路径没问题去镜像站帮助页确认它的 20.04 仓库路径是否跟官方一致如果该镜像没有同步proposed这类特殊仓库就删掉对应行别惦记一个小技巧临时用apt update -o Acquire::http::Timeout5加快报错反馈能快速试出到底哪行源有问题。4.3 组件缺失universe/multiverse 被注释后依赖消失很多时候“无法定位软件包”跟源地址没关系纯粹是组件写少了。比如你想装htop它属于universe组件但你的sources.list只留了main restrictedapt 就会告诉你找不到。解决方式很直接把四行源的组件部分统一补成main restricted universe multiverse再更新索引。不需要一个个追查软件包属于哪个组件四个组件全开基本能覆盖绝大多数软件需求。universe覆盖海量社区软件multiverse包含一些非自由软件和特殊授权包。从安全角度讲组件并不是开得越多越危险apt 的软件包签名和安装确认机制依然有效只是搜索范围变大而已。担心软件来源的话重点看你到底从哪个仓库拉包而不是担心组件数量。4.4 改坏了也没关系一条命令回滚到官方源手滑把源写坏最忌讳的是慌着删文件。只要备份还在一条命令就能回到官方默认状态sudo cp /etc/apt/sources.list.bak.$(date %F) /etc/apt/sources.list如果你完全没备份但还记得官方源的格式也可以直接写回上面第一步里的官方写法。回滚之后立刻执行sudo apt update确认系统恢复正常再重新走一遍改源流程速度反而最快。一个额外的排查方向是/etc/apt/sources.list.d/目录。有时候你改了主文件但 apt 仍然去连接旧地址多半是目录下某个.list或.sources文件在捣乱。处理办法是把可疑文件临时移走sudo mv /etc/apt/sources.list.d/custom.list /etc/apt/sources.list.d/custom.list.disabled移动后再跑apt update如果报错消失那就是这个文件的问题。这个目录容易被忽略但实际排障时比想象中更常遇到。5. 一点超出标题的经验容器与多版本场景下的源管理5.1 用 codename 变量写出一套可复制的源模板20.04 用focal22.04 用jammy如果每换一台机器就去查一遍代号效率实在太低。我自己的习惯是直接复用系统变量source /etc/os-release echo 当前版本代号: ${UBUNTU_CODENAME:-$VERSION_CODENAME}拿到代号后写源模板时可以把它硬编码进去也可以写成带变量的形式。带变量的版本适合拿来写自动化脚本举例CODENAME$(. /etc/os-release echo ${UBUNTU_CODENAME:-$VERSION_CODENAME}) sudo sed -i s/focal/${CODENAME}/g /etc/apt/sources.list这个思路本质是把“系统版本”和“源写法”解耦。无论当前是 20.04 还是 22.04脚本都能生成匹配的源不会因为手动填错代号而翻车。5.2 升级到新版本后源失效的复盘很多人在do-release-upgrade升级系统版本以后会遇到源全部 404 的情况。原因很简单升级过程会把/etc/apt/sources.list里的版本代号整体替换成新系统代号但国内镜像不一定立刻同步新版本的仓库目录。这时候不要急着把源改回老版本否则升级后的软件包管理会非常混乱。我的建议是先临时使用官方源跑一次apt update确认新系统基本可更新等待镜像站公告完成新版本同步再把源切回镜像站如果升级前能主动把镜像源恢复成官方源升级过程其实更顺升级完成后再切换回来这是目前我验证过最稳的顺序。5.3 源管理这件事的日常维护习惯改源不是一次性的活儿它需要偶尔维护。我给自己定了几条规矩每次改源后至少跑一次apt update确认没有 W 或 Err新装第三方软件仓库前先看.list文件里是否夹杂旧源定期检查系统里有没有失效的源用apt update的输出当警报器重要机器保留一个带日期的源备份而不是让备份文件被下一次备份覆盖容器场景更特殊。Docker 镜像里如果裁剪过 apt 列表apt update后可能连基础工具都装不全。这种时候我习惯先补ca-certificates和gnupg再把源模板改掉否则后面拉密钥、验证书都会出问题。lsb-release在这个环境里尤其容易被忽略但它对很多安装脚本的判断逻辑又很重要所以标题里那句“可选安装”其实是有经验判断在里面的。改源这件事情真正考验人的不是会不会敲命令而是遇到报错时能不能快速定位到文件结构、组件、密钥、路径这几个核心变量上。我处理过不少“源有问题”的工单最后大多数都落在 404 和公钥这两个点上。把上面这些检查流程走一遍八成问题都能自己解决。