Ubuntu 内网离线安装 deb 依赖包：三种下载与本地源方案

机房断网的活我接过几次，印象最深的一回是带着 U 盘去内网装 nginx，几个 deb 拷进去dpkg -i，装到一半提示缺 libpcre3，回来补上再装，又缺 zlib1g，前后跑了三趟才把服务起起来。后来我就固定了一套打法：在能联网的机器上，把 Ubuntu 软件包连同它递归展开的整棵依赖树一次性抓到本地，打成压缩包带走。这篇就按我实际操作的习惯，把"本地下载 + 递归拉依赖"的三种方案、目标机安装的收尾动作，以及我反复踩过的几个坑讲清楚。如果你碰到过"无法定位软件包""没有可用软件包 nginx"之类的提示，或者要给 CentOS 那边做离线依赖包，下面这些内容基本可以直接抄。

1. 什么场景下才值得折腾离线依赖包

1.1 内网隔离的机器，apt 连不上任何源

最典型的就是生产区和办公网物理隔离。这类机器上跑apt-get update会直接卡在连接超时，apt-get install自然也没戏。这时候你手里能用的只剩下 U 盘、跳板机上的一次文件中转，或者统一的内网文件分发目录。把依赖在图省事，但一旦漏了某个间接依赖，中间人来回跑的成本极高，所以我一般都要求一次抓全，宁可多抓几个包也不要少抓。

判断标准很简单：只要目标机器上apt-get update跑不通，或者你无法确认它一定能访问和下载机完全相同的源，就应该走离线依赖包这条路。哪怕目标机器其实能联网，只要网络不稳定、带宽紧张，先把包下好再装也比边下边装可控得多。

1.2 最小化安装的系统，基础库缺得比你想的多

服务器上经常装的是--no-install-recommends的最小化 Ubuntu，这种系统里连curl、vim都可能是后补的。我之前在一台 Ubuntu 22.04 minimal 上装ros-noetic-desktop-full，光是依赖列表就打印了好几屏，apt-cache depends --recurse跑出来八百多个包名。这种量级如果靠人工一个个数缺什么，基本不可能，必须用工具递归展开。

还有一类更容易被忽略的情况：容器里的基础镜像。ubuntu:22.04官方镜像不到 30MB，里面缺的东西非常多，你在宿主机上跑得好好的脚本，扔进容器里第一行就报错。给自己的镜像预先装一套离线包，比每次构建时联网拉要省事得多。

1.3 版本回滚、灰度对比，需要把包固定下来

线上出问题回滚的时候，最忌讳的就是"重新装一遍最新的"。源里的版本随时会更新，今天装的libssl和上周装的就不是同一个版本号，回滚反而引入新变量。把当时那一套 deb 原样存下来，回滚时直接按同样的包集合铺回去，行为才是可复现的。

顺带说一句，这也是为什么我不太推荐在关键环境里用apt-get upgrade一把梭。批量升级在测试机上没问题，生产机上更稳的做法是先把目标版本的包下载到本地目录，验证过再逐个推进。

2. 先把 apt、dpkg 和依赖树的关系捋直

2.1 apt 的"下载"和"安装"本来就是两个阶段

很多人以为apt-get install是一个原子操作，其实它内部至少分三步：解析依赖关系生成安装计划、把缺失的 deb 下载到/var/cache/apt/archives/、调用 dpkg 依次解包配置。离线下载的所有技巧，本质上都是把中间那步单独拿出来做，并且控制下载目标和下载位置。

理解这一点之后，--download-only、--print-uris这些参数就不再是"玄学选项"了。前者是"只做第二步，不做第三步"，后者是"第二步都不做，只把要下载的地址清单告诉我"。搞清楚这一点，后面选方案就不会纠结。

2.2 Depends、Recommends、Suggests 三种关系要分开对待

这张表是我自己在整理下载清单时的依据。默认情况下 apt 会装 Recommends，所以如果你用--download-only抓包，抓到的其实是"含推荐项"的一整套；如果你在目标机上安装时加了--no-install-recommends，就会出现"下了但不用"的浪费，基本无害。反过来，如果你下载时图省事加了--no-install-recommends，而目标机安装时没加，那就可能缺推荐包，表现为某些功能模块加载不出来。

2.3 虚拟包、元包、Essential 包各有各的脾气

虚拟包（Virtual Package）是最容易卡住脚本的一类。像debconf-2.0、mail-transport-agent这种名字，在源里根本找不到同名的 deb 文件，apt-get download debconf-2.0会直接报错退出。工具输出里它们通常被尖括号包起来，写脚本时必须过滤掉。

元包（Metapackage）则是另一回事，它本身是个空壳，只用来拉一堆依赖，比如ros-noetic-desktop-full、build-essential。这类包自己那个 deb 文件很小，价值全在依赖列表里，所以递归展开对它们特别重要。

Essential 包则要小心排除。libc6、dpkg、bash这些包如果被你的脚本重新下载并覆盖安装，搞不好会把系统装坏。我的做法是在目标机上安装时，如果某个包已经在系统里且版本不低于待安装版本，就跳过它。

3. 方案一：--download-only配合独立缓存目录

3.1 命令怎么写、每个参数在干什么

这是最省事的一种办法，前提是下载机和目标机是同版本、同架构的 Ubuntu。核心命令就一行：

sudo apt-get update sudo apt-get -o Dir::Cache::archives="/opt/offline-debs/" \ install --download-only --reinstall -y nginx

拆开看，-o Dir::Cache::archives=是把 deb 的落盘位置从默认的/var/cache/apt/archives/换到我指定的目录，这样不会污染系统缓存，也不会和之前下载的东西混在一起。--download-only让 apt 只下载不安装。--reinstall是我自己加的习惯，因为如果某个包你已经装过了，不加这个参数 apt 会认为"已满足需求"从而跳过下载，导致清单不全。

最后那个目录路径建议带上结尾斜杠，并且提前用mkdir -p建好。我遇到过没建目录时 apt 直接报权限或路径错误的情况。

3.2 下载完之后目录里到底有什么

跑完之后ls /opt/offline-debs/会看到一堆.deb，名字格式是包名_版本_架构.deb。同时/var/cache/apt/archives/里会多出几个*.lock和partial/目录，那些是 apt 的工作文件，不用管，也不要拷给目标机。

有一个容易忽略的点：apt 只会下载"当前安装计划中需要下载的包"，也就是说已经装在下载机上的包不会出现在结果里。所以如果你想拿到一份完整清单，最好在一台干净的、和源版本一致的同版本系统上下载，或者在容器里干这件事。用 Docker 是最方便的：

docker run --rm -v "$PWD/debs:/out" ubuntu:22.04 bash -c \ "apt-get update && apt-get -o Dir::Cache::archives=/out \ install --download-only --reinstall -y nginx"

这样跑出来的包集合，和一台全新 Ubuntu 22.04 需要的包集合基本一致。

3.3 这套方案什么时候会翻车

它最大的边界就是"必须同版本同架构"。你在 Ubuntu 22.04 上下载的libc6 2.35，拿到 Ubuntu 20.04 上装，dpkg 会直接报依赖不满足，因为 20.04 的 libc6 是 2.31 那一代，而系统里的包不能被随意替换。这种错误信息通常长这样：

nginx : 依赖: libc6 (>= 2.34) 但是 2.31-0ubuntu9.9 正要被安装

看到这种版本号明显对不上的提示，别怀疑自己的操作，先确认两台机器的发行版代号。lsb_release -a或者cat /etc/os-release一眼就能看出来。解法只有一个：换一台同版本的机器重新下载，或者在目标机上补一个能用的源。

4. 方案二：--print-uris生成下载清单再批量抓取

4.1 为什么这个方法在跨版本时更靠谱

--print-uris的好处在于它不下载任何东西，只是把"如果要安装这个包，apt 打算去哪里取哪些文件"打印出来。输出里带包名、大小和 SHA256 校验值，信息非常完整。

关键点是：这个清单是在哪台机器上生成的，就天然匹配哪台机器的版本和架构。所以当目标机版本比较特殊（比如某个定制发行版、或者内部源里有一批私有包），正确姿势是把下载机伪装成目标机——用同样的 Docker 镜像、同样的 sources.list，再跑--print-uris。这样生成的 URL 就是在目标机语境下算出来的，版本不会错位。

4.2 从输出里把 URL 干净地抠出来

原始输出每一行大致长这样：

'http://archive.ubuntu.com/ubuntu/pool/main/n/nginx/nginx_1.18.0-0ubuntu1_amd64.deb' nginx_1.18.0-0ubuntu1_amd64.deb 1543178 SHA256:9f1c...

单引号包起来的是 URL，后面依次是文件名、字节数、哈希。我用 awk 按单引号切分取第二段：

apt-get install --print-uris -y --reinstall nginx \ | awk -F"'" '/\.deb/ {print $2}' > urls.txt wc -l urls.txt head -n 5 urls.txt

拿到urls.txt之后就能交给下载工具了。单个文件用wget或者curl -O都行，批量下载我习惯用 wget 的并发能力：

mkdir -p ./debs && cd ./debs xargs -n 1 -P 4 wget -q -c < ../urls.txt

-P 4是四个并发，别开太大，很多公共源对单 IP 连接数有隐性限制，开到 8 以上反而容易被限速甚至临时拒连。-c是断点续传，网络抖一下不用从头再来。

4.3 别浪费输出里的 SHA256，校验真的有用

我早期也懒得校验，直到有一次从公司内网镜像站下载的一个包在网络传输中被截断了，dpkg -i报 "文件意外结束"，排查了半小时才发现是文件不完整。从那以后我就固定把哈希一起存下来：

apt-get install --print-uris -y --reinstall nginx \ | sed -n "s/^'\(.*\)' \([^ ]*\) \([0-9]*\) SHA256:\([0-9a-f]*\)$/\4 \2/p" \ > sha256sums.txt cd ./debs && sha256sum -c ../sha256sums.txt

输出里全是OK就说明这一批包都是完整的。如果出现FAILED，直接删掉重新下，别抱着"可能还能装"的侥幸心理。这批文件最终是要在没法联网校验的机器上用的，源头不干净后面全是坑。

5. 方案三：递归展开依赖树后再逐个下载

5.1 两种展开工具的差别

真正意义上"递归下载所有依赖"，靠的是依赖树展开工具。常用的有两个：apt-cache depends --recurse和apt-rdepends。

apt-cache depends --recurse是 apt 自带的，不用额外安装。它能一次性把所有层级的依赖列出来，配合--no-recommends、--no-suggests这类开关可以精确控制范围。输出里缩进的Depends:行是依赖关系描述，顶格不缩进的行才是包名，所以过滤时要抓"行首是字母或数字"的行。

apt-rdepends需要apt install apt-rdepends装一下，它的输出更详细，但会把虚拟包名原样打出来，还可能出现同名不同版本的重复项，需要额外过滤。我在只需要普通依赖的时候首选前者，需要看"谁依赖谁"的反向关系时才用后者。

5.2 一份我实际在用的下载脚本

下面这段是我反复改过几轮之后的版本，逻辑是：展开依赖树、过滤出真实包名、逐个下载、失败的记录下来而不是直接中断。

#!/bin/bash # 用法: ./grab-deps.sh 目标包名 输出目录 set -u PKG="${1:?请指定包名}" OUT="${2:-./offline-debs}" mkdir -p "$OUT" cd "$OUT" || exit 1 export LC_ALL=C apt-cache depends --recurse \ --no-recommends --no-suggests \ --no-conflicts --no-breaks --no-replaces --no-enhances \ "$PKG" 2>/dev/null \ | grep -E '^[a-zA-Z0-9]' \ | sort -u > pkglist.txt echo "共发现 $(wc -l < pkglist.txt) 个候选包" : > failed.txt while read -r p; do if ! apt-get download "$p" 2>/dev/null; then echo "$p" >> failed.txt fi done < pkglist.txt echo "下载完成，失败 $(wc -l < failed.txt) 个" cat failed.txt

几个细节值得解释。export LC_ALL=C是为了让apt-cache的输出语言固定成英文，否则不同机器上的 locale 设置会让"依赖"这两个字的翻译不一样，过滤规则就得跟着改，很不省心。grep -E '^[a-zA-Z0-9]'这一步同时干掉了缩进的依赖描述行和尖括号包裹的虚拟包行，一举两得。用while read而不是xargs，是因为apt-get download依赖 apt 自己的锁和状态，并发跑容易出问题。

apt-get download不需要 sudo，文件会落在当前目录，这也是我把它cd到输出目录的原因。

5.3 虚拟包和版本约束导致失败怎么办

脚本跑完failed.txt里有内容很正常，常见两类：

一类是虚拟包，比如某个包Depends: <default-mta>，展开后跑出个default-mta，源里没有同名 deb。这类直接忽略就行，因为实际提供这个能力的包（postfix、exim4之一）通常在别的分支已经覆盖到了。

另一类是版本约束丢失带来的问题。apt-cache depends --recurse只给包名不给版本号，apt-get download会去拿源里的"候选版本"，也就是最新的那个。如果目标机需要的是某个更旧的版本，就会装不上。补救办法是回到源里查可用版本：

apt-cache madison libssl1.1 apt-get download libssl1.1=1.1.1f-1ubuntu2.19

apt-cache madison会把源里所有可用版本列出来，用包名=版本号的写法就能锁定具体版本下载。这一步在需要精确复现环境的场景里几乎是必须的。

对于像ros-noetic-desktop-full这种巨型元包，展开出来的列表可能有七八百行，下载耗时也长。我的经验是先跑一遍看数量，如果超过五百个，就分两批下载，中间检查一次failed.txt，避免跑到一半网络断了前功尽弃。

6. 目标机上怎么把这一堆 deb 装进去

6.1dpkg -i一次投喂全部文件的实际行为

把 deb 全部拷到目标机后，最直接的做法是：

sudo dpkg -i ./*.deb

这个命令能不能一次成功，取决于你提供的顺序。dpkg 是按命令行列出的顺序依次处理的，如果被依赖的包排在被依赖者后面，第一次一定会报"依赖关系不满足"。但 dpkg 不会回滚，已经装好的部分保留着，所以通常的做法是再执行一遍：

sudo dpkg -i ./*.deb || sudo dpkg -i ./*.deb

第二遍的时候，前面装好的包已经被登记进数据库了，剩下的包就能顺利配置。这个方法看着粗暴，但在包集合完整的前提下成功率相当高。我一般最多跑三遍，三遍还不过就说明包确实缺东西，得回去查failed.txt。

6.2apt-get -f install到底在修什么

dpkg -i报错之后，系统里会残留一批"已解包未配置"的包，apt数据库状态是 broken。这时候：

sudo apt-get -f install

它会扫描当前的破损状态，算出补齐方案。注意这里有个陷阱：如果目标机完全没有可用源，-f install会尝试联网，最后报无法下载。所以这个命令只在两种情况下有用——要么目标机有本地源（下一节讲），要么缺的包你刚好已经放在/var/cache/apt/archives/里了。把 deb 先拷到这个缓存目录，再跑-f install，效果往往比反复dpkg -i好。

6.3 搭一个 file:// 本地源，把安装还原成 apt 安装

这是我最推荐的收尾方式，一次搭好多台机器都能用，而且不用再折腾顺序问题。

先把dpkg-dev装上（它提供dpkg-scanpackages），然后把所有 deb 放在一个目录里，生成索引：

sudo apt-get install -y dpkg-dev cd /opt/offline-debs dpkg-scanpackages --multiversion . /dev/null | gzip -9c | sudo tee Packages.gz > /dev/null

--multiversion是允许同名包的不同版本共存于索引里，回滚场景下很有用。第二个参数/dev/null是覆盖文件（override file）的位置，一般不需要就直接给空设备。

然后加一条源：

echo "deb [trusted=yes] file:/opt/offline-debs ./" \ | sudo tee /etc/apt/sources.list.d/offline.list sudo apt-get update

[trusted=yes]是关键，本地目录没有 GPG 签名，不加这个 apt 会因为"仓库未签名"而拒绝使用。更新完之后，apt-get install nginx就又能用了，依赖关系由 apt 自己算，冲突检测、配置顺序全都交给它，人只需要保证包在目录里齐全即可。

有个细节要注意：file:后面的路径必须是绝对路径，最后的./表示这是一个扁平结构的仓库（所有 deb 平铺在一个目录，没有dists/层级）。少写或者写错这个./，apt-get update会报"无法找到 Release 文件"。

7. 几个我实际踩过的坑

7.1 下载机和目标机的源版本对不上

这个坑上面前面提过，但还有一种隐藏形态：两台机器发行版版本一样，但sources.list里配的源不一样。比如下载机用的是国内某镜像站的 Ubuntu 22.04 归档，目标机的源被同事改成了某个私有仓库的 22.04 分支。两边的libssl3小版本号差了一个补丁号，装的时候照样报依赖不满足。

排查手段就是比对两边的候选版本：

apt-cache policy libssl3 | head -n 4

在下载机和目标机上各跑一次，看 "Candidate" 那一行是否一致。不一致就以目标机的为准，回下载机锁版本重下。

7.2 架构不一致，白忙一场

另一回更冤：目标机是 ARM64 服务器，我在 x86 笔记本上兴冲冲下载了两百多个包，拷过去一个都装不上，dpkg 报 "package architecture (amd64) does not match system (arm64)"。

下载前先确认架构，只要一条命令：

dpkg --print-architecture

两台机器输出必须一致。想在一台机器上同时下载两种架构是可行的（dpkg --add-architecture加上对应的 ports 源），但配置麻烦、包也不一定齐。我现在的做法是强烈建议用同架构的机器下载，实在没有就用 QEMU 或者支持多架构构建的容器环境起一个 arm64 的 Ubuntu，里面跑下载脚本。多花十分钟起环境，比来回折腾包省事得多。

7.3 post-installation 脚本报错，跟依赖没关系

错误信息长这样：

已安装 xxx 软件包 post-installation 脚本 子进程返回错误状态 1

新手看到这个第一反应是"是不是依赖没下全"，其实不是。这个错误发生在包已经解包完成、正在执行postinst脚本的阶段，常见原因有三个：

第一个是脚本要启动服务，而环境里没有对应的服务管理器。容器里最常见，因为容器里通常没有完整的 init 系统。解决办法是装一个策略脚本阻止服务自动启动：

printf '#!/bin/sh\nexit 101\n' | sudo tee /usr/sbin/policy-rc.d sudo chmod +x /usr/sbin/policy-rc.d

exit 101这个约定的返回值告诉 dpkg "服务启动被策略拒绝了"，dpkg 会认为这是预期行为，不再报错。装完之后记得删掉这个文件，否则后续服务真的需要启动时也会被拦住。

第二个原因是脚本要创建用户或组，而当前环境缺少adduser之类的工具。第三个是脚本要修改的配置文件已经存在且被本地改过，合并冲突。这两个原因都会在postinst的输出里留下线索，仔细看dpkg -i打印的日志，通常能直接定位到具体行。

7.4 "无法定位软件包"的几种真实成因

这个提示被搜得特别多，我自己遇到过的情况归纳下来主要是这几类：

• 没有执行apt-get update，本地索引是空的或者过期的。

• 包在universe或multiverse组件里，而源只启用了main。Ubuntu 上装ros-noetic-desktop-full报这个错，多半是 ROS 的源没加。

• 包名拼错，尤其是带数字和连字符的包名，比如把libpcre3-dev写成libpcre3dev。

• 目标包只存在于更新的发行版里，当前版本确实没有。

• CentOS/RHEL 上提示"没有可用软件包 nginx"，一般是 EPEL 源没启用。

排查顺序我固定成这样：先apt-get update，再apt-cache search 关键字，然后apt-cache policy 包名。最后这条特别有用，它能告诉你这个包在当前源里到底有没有、候选版本是哪个、从哪个源来的。如果 policy 输出里 "Candidate" 是(none)，那就别折腾了，源里确实没有，得先解决源的问题。

8. CentOS 那一套顺手也说几句

8.1yumdownloader --resolve和dnf download --resolve

RHEL 系的离线下载工具链跟 Debian 系思路一样，但命令不同。CentOS 7 上：

sudo yum install -y yum-utils yumdownloader --resolve --destdir=/tmp/rpms nginx

--resolve就是"递归解析依赖"的意思，等价于 apt 那边的apt-cache depends --recurse加下载。CentOS 8 和更新版本已经切到 dnf：

dnf download --resolve --alldeps --destdir=/tmp/rpms nginx

--alldeps会把依赖也带上，不加的话只下你点名的那个包。另外yum install --downloadonly --downloaddir=/tmp/rpms nginx也能用，效果类似，区别是它只下载"当前机器缺的"，已经装过的不会下。做整包搬运的时候我还是更习惯用--resolve。

8.2createrepo_c搭本地源

和 Debian 那边的dpkg-scanpackages对应，RHEL 系用：

sudo yum install -y createrepo_c createrepo_c /tmp/rpms

这会在目录里生成repodata/子目录。然后写一个 repo 文件：

[local-offline] name=Local Offline Repo baseurl=file:///tmp/rpms enabled=1 gpgcheck=0 priority=1

放到/etc/yum.repos.d/local-offline.repo，再yum clean all && yum makecache就能用了。gpgcheck=0是因为本地包没签名，跟 apt 那边的[trusted=yes]是一个道理。priority=1是让这个源优先于在线源，避免本地已经下好的包被在线源里更新的版本顶掉。

顺带提一句，下载阶段和安装阶段的架构问题在 RHEL 系上一模一样，uname -m必须两边一致，aarch64和x86_64的包互不通用。

最后分享一个我自己的小习惯：每次做完离线包，我都会在压缩包根目录写一个README.txt，记清楚下载机器的os-release内容、架构、下载日期，以及生成清单用的原始命令。半年后再有人翻出这个包要用，看一眼就知道能不能直接用，不用再去猜这些 deb 是哪台机器上弄出来的。这个动作花不了三十秒，但省下的沟通成本远不止这些。