Kernel

根据维基百科

Linux 内核是一个开源的单内核 Unix-like 计算机操作系统内核。

Arch Linux 基于 Linux 内核。除了最新的稳定内核之外，还有各种可用于 Arch Linux 的替代 Linux 内核。本文列出了一些在软件仓库中可用的选项，并对每个选项进行了简要描述。本文还描述了可以应用于系统内核的补丁。文章末尾概述了自定义内核编译，并提供了各种方法的链接。

内核软件包安装在 /usr/lib/modules/ 路径下，随后用于在 /boot/ 中生成 vmlinuz 可执行映像。[1] 当安装不同的内核或在多个内核之间切换时，您必须配置您的引导加载程序以反映这些更改。有关将内核降级到旧版本的信息，请参阅软件包降级#降级内核。

官方支持的内核

官方支持的内核可在论坛和错误报告中获得社区支持。

Stable — Vanilla Linux 内核和模块，应用了一些补丁。

https://linuxkernel.org.cn/ || linux

Hardened — 侧重于安全的 Linux 内核，应用了一组强化补丁以缓解内核和用户空间漏洞利用。它还启用了比 linux 更多的上游内核强化功能。

https://github.com/anthraxx/linux-hardened || linux-hardened

Longterm — 长期支持 (LTS) Linux 内核和模块，其配置选项针对服务器中的使用。

https://linuxkernel.org.cn/ || linux-lts

Realtime kernel — 由 Ingo Molnar 领导的一小群核心开发人员维护。此补丁允许几乎所有内核都被抢占，除了少数非常小的代码区域（“raw_spinlock 临界区”）。这是通过将大多数内核自旋锁替换为支持优先级继承的互斥锁，以及将所有中断和软件中断移动到内核线程来完成的。

https://wiki.linuxfoundation.org/realtime/start || linux-rt, linux-rt-lts

注意： 实时内核支持已合并到 Linux 6.12

Zen Kernel — 内核黑客协作努力的成果，旨在为日常系统提供最佳的 Linux 内核。有关更多详细信息，请参阅 FAQ 和 Detailed Feature List。

https://github.com/zen-kernel/zen-kernel || linux-zen

编译

以下方法可用于编译您自己的内核

/Arch 构建系统: 利用现有 linux PKGBUILD 的高质量以及软件包管理的优势。
/传统编译: 涉及手动下载源代码 tarball，并在您的主目录中以普通用户身份进行编译。

警告

使用自定义内核可能会导致各种稳定性和可靠性问题，包括数据丢失。强烈建议进行备份。
Arch Linux 仅对#官方支持的内核提供官方支持。当使用不同的内核时，请在支持请求中提及。

提示

提高系统速度的最佳方法是首先根据您的架构和处理器类型定制内核配置。
您可以通过不包含对您没有或不使用的东西的支持来减小内核的大小（并因此缩短构建时间）。例如，对蓝牙、video4linux、1000Mbit 以太网等的支持。

Arch 内核软件包的 config 文件位于 Arch 软件包源文件中（例如，[2] 链接自 linux）。如果启用了 CONFIG_IKCONFIG_PROC 内核选项，则您当前正在运行的内核的 config 文件也可能在您的文件系统中的 /proc/config.gz 中可用。

某些列出的软件包也可能通过非官方用户仓库以二进制软件包的形式提供。

kernel.org 内核

Git — 使用来自 Linus Torvalds 的 Git 仓库的源代码构建的 Linux 内核和模块。

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git || linux-git^AUR

Mainline — 所有新功能都在其中引入的内核，每 2-3 个月发布一次。

https://linuxkernel.org.cn/ || linux-mainline^AUR

Next — 包含待合并到下一个 mainline 版本的特性的前沿内核。

https://linuxkernel.org.cn/doc/man-pages/linux-next.html || linux-next-git^AUR

DRM — 具有前沿 GPU 驱动程序的 Linux 内核。

https://cgit.freedesktop.org/drm/ || linux-drm-tip-git^AUR, linux-drm-next-git^AUR

Longterm — 长期支持 (LTS) Linux 内核和模块。

https://linuxkernel.org.cn/ || linux-lts66^AUR, linux-lts61^AUR, linux-lts515^AUR, linux-lts510^AUR, linux-lts54^AUR

非官方内核

Ck — 包含 Con Kolivas 的补丁（包括 MuQSS 调度器），旨在提高系统响应速度，特别强调桌面，但它们适用于任何工作负载。

http://ck.kolivas.org/ || linux-ck^AUR

Clear — 来自 Intel 的 Clear Linux 项目的补丁。提供性能和安全优化。

https://github.com/clearlinux-pkgs/linux || linux-clear^AUR

Libre — 没有专有或混淆的设备驱动程序。

https://www.fsfla.org/ikiwiki/selibre/linux-libre/ || linux-libre^AUR

Liquorix — 使用面向 Debian 的配置和 Zen 内核源代码构建的内核替代品。专为桌面、多媒体和游戏工作负载而设计，通常用作 Debian Linux 性能替代内核。Liquorix 补丁集的维护者 Damentz 也是 Zen 补丁集的开发人员。

https://liquorix.net || linux-lqx^AUR

pf-kernel — 提供一些未合并到内核 mainline 的出色功能。由内核工程师维护。如果包含的新内核补丁的端口未正式发布，则该补丁集提供并支持到新内核的补丁端口。linux-pf 当前最突出的补丁是 UKSM、DDCCI、v4l2loopback 和 BBRv3。

https://pfkernel.natalenko.name || 软件包

仓库, linux-pf^AUR by pf-kernel 开发者 post-factum

Project C — 带有 Alfred Chen 的 Project C 补丁集（BMQ 和 PDS 调度器）的内核。

https://gitlab.com/alfredchen/projectc || linux-prjc^AUR

Nitrous — 针对 Skylake 及更新版本优化的修改后的 Linux 内核。

https://gitlab.com/xdevs23/linux-nitrous || linux-nitrous^AUR

tkg — 一个高度可定制的内核构建系统，提供一系列旨在提高桌面和游戏性能的补丁和调整。它由 Etienne Juvigny 维护。在其他补丁中，它提供了各种 CPU 调度器：CFS、Project C PDS、Project C BMQ、MuQSS 和 CacULE。

https://github.com/Frogging-Family/linux-tkg || 在 chaotic-aur 中可用。

VFIO — Linux 内核和 Alex Williamson 编写的一些补丁（acs override 和 i915），以在某些机器上使用 KVM 实现 PCI Passthrough 功能。

https://lwn.net/Articles/499240/ || linux-vfio^AUR, linux-vfio-lts^AUR

XanMod — 旨在充分利用高性能工作站、游戏桌面、媒体中心等，并旨在提供更稳定、响应更快、更流畅的桌面体验。此内核使用 BFQ I/O 调度器、TCP BBRv3 拥塞控制、x86_64 高级指令集支持、部分 clear linux 补丁集和其他默认更改。

https://xanmod.org/ || linux-xanmod^AUR, linux-xanmod-lts^AUR, linux-xanmod-rt^AUR, linux-xanmod-bore^AUR

linux-cachyos — CachyOS 的 Linux SCHED-EXT + BORE + Cachy Sauce 内核，带有其他补丁和改进的内核和模块

https://github.com/CachyOS/linux-cachyos || linux-cachyos^AUR

故障排除

内核崩溃

内核崩溃发生在 Linux 内核进入不可恢复的故障状态时。该状态通常源于有缺陷的硬件驱动程序，导致机器死锁、无响应并需要重启。就在死锁之前，会生成一条诊断消息，其中包括：发生故障时的机器状态、导致内核函数识别故障的调用堆栈以及当前加载的模块列表。值得庆幸的是，使用内核的mainline 版本（例如官方仓库提供的版本）时，内核崩溃的情况并不经常发生，但当它们确实发生时，您需要知道如何处理它们。

注意： 内核崩溃有时被称为 oops 或 kernel oops。虽然崩溃和 oops 都是由于故障状态而发生的，但 oops 更笼统，因为它不一定会导致机器死锁：有时内核可以通过杀死有问题的任务并继续运行来从 oops 中恢复。

提示： 在启动时传递内核参数 oops=panic 或写入 1 到 /proc/sys/kernel/panic_on_oops 以强制可恢复的 oops 发出崩溃。如果您担心 oops 恢复可能导致系统不稳定，从而使以后的错误难以诊断，则建议这样做。

检查崩溃信息

如果内核崩溃在启动过程的早期发生，您可能会在控制台上看到一条包含 “Kernel panic - not syncing:” 的消息，但是一旦 Systemd 运行，内核消息通常会被捕获并写入系统日志。但是，当发生崩溃时，内核输出的诊断消息几乎从不写入磁盘上的日志文件，因为机器在 system-journald 有机会之前就死锁了。因此，检查崩溃消息的唯一方法是在它发生时在控制台上查看它（无需设置 kdump crashkernel）。您可以通过使用以下内核参数启动并在 tty1 上尝试重现崩溃来做到这一点

systemd.journald.forward_to_console=1 console=tty1

提示： 如果崩溃消息滚动太快而无法检查，请尝试在启动时传递内核参数 pause_on_oops=seconds。

示例场景：错误的模块

可以使用诊断消息中的信息，最好地猜测哪个子系统或模块导致了崩溃。在此场景中，我们在某台假想机器的启动过程中发生了崩溃。请注意以粗体突出显示行

kernel: BUG: unable to handle kernel NULL pointer dereference at (null) ¹
kernel: IP: fw_core_init+0x18/0x1000 [firewire_core] ²
kernel: PGD 718d00067
kernel: P4D 718d00067
kernel: PUD 7b3611067
kernel: PMD 0
kernel:
kernel: Oops: 0002 [#1] PREEMPT SMP
kernel: Modules linked in: firewire_core(+) crc_itu_t cfg80211 rfkill ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG nf_conntrack_ipv4 ... ³
kernel: CPU: 6 PID: 1438 Comm: modprobe Tainted: P           O    4.13.3-1-ARCH #1
kernel: Hardware name: Gigabyte Technology Co., Ltd. H97-D3H/H97-D3H-CF, BIOS F5 06/26/2014
kernel: task: ffff9c667abd9e00 task.stack: ffffb53b8db34000
kernel: RIP: 0010:fw_core_init+0x18/0x1000 [firewire_core]
kernel: RSP: 0018:ffffb53b8db37c68 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
kernel: RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffffc16d3af4
kernel: RBP: ffffb53b8db37c70 R08: 0000000000000000 R09: ffffffffae113e95
kernel: R10: ffffe93edfdb9680 R11: 0000000000000000 R12: ffffffffc16d9000
kernel: R13: ffff9c6729bf8f60 R14: ffffffffc16d5710 R15: ffff9c6736e55840
kernel: FS:  00007f301fc80b80(0000) GS:ffff9c675dd80000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000000 CR3: 00000007c6456000 CR4: 00000000001406e0
kernel: Call Trace:
kernel:  do_one_initcall+0x50/0x190 ⁴
kernel:  ? do_init_module+0x27/0x1f2
kernel:  do_init_module+0x5f/0x1f2
kernel:  load_module+0x23f3/0x2be0
kernel:  SYSC_init_module+0x16b/0x1a0
kernel:  ? SYSC_init_module+0x16b/0x1a0
kernel:  SyS_init_module+0xe/0x10
kernel:  entry_SYSCALL_64_fastpath+0x1a/0xa5
kernel: RIP: 0033:0x7f301f3a2a0a
kernel: RSP: 002b:00007ffcabbd1998 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
kernel: RAX: ffffffffffffffda RBX: 0000000000c85a48 RCX: 00007f301f3a2a0a
kernel: RDX: 000000000041aada RSI: 000000000001a738 RDI: 00007f301e7eb010
kernel: RBP: 0000000000c8a520 R08: 0000000000000001 R09: 0000000000000085
kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000c79208
kernel: R13: 0000000000c8b4d8 R14: 00007f301e7fffff R15: 0000000000000030
kernel: Code: <c7> 04 25 00 00 00 00 01 00 00 00 bb f4 ff ff ff e8 73 43 9c ec 48
kernel: RIP: fw_core_init+0x18/0x1000 [firewire_core] RSP: ffffb53b8db37c68
kernel: CR2: 0000000000000000
kernel: ---[ end trace 71f4306ea1238f17 ]---
kernel: Kernel panic - not syncing: Fatal exception ⁵
kernel: Kernel Offset: 0x80000000 from 0xffffffff810000000 (relocation range: 0xffffffff800000000-0xfffffffffbffffffff
kernel: ---[ end Kernel panic - not syncing: Fatal exception

指示导致崩溃的错误类型。在这种情况下，这是一个程序员错误。
指示崩溃发生在模块 firewire_core 中的名为 fw_core_init 的函数中。
指示 firewire_core 是最新加载的模块。
指示调用函数 fw_core_init 的函数是 do_one_initcall。
指示此 oops 消息实际上是一个内核崩溃，并且系统现在已死锁。

然后我们可以推断出，崩溃发生在加载模块 firewire_core 时模块的初始化例程期间。（然后我们可能会假设机器的 firewire 硬件与此版本的 firewire 驱动程序模块不兼容，原因是程序员错误，并且必须等待新版本发布。）同时，使机器再次运行的最简单方法是阻止模块加载。我们可以通过以下两种方式之一做到这一点

如果模块在执行 initramfs 期间加载，请使用内核参数 rd.blacklist=firewire_core 重启。
否则，使用内核参数 module_blacklist=firewire_core 重启。

重启进入 root shell 并修复问题

此条目或章节已过时。

原因： 由于 initramfs 中的 root 帐户已锁定，rd.rescue 和 rd.emergency 将不起作用。（在 Talk:Kernel 中讨论）

此条目或章节的事实准确性存在争议。

原因： 键盘在 rd.emergency 中不起作用，因此无法使用。（在 Talk:Kernel 中讨论）

您将需要 root shell 来更改系统，以便不再发生崩溃。如果崩溃发生在启动时，则有几种策略可以在机器死锁之前获得 root shell

使用内核参数 emergency、rd.emergency 或 -b 重启，以便在 root 文件系统挂载且 systemd 启动后立即收到登录提示符。

注意： 此时，root 文件系统将以只读方式挂载。以 root 用户身份执行 mount -o remount,rw / 以进行更改。

使用内核参数 rescue、rd.rescue、single、s、S 或 1 重启，以便在本地文件系统挂载后立即收到登录提示符。
使用内核参数 systemd.debug_shell 以在 tty9 上获得非常早期的 root shell。通过按 Ctrl+Alt+F9 切换到它。
通过使用不同的内核参数集重启来尝试禁用导致崩溃的内核功能。尝试“旧的备用” acpi=off 和 nolapic。

提示： 有关所有内核参数，请参阅 kernel-parameters.html。

作为最后的手段，使用 Arch Linux 安装介质启动，并将 root 文件系统挂载到 /mnt，然后以 root 用户身份执行 arch-chroot /mnt。
禁用导致崩溃的服务或程序，回滚错误的更新，或修复配置问题。

提示： 如果原始 initial ramdisk 映像损坏，则可能需要生成新的映像。当内核更新中断时，可能会发生这种情况。有关创建新映像的信息，请参阅mkinitcpio。

调试回归

请参阅通用故障排除#调试回归。

尝试 linux-mainline^AUR 以检查问题是否已在上游修复。置顶评论还提到了一个包含已构建内核的仓库，因此可能不需要手动构建它，这可能需要一些时间。

也值得考虑尝试 LTS 内核 (linux-lts) 来调试最近未出现的问题。旧版本的 LTS 内核可以在Arch Linux 存档中找到。

如果问题仍然存在，请二分 linux-git^AUR 内核，并根据内核流程报告报告回归的错误。根据 MAINTAINERS 文件中的 Bugtracker (B:) 条目，这需要通过子系统的邮件列表、Kernel Bugzilla 或其他问题跟踪器（如 DRM Gitlab）打开一个 issue。重要的是尝试没有任何补丁的“vanilla”版本，以确保它与它们无关。如果补丁导致问题，请将其报告给补丁的作者。

注意： 二分内核可能需要花费大量时间，因为它可能需要多次重建。

构建更小的内核

您可以使用 modprobed-db 或通过 make localmodconfig 构建本地系统所需的模块来缩短内核构建时间。当然，您可以完全删除不相关的驱动程序，例如声卡驱动程序来调试网络问题。

参见

O'Reilly - Linux Kernel in a Nutshell （免费电子书）
我应该使用哪个稳定内核？ Greg Kroah-Hartman 著
Linux 内核文档