根据维基百科:
- Linux 内核是一个开源的、类 Unix 的、操作系统宏内核。
Arch Linux 基于 Linux 内核。除了最新的稳定内核之外,还有许多各种各样的 Linux 内核可供选择。本文列出了仓库中提供的一些选择,并对它们简要介绍。本文还介绍了一些可用的内核补丁。文章的最后总览了自行编译内核的方法,并包含各种方法的链接。
内核包安装在 /usr/lib/modules/
路径下,用于生成 /boot/
目录中的 vmlinuz 可执行镜像[1]。安装新的内核包后,需重新配置引导加载程序以适配变更。若需降级内核,请参阅降级软件包#降级内核。
官方支持的内核
- Stable — 采用了一些补丁的原版 Linux 内核和模块。
- Hardened — 注重安全的 Linux 内核,采用一系列加固补丁以缓解内核和用户空间漏洞。和 linux包 相比,它启用了上游更多的内核加固功能。
- Longterm — 长期支持(LTS)的 Linux 内核及模块,提供针对服务器使用场景优化的配置选项。
- Realtime kernel — 由 Ingo Molnar 领导的核心开发者小组维护。该补丁使内核的几乎所有部分可被抢占(除少量“raw_spinlock critical regions”(“原始自旋锁关键区域”)代码段外),通过将大多数内核自旋锁替换为支持优先级继承的互斥锁,并将所有硬件中断和软件中断迁移至内核线程处理实现。
- https://wiki.linuxfoundation.org/realtime/start || linux-rt包、linux-rt-lts包
- 注意:实时内核支持已并入 Linux 6.12
编译
可通过以下方式编译内核:
- /Arch 构建系统
- 利用已有的高质量的
linux
PKGBUILD 且可受益于包管理系统。 - /传统编译
- 需要手动下载内核源代码包,并以普通用户身份在自己的主目录中进行编译。
- 提高系统速度的最佳方法是先根据架构和处理器类型定制内核配置。
- 可以通过移除不使用的功能模块来减小内核体积(从而缩短编译时间)。例如禁用蓝牙、video4linux、千兆以太网等支持。
config
文件位于 Arch 软件包的源文件中(例如 linux包 链接到的 [2])。如果启用了 CONFIG_IKCONFIG_PROC
内核选项,当前运行的内核的 config
文件也可通过 /proc/config.gz
路径获取。部分列出的软件包也可通过非官方用户仓库获取预编译版本。
kernel.org 内核
- Git — 使用 Linus Torvalds Git 仓库源码构建的 Linux 内核及模块。
- Mainline — 每 2~3 个月发布一次的引入所有新功能的内核。
- Next — 包含待合并至下个 Mainline 版本的功能的前沿内核。
- DRM — 包含前沿 GPU 驱动程序的 Linux 内核。
- Longterm — 长期支持(LTS)的 Linux 内核和模块。
- https://www.kernel.org/ || linux-lts66AUR、linux-lts61AUR、linux-lts515AUR、linux-lts510AUR、linux-lts54AUR
非官方内核
- linux-lily — 本站站长 Lilydjwg 使用的内核,包含 cjktty、Android binder 和默认 BBR。这是一个较少更新的内核包,可以通过添加 archlinuxcn 仓库来安装。
- Ck — 包含 Con Kolivas 开发的补丁集(含 MuQSS 调度器),专为提升系统响应速度设计,特别针对桌面环境优化,也适用于其它各类工作负载。
- Clear — 包含 Intel Clear Linux 项目的优化补丁,提供性能与安全增强。
- Liquorix — 基于 Zen 内核源码并使用 Debian 配置方案构建的替代内核,专为桌面、多媒体和游戏场景优化,常用作 Debian 性能增强内核。维护者 Damentz 同时也是 Zen 补丁集的开发者。
- pf-kernel — 包含多项未合并入主线的前沿特性,由内核工程师维护。若补丁未正式移植到新版内核,项目将提供支持。当前主要特性包含 UKSM、DDCCI、v4l2loopback 和 BBRv3。
-
https://pfkernel.natalenko.name || 软件包:
- 通过 post-factum kernels 仓库获取或使用 linux-pfAUR(由开发者 post-factum 维护)
- Project C — 包含 Alfred Chen 的 Project C 补丁集(含 BMQ 和 PDS 调度器)。
- Nitrous — 针对 Skylake 及更新架构优化的修改版内核。
- tkg — 高度可定制的内核构建系统,提供多项性能优化补丁和调校选项(含 CFS、Project C PDS/BMQ、MuQSS 和 CacULE 调度器),由 Etienne Juvigny 维护。
- VFIO — 包含 Alex Williamson 开发的补丁(acs override 和 i915),用于在特定设备上实现 KVM PCI 直通功能。
- XanMod — 专为高性能工作站、游戏主机和媒体中心优化,采用 BFQ I/O 调度器、TCP BBRv3 拥塞控制、x86_64 高级指令集支持和部分 Clear Linux 补丁集。
- linux-cachyos — 由 CachyOS 开发的 SCHED-EXT + BORE + Cachy Sauce 增强内核,包含多项优化补丁。
疑难解答
内核 panic
当 Linux 内核进入不可恢复的故障状态时,会触发内核 panic(kernel panic)。该状态通常由存在缺陷的硬件驱动引发,导致系统死锁、无响应并需强制重启。在死锁发生前,内核会生成诊断信息,包含以下内容:故障发生时的机器状态(machine state)、指向识别故障的内核函数的调用轨迹(call trace),以及当前已加载的模块列表。值得庆幸的是,使用主线版本内核(例如官方仓库所提供的)时,内核 panic 概率较低。但仍需掌握遭遇此情况时的应对方法。
- 启动时添加内核参数
oops=panic
- 向
/proc/sys/kernel/panic_on_oops
写入1
检查 panic 信息
若内核 panic 发生在启动流程早期,控制台可能显示含“Kernel panic - not syncing:”的提示信息,而一旦 Systemd 开始运行,内核消息应被捕获并写入系统日志。然而,由于 panic 发生时系统会在 system-journald
记录前即死锁,故内核输出的诊断信息几乎从不写入磁盘日志。因此,查看 panic 信息(不配置 kdump crashkernel 的情况下)的唯一方式是在触发时通过控制台实时观察。可通过以下内核参数启动系统,并尝试在 tty1 复现 panic:
systemd.journald.forward_to_console=1 console=tty1
pause_on_oops=seconds
(seconds 为暂停秒数)来冻结屏幕输出。示例:问题模块分析
通过诊断信息可推测引发 panic 的子系统或模块。本例展示某虚拟设备启动时发生的 panic,请关注粗体标记的关键行:
kernel: BUG: unable to handle kernel NULL pointer dereference at (null) 1 kernel: IP: fw_core_init+0x18/0x1000 [firewire_core] 2 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 ... 3 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 4 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 5 kernel: Kernel Offset: 0x80000000 from 0xffffffff810000000 (relocation range: 0xffffffff800000000-0xfffffffffbffffffff kernel: ---[ end Kernel panic - not syncing: Fatal exception
- 指出引发 panic 的错误类型,本例为程序缺陷
- 显示 panic 发生在
firewire_core
模块的fw_core_init
函数 - 显示最近加载的模块是
firewire_core
- 显示调用
fw_core_init
的上层函数是do_one_initcall
- 确认该 oops 实际已成为 panic,系统进入死锁
由此可推断 panic 发生于 firewire_core
模块加载时的初始化例程(可能是该版本 FireWire 驱动存在程序错误,导致与硬件不兼容)。临时解决方案是阻止该模块加载:
- 若模块在 initramfs 阶段加载:使用内核参数
rd.blacklist=firewire_core
重启 - 其他情况:使用内核参数
module_blacklist=firewire_core
重启
调试回归问题
可尝试安装 linux-mainlineAUR 以确认问题是否已在上游修复。软件包评论区置顶说明中提及的预编译内核仓库可避免耗时的手动编译。
若问题非近期出现,建议测试 Arch Linux Archive 中的旧版 LTS 内核(linux-lts包)。
若问题仍存,请对 linux-gitAUR 内核进行二分排查(bisect),并按内核项目回归问题报告流程提交错误报告。具体报告途径需根据 MAINTAINERS
文件中标注的 Bugtracker(B:
条目)选择:子系统邮件列表、Kernel Bugzilla 或 DRM Gitlab 等平台。测试时需确保使用未打补丁的“原版”内核以排除第三方修改影响。若确认补丁引发问题,请直接联系补丁作者。
精简内核构建
通过以下方式可显著缩短内核编译时间:
- 使用 modprobed-db 工具仅编译本地系统所需的模块
- 运行
make localmodconfig
自动生成最小化配置
调试特定子系统时(如网络问题),可完全移除无关驱动(例如声卡驱动)以进一步精简配置。
参见
- O'Reilly - Linux Kernel in a Nutshell(免费电子书)
- What Stable Kernel Should I Use?(Greg Kroah-Hartman 撰文)
- Linux 内核官方文档