常见问题解答

常规

什么是 Arch Linux？

请参阅 Arch Linux 文章。

为什么我不应该使用 Arch？

如果您有以下情况，您可能不想使用 Arch：

您没有能力/时间/意愿去使用“自己动手”的 GNU/Linux 发行版。
您需要支持 x86_64 以外的架构。
您坚持使用只提供 GNU 定义的自由软件的发行版。
您认为操作系统应该自行配置，开箱即用，并在安装介质上包含完整的默认软件和桌面环境。
您不想要滚动发布的 GNU/Linux 发行版。
您对当前的操作系统感到满意。

为什么我应该使用 Arch？

因为 Arch 是最好的。

Arch 支持哪些架构？

Arch 仅支持 x86_64（有时称为 amd64）架构。对 i686 的支持已于 2017 年 11 月停止[1]。

非官方端口适用于 i686 架构[2] 和 ARM CPU [3]，每个都有自己的社区频道。

Arch 是否遵循 Linux 基金会的文件系统层次标准（FHS）？

对于使用 systemd 服务管理器的操作系统，Arch Linux 遵循文件系统层次结构。有关每个目录及其指定的说明，请参阅 file-hierarchy(7)。特别是，/bin、/sbin 和 /usr/sbin 是 /usr/bin 的符号链接，/lib 和 /lib64 是 /usr/lib 的符号链接。

我是一个 GNU/Linux 的完全新手。我应该使用 Arch 吗？

如果您是新手并且想使用 Arch，您必须愿意投入时间学习新系统，并接受 Arch 被设计为“自己动手”的发行版；是由用户组装系统。

在寻求帮助之前，请通过搜索网络、论坛和 Arch Wiki 提供的出色文档进行独立研究。这些资源被提供给您是有原因的。 已经花费了数千小时的志愿者时间来编译这些优秀的信息。

另请参阅 Arch 术语表#RTFM 和安装指南。

Arch 的设计是用作服务器？桌面？还是工作站？

Arch 不是为任何特定类型的用途而设计的。相反，它是为特定类型的用户设计的。Arch 的目标是有能力的用户，他们喜欢它的“自己动手”性质，并进一步利用它来塑造系统以适应他们的独特需求。因此，在其目标用户群手中，Arch 可以用于几乎任何目的。许多人在他们的桌面和工作站上都使用 Arch。当然，archlinux.org、aur.archlinux.org 以及几乎所有 Arch 的基础设施都在 Arch 上运行。

我真的很喜欢 Arch，除了开发团队需要实现 X 功能

参与贡献，将您的代码/解决方案贡献给社区。如果它受到社区和开发团队的好评，也许它将被合并。Arch 社区在代码和工具的贡献和共享方面蓬勃发展。

新版本何时发布？

Arch Linux 版本只是一个用于安装或救援的 live 环境，其中包括 base 元软件包和一些其他软件包。版本通常在每个月的上半月发布。

Arch Linux 是一个稳定的发行版吗？我会经常遇到崩溃吗？

用户最终对其滚动发布系统的稳定性负责。用户决定何时升级，并在需要时合并必要的更改。如果用户向社区寻求帮助，通常会及时提供帮助。Arch 与其他发行版在这方面的区别在于，Arch 真正是一个“自己动手”的发行版；抱怨崩溃是误导和徒劳的，因为上游更改不是 Arch 开发人员的责任。

请参阅系统维护文章，了解如何使 Arch Linux 系统尽可能稳定。

Arch 需要更多的媒体报道（即广告宣传）

Arch 已经获得了大量的媒体报道。Arch Linux 的目标不是变得庞大；相反，有机的、可持续的增长自然发生在目标用户群中。

Arch 需要更多的开发者

可能确实如此。欢迎您自愿贡献您的时间！访问论坛、IRC 频道和邮件列表，看看有什么需要做的。另请参阅参与贡献了解详情。

安装

Arch 需要一个安装器。也许是一个图形界面安装器？

带文本用户界面的引导式安装程序是可用的。请参阅 archinstall 了解详情。

我安装了 Arch，现在我进入了 shell！接下来该怎么办？

请参阅通用建议。

我应该使用哪个桌面环境或窗口管理器？

由于您可以使用许多，请使用最适合您需求的一个。请查看桌面环境和窗口管理器文章。

是什么使 Arch 在其他“最小化”发行版中脱颖而出？

请参阅 Arch 与其他发行版的比较。

系统维护

另请参阅系统维护。

为什么我的互联网速度比其他操作系统慢？

您的网络配置是否正确？请查看网络配置文章。对于高级设置，您可能还需要查看流量整形。

最常用的内核之一，linux，往往比其他更稳定的 Linux 发行版的内核更新。因此，您可能很少遇到内核回归或驱动程序错误，尤其是在使用 Wi-Fi 时。请注意，绝大多数这些错误都不是 Arch Linux 特有的，因为 Arch Linux 仅应用最基本的补丁。这需要提交到上游。请参阅 #我发现软件包 X 有错误。我该怎么办？。

为什么 Arch 占用了我所有的 RAM？

本质上，未使用的 RAM 是浪费的 RAM。

许多新用户注意到 Linux 内核处理内存的方式与他们习惯的方式不同。由于从 RAM 访问数据比从存储驱动器快得多，因此内核会将最近访问的数据缓存在内存中。只有当系统开始耗尽可用内存并且需要加载新数据时，缓存的数据才会被清除。

我们可以从 free 命令中区分差异

$ free -h

              total        used        free      shared  buff/cache   available
Mem:          2.8Gi       1.1Gi       283Mi       224Mi       1.4Gi       1.2Gi
Swap:         3.0Gi       881Mi       2.1Gi

重要的是要注意“可用”内存和“可用”内存之间的区别。在上面的示例中，总共有 2.8 GiB RAM 的笔记本电脑似乎正在使用大部分内存，只有 283 MiB 作为可用内存。但是，其中 1.4 GiB 是“buff/cache”。仍然有 1.2 GiB 可用于启动新应用程序，而无需交换。请参阅 free(1) 了解详情。这一切的结果是什么？性能！

如果您的好奇心被激起，请参阅这篇精彩的文章。还有一个专门用于消除这种困惑的网站：https://www.linuxatemyram.com/。

我的所有可用空间都去哪儿了？

这个问题的答案取决于您的系统。有一些优秀的实用工具可能会帮助您找到答案。

为什么我无法登录？

您是否输错了密码或在十五分钟内取消了三次 sudo 命令？如果是这样，您已经触发了针对暴力攻击的预防机制：有关更多详细信息，请参阅安全#在三次登录尝试失败后锁定用户。

Arch 会“电话回家”吗？

简而言之？不会。

更详细地说

NetworkManager 的用户应该知道它会进行自动连接检查：默认连接 URL 由 Arch 提供，并承诺不记录任何访问；
网络时间协议客户端在其默认配置中使用 NTP Pool 项目提供的 NTP 服务器供应商池（根据其规则）；
正如 Pacman/软件包签名#定期升级系统中的注释所解释的那样，systemd 计时器每周运行一次以更新已信任密钥的新签名：那里也没有任何访问日志记录。

您可能希望自愿“电话回家”，通过为 pkgstats 项目贡献力量，该项目收集软件包受欢迎程度的匿名数据，以帮助 Arch 开发人员确定他们的工作重点。

软件包管理

有关更多答案，请参阅 pacman，pacman/技巧和窍门和官方软件仓库页面。

我发现软件包 X 有错误。我该怎么办？

首先，您需要弄清楚这个错误是否是 Arch 团队可以修复的。通常不是（例如，Firefox 崩溃可能是 Mozilla 团队的错误）；这称为上游错误，请参阅错误报告指南#上游还是 Arch？。如果是 Arch 问题，您可以采取一系列步骤

在论坛中搜索信息。看看是否有人注意到它。
在 Gitlab 中的 Arch Linux 错误跟踪器上发布包含详细信息的错误报告。
如果您愿意，可以撰写一篇论坛帖子，详细说明问题以及您已报告该问题的事实。这将有助于防止许多人报告相同的错误。

Arch 软件包需要使用唯一的命名约定。“.pkg.tar.zst”太长和/或令人困惑

这已在 Arch 邮件列表中讨论过。有人提议使用 .pac 文件扩展名，但没有计划更改软件包扩展名。正如 Arch 开发人员之一 Tobias Kieslich 所说，“软件包就是一个[压缩的] tarball！它可以被任何支持 tar 的应用程序打开、调查和操作。此外，mime 类型可以被大多数应用程序自动正确检测到。”

Pacman 需要一个库，以便其他应用程序可以轻松访问软件包信息

Pacman 是 libalpm(3)—即“Arch Linux 软件包管理”库—的前端，它允许编写替代前端，例如 GUI 前端。

Pacman 需要 X 功能！

如果您认为某个想法有价值，您可以选择在 pacman-dev 上讨论它。另请查看 https://gitlab.archlinux.org/pacman/pacman/-/issues 以获取现有功能请求。

但是，将功能添加到 pacman 或 Arch Linux 的最佳方法是自己实现它。该补丁或代码可能会或可能不会被官方接受，但也许其他人会欣赏、测试并为您的努力做出贡献。

我刚刚安装了软件包 X。我该如何启动它？

如果您正在使用像 KDE 或 GNOME 这样的桌面环境，如果程序带有桌面条目，它应该会自动显示在您的菜单中。如果您尝试从终端运行程序但不知道二进制文件名，请使用

$ pacman -Qlq package_name | grep /usr/bin/

为什么在官方仓库中每个共享库只有一个版本？

像 Debian 这样的几个发行版，将共享库的不同版本打包为不同的软件包：libfoo1、libfoo2、libfoo3 等。这样，就可以在同一系统上安装针对不同版本的 libfoo 编译的应用程序。

对于像 Arch 这样的发行版，只有最新的打包版本是官方支持的。通过放弃对过时软件的支持，软件包维护人员能够花费更多时间来确保最新版本按预期工作。一旦上游提供新版本的共享库，它就会被添加到仓库中，并且受影响的软件包会被重建以使用新版本。

如果我运行完整的系统升级，并且将要更新一个共享库，但没有更新依赖于它的应用程序，会怎么样？

这种情况根本不应该发生。假设一个名为 foobaz 的应用程序位于官方仓库之一中，并成功针对名为 libbaz 的新版本共享库构建，它将与 libbaz 一起更新。但是，如果它没有成功构建，则 foobaz 软件包将具有版本化的依赖项（例如 libbaz 1.5），并且由于冲突，将在 libbaz 升级期间被 pacman 删除。

如果 foobaz 是您自己构建并从 AUR 安装的软件包，您应该针对新版本的 libbaz 重建 foobaz。如果构建失败，请向 foobaz 开发人员报告错误。

仓库中是否可能存在主要的内核更新，并且某些驱动程序软件包尚未更新？

不，这不可能。主要的内核更新（例如，linux 3.5.0-1 到 linux 3.6.0-1）总是伴随着所有受支持的内核驱动程序软件包的重建。另一方面，如果您在系统上安装了不受支持的驱动程序软件包（例如来自 AUR），那么内核更新可能会破坏您的系统，如果您不为新内核重建它。用户负责更新他们安装的任何不受支持的驱动程序软件包。

升级前要做什么？

请按照系统维护#升级系统部分进行操作。

软件包更新已发布，但 pacman 说系统是最新的

pacman 镜像不会立即同步。更新可能需要 24 小时以上才能提供给您。唯一的选择是耐心等待或使用另一个镜像。镜像状态可以帮助您识别最新的镜像。

上游项目 X 发布了一个新版本。Arch 软件包更新到该新版本需要多长时间？

软件包更新将在准备就绪后发布。具体时间可能短至上游发布次要错误修复更新后的几个小时，长至大型软件包组的主要更新后的几周。从上游新版本到 Arch 发布新软件包的时间量取决于特定软件包和软件包维护人员的可用性。此外，一些软件包会在 testing 仓库中花费一些时间，因此这可能会延长软件包更新之前的时间。软件包维护人员尝试快速工作，将稳定的更新带到仓库中。如果您在官方仓库中找到过时的软件包，请转到软件包网站上该软件包的页面并标记它。

如果我需要已安装库的旧版本，我可以只符号链接到较新版本吗？

如果您幸运的话，它可能会暂时起作用。无论如何，这不是一个正确的解决方案，因为

库不会随机更改版本——API/ABI 可能已经更改（可能删除了位），而这些更改是否影响使用仅仅是运气问题。
符号链接将不会被软件包管理器跟踪。立即尝试破解系统库文件的新手最有可能进行他们无法诊断/修复的不需要的更改，而软件包管理器有助于防止这种情况发生。
将旧库文件转储到文件系统中，不被跟踪，这是一个稍微不同的替代方案，会被遗忘，并且不会注意到/修补潜在的安全漏洞。

相反，例如，使用/编写一个 compat（兼容性）软件包，它提供所需的库版本。

64 位

如何确定我的处理器是否与 x86_64 兼容？

如果您的处理器与 x86_64 兼容，您将在 /proc/cpuinfo 中找到 lm（长模式）标志。例如，

$ grep -w lm /proc/cpuinfo

在 Windows 下，使用免费软件 CPU-Z 有助于确定您的 CPU 是否与 64 位兼容。具有 AMD 的指令集“AMD64”或 Intel 的解决方案“EM64T”的 CPU 应与 x86_64 版本和二进制软件包兼容。

为什么要使用 64 位？

在大多数情况下，它速度更快，并且由于地址空间布局随机化 (ASLR) 的性质，结合位置无关代码 (PIC) 和 NX 位，也更安全，这是一个额外的优势。由于禁用了物理地址扩展 (PAE)，NX 位在 stock i686 内核中不可用。如果您的计算机有超过 4 GiB 的 RAM，则只有 64 位操作系统才能完全利用它。

程序员也越来越不关心 32 位（“旧版”），因为“新” x86 CPU 通常支持 64 位扩展。

我们可以列出更多理由来告诉您避免使用 32 位，但是在内核、用户空间和各个程序之间，列出 64 位现在做得更好的所有事情是不切实际的。