Ubuntu下apt-get update报错？手把手教你修复‘Skipping acquire’问题（附amd64架构配置）
最近在给一台新装的Ubuntu服务器配置开发环境，准备安装OpenCV来跑一些视觉算法。像往常一样，我习惯性地先执行sudo apt-get update刷新软件源列表，结果终端里刷出了一堆刺眼的警告：“Skipping acquire of configured file... doesn‘t support architecture ‘i386’”。这场景对很多从Windows或macOS转过来的开发者来说，可能有点懵——明明系统是64位的，怎么老在提一个听起来很古老的“i386”架构？如果你也遇到了类似的困扰，别急着重装系统。这篇文章，我就结合自己踩坑和解决的经验，带你彻底搞懂这个错误的来龙去脉，并手把手教你如何精准修复，特别是针对目前主流的amd64架构环境。无论你是刚接触Linux的初学者，还是有一定经验的中级用户，都能从这里找到清晰、可操作的答案。
1. 理解“Skipping acquire”错误的根源：架构冲突
当你在终端里看到Skipping acquire这个提示时，apt这个包管理器其实是在很“礼貌”地告诉你：它尝试去某个软件仓库获取适用于特定系统架构的软件包列表，但那个仓库明确表示“我不支持你这个架构”，所以只能跳过。这本身不是一个会阻止所有更新的致命错误，但它意味着你无法从那个特定的仓库安装或更新任何软件，对于依赖该仓库的软件（比如某些特定版本的OpenCV、ROS或专业工具）来说，这就是个问题了。
问题的核心通常出在系统架构与软件仓库声明的支持架构不匹配。现代个人电脑和服务器最常见的架构是amd64（也称为 x86_64），这是一个64位的架构。而错误信息中频繁出现的i386，则是经典的32位x86架构。为什么64位系统会去请求32位的包呢？这背后有几个常见原因：
- 历史兼容性： 一些软件或驱动为了兼容旧的32位应用程序，会在64位系统中启用多架构（multiarch）支持，从而也会尝试获取i386的软件包信息。
- 仓库配置疏忽： 很多第三方软件仓库（PPA）或商业软件源，在提供安装说明时，给出的
sources.list配置行可能没有明确指定架构。当你的系统启用了多架构支持，apt就会默认尝试获取所有已启用架构的包，如果仓库本身只提供amd64的包，对i386的请求自然会被拒绝。 - 配置文件残留： 系统升级后，一些旧版本的仓库配置文件可能残留，里面包含了不再支持的架构信息。
要查看你的系统当前启用了哪些架构，可以运行：
dpkg --print-foreign-architectures如果输出中包含i386，说明你的系统确实配置了安装32位软件的能力。而查看某个软件仓库具体支持哪些架构，错误信息本身就是一个线索，它指向的InRelease文件里就包含了这些元数据。
注意：
InRelease文件是软件仓库的“索引目录”，它使用GPG签名确保内容安全，里面列出了该仓库为各种架构（如amd64, i386, arm64等）提供的软件包列表（Packages文件）的位置。apt-get update的核心工作就是下载并解析这些InRelease和Packages文件。
2. 诊断与定位：找到出问题的配置文件
面对一屏的错误信息，第一步不是盲目修改，而是精准定位。错误信息本身就是最好的诊断工具。我们仔细看一个典型例子：
Skipping acquire of configured file ‘universe/binary-i386/Packages’ as repository ‘http://miktex.org/download/ubuntu bionic InRelease’ doesn’t support architecture ‘i386’我们可以从中提取出几个关键信息：
- 问题架构：
i386 - 问题仓库地址：
http://miktex.org/download/ubuntu - 系统版本代号：
bionic(对应Ubuntu 18.04) - 出错的配置文件： 虽然没直接说，但仓库地址强烈暗示了配置来源于某个
.list文件，通常位于/etc/apt/sources.list.d/目录下，文件名很可能与仓库名相关（如miktex.list）。
因此，标准的诊断流程如下：
- 审查错误源头： 仔细阅读每一条
Skipping acquire错误，记下涉及的仓库URL（如http://miktex.org/download/ubuntu）和系统版本（如bionic,focal）。 - 定位配置文件： Ubuntu的软件源配置主要在两个地方：
- 系统主配置：
/etc/apt/sources.list - 附加配置目录：
/etc/apt/sources.list.d/（第三方软件源通常将配置文件放在这里） 我们需要去这两个地方寻找包含错误仓库URL的行。
- 系统主配置：
- 进入配置目录查看：
这会列出目录下所有文件。根据错误信息中的仓库名称（如miktex），你通常可以找到对应的cd /etc/apt/sources.list.d/ ls -la.list文件（如miktex.list,ros.list,docker.list等）。
3. 手把手修复：三种精准解决方案
找到问题文件后，我们就可以着手修复了。根据你的具体需求，有以下三种主流解决方案，我推荐按顺序考虑。
3.1 方案一：为仓库行明确指定架构（推荐）
这是最精准、最干净的解决方案。原理是修改仓库配置行，明确告诉apt：“这个仓库我只想获取amd64架构的包，不要尝试i386。” 这能从根本上消除警告。
操作步骤如下：
使用文本编辑器（如
nano,vim或gedit）打开有问题的.list文件。例如，对于miktex.list：sudo nano /etc/apt/sources.list.d/miktex.list你会看到类似这样的内容：
deb http://miktex.org/download/ubuntu bionic main或者可能包含
[arch=amd64]但后面跟着,i386。将其修改为，显式指定
arch=amd64：deb [arch=amd64] http://miktex.org/download/ubuntu bionic maindeb表示这是一个二进制软件仓库。[arch=amd64]是架构限定选项，确保apt只处理该架构。- 后面的URL、发行版代号和组件保持不变。
保存并退出编辑器（在nano中按
Ctrl+X，然后按Y确认，再按Enter）。重新运行更新：
sudo apt-get update此时，针对该仓库的
Skipping acquire错误应该消失了。
哪些情况适合此方案？
- 你确定只需要从该仓库安装64位（amd64）软件。
- 该仓库本身只提供amd64的包（大多数现代第三方仓库如此）。
- 这是处理第三方仓库（如Docker, ROS, PostgreSQL官方源等）最常见、最推荐的方法。
3.2 方案二：禁用系统的i386多架构支持
如果你百分之百确定你的系统不需要运行任何32位（i386）的软件，并且所有Skipping acquire错误都源于系统对i架构的请求，那么可以考虑从系统中移除i386的多架构支持。这是一剂“猛药”，请谨慎使用。
- 首先，移除i386架构：
sudo dpkg --remove-architecture i386 - 接着，你需要清理或修改所有在
/etc/apt/sources.list和/etc/apt/sources.list.d/中显式包含i386的仓库行。例如，将deb [arch=amd64,i386] ...改为deb [arch=amd64] ...。 - 最后更新：
sudo apt-get update
警告： 除非你非常清楚后果，否则不建议新手随意操作。一些老旧但必需的闭源驱动（如某些NVIDIA旧驱动）或专业软件可能依赖32位库。移除后可能导致这些软件无法安装或运行。
3.3 方案三：忽略特定仓库的警告（临时处理）
如果某个仓库的警告无关紧要（例如，你根本不使用该仓库的任何软件），或者你暂时不想修改配置，可以采取“鸵鸟策略”，让apt在更新时忽略特定仓库。这并不解决根本问题，但能让输出更干净。
通过给apt-get update加上-o选项，可以设置临时的配置参数。但更一劳永逸的方法是在/etc/apt/apt.conf.d/目录下创建一个配置文件（例如99ignore-i386）：
echo 'Acquire::Check-Valid-Until "false";' | sudo tee /etc/apt/apt.conf.d/99ignore-release但请注意，上述命令是忽略发布文件过期警告，对于架构错误，更直接的方法是确保仓库配置正确。忽略警告只是一种表面处理。
方案选择对比表
| 方案 | 操作难度 | 影响范围 | 推荐度 | 适用场景 |
|---|---|---|---|---|
| 方案一：指定架构 | 简单 | 单个仓库 | ★★★★★ | 绝大多数第三方仓库配置问题 |
| 方案二：移除架构 | 中等 | 整个系统 | ★★☆☆ | 确认完全不需要32位软件的系统 |
| 方案三：忽略警告 | 简单 | 临时/表面 | ★☆☆☆ | 仅想清洁输出，且不依赖问题仓库 |
4. 深入解析：amd64架构与软件仓库管理
在修复过程中，我们反复提到了amd64。为什么它如此重要？简单来说，amd64是当前Linux桌面和服务器的绝对主流架构标准。它由AMD公司率先提出（因此得名），后来被Intel采纳，成为了64位x86处理器的通用指令集架构。在软件仓库的语境下，amd64就代表为这类64位CPU编译的软件包。
一个管理良好的软件仓库，会在其InRelease文件中明确列出支持的架构。当我们执行apt-get update时，apt会做以下几件事：
- 读取所有
sources.list配置。 - 为每个仓库URL和每个已启用的系统架构，生成对应的
Packages文件下载链接。 - 尝试下载这些链接。如果服务器返回404或明确不支持（就像我们遇到的错误），apt就记录为
Skipping acquire。
因此，良好的仓库配置习惯是预防此类问题的关键：
- 优先使用官方和知名PPA： 它们通常有更规范的配置和文档。
- 添加仓库时，注意安装说明： 许多项目现在提供的安装命令会自动生成带有
[arch=amd64]限制的配置文件。 - 定期清理
/etc/apt/sources.list.d/： 移除不再使用的软件源配置文件。可以使用sudo apt-add-repository --remove或直接手动删除.list文件。 - 理解
apt与apt-get： 在较新的Ubuntu版本中，更推荐使用apt命令（它合并了apt-get和apt-cache的常用功能，输出更友好）。例如sudo apt update。但在脚本中，为了兼容性，apt-get仍是标准。
5. 实战演练：以安装特定软件为例
让我们用一个更贴近开发的例子来串联整个流程。假设我们想在Ubuntu 20.04 (Focal)上安装一个特定版本的OpenCV，它需要通过某个PPA来获取。
添加PPA后首次更新报错：
sudo add-apt-repository ppa:some-opencv/ppa sudo apt update输出中可能出现：
Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'http://ppa.launchpad.net/some-opencv/ppa/ubuntu focal InRelease' doesn't support architecture 'i386'定位问题文件： PPA的配置通常位于
/etc/apt/sources.list.d/下，文件名类似some-opencv-ubuntu-ppa-focal.list。cd /etc/apt/sources.list.d/ ls *opencv* # 或 ls *some-opencv*查看并编辑配置文件：
sudo cat some-opencv-ubuntu-ppa-focal.list可能看到：
deb http://ppa.launchpad.net/some-opencv/ppa/ubuntu focal main编辑它，添加架构限制：sudo nano some-opencv-ubuntu-ppa-focal.list # 修改为 deb [arch=amd64] http://ppa.launchpad.net/some-opencv/ppa/ubuntu focal main验证修复：
sudo apt update错误信息应该消失，并且关于该PPA的更新行会正常显示“命中”或“获取”。
进行安装：
sudo apt install libopencv-dev python3-opencv
这个过程清晰地展示了从遇到问题、分析、定位到解决、验证的完整闭环。掌握之后，你不仅能解决Skipping acquire，对Ubuntu的包管理系统也会有更深的理解。下次再看到类似的警告，你就能胸有成竹地快速处理，而不是被终端里滚动的红字吓到了。
