Linux内核编译完全指南：从源码到自定义内核的实战教程

1. 动手之前，先把内核这件事想清楚

我记得自己第一次冒出“要不自己编一个内核”这个念头的时候，心里其实挺没底的。那时候系统偶尔卡顿，又恰好看到某个群聊里有人提到自己编译的内核跑起来快不少，我就跟着心动。结果翻了一堆教程，不是过于陈旧，就是直接甩一条 configure 命令让你跑完拉倒，完全没有解释为什么。折腾到半夜，重启之后直接进不了图形界面，只好灰溜溜地恢复系统。后来把整套流程跑通，才发现这东西真的不难，难的是没人把背后的逻辑讲透。

写这篇的目的，就是把这套“自己制作 Linux 内核”的流程掰开揉碎。从准备环境、选源码、做配置、编译、安装到回退，每一步我都会告诉你是什么、为什么、怎么做，还会把我在过程中踩过的坑原样搬出来。这篇适合谁？三类人：一是在校学生，想通过内核编译理解操作系统课程的抽象概念；二是开发者和运维，需要针对特定硬件或业务场景定制内核；三就是纯粹想让电脑跑得更顺手、顺便长长见识的爱好者。哪怕之前对编译零基础，只要会用 Linux 命令行，跟着走一遍，也能在你自己的机器上跑起来一个属于你的内核。

这里先给个心理预期：整个过程，在普通 i5 级别处理器上，从下载源码到最终重启进入新内核，顺利的话大约需要两到三个小时。绝大部分时间都花在编译上，你真正需要动手操作的部分其实不多。

2. 准备阶段：硬件、依赖和磁盘空间

2.1 先确认机器能不能“扛得住”内核编译

编译内核本身对 CPU 和内存有一定要求，但真没有某些教程夸大的那么吓人。以我的体验来说，双核四线程的处理器加 4GB 内存完全可以跑完，只是时长感人。内存这里要单独提醒一句：如果你只有 2GB 内存，建议先增加交换分区，或者临时开一个 swap 文件，否则并行编译时很容易因为内存耗尽导致假死。我自己的机器是 16GB 内存，这个容量下无论怎么折腾都很宽裕，但这不代表配置不够就不能玩。

磁盘空间是另一个容易忽略的点。内核源码解压后大概占用 1.5GB 左右，编译产生的中间文件和最终镜像会再占几个 GB。我建议至少留出 20GB 空闲空间再动手，因为后续可能还要装调试符号、保留多版本内核，这些都会吃掉磁盘。如果空间不够，整个编译过程会在某个时刻突然以 no space left 的形式毫无预兆地挂掉，你前面好几个小时的等待就全部归零，那个滋味我替你们试过了，非常不好受。

2.2 前置软件包清单与检查命令

除了空间，编译工具链也得备齐。不同发行版安装方式不一样，但装包的本质是一回事：你需要的是一套完整编译工具链、内核配置辅助工具和源码解压工具。

对于 Debian 系的发行版，我通常这样安装：

sudo apt update sudo apt install build-essential flex bison libssl-dev libelf-dev dwarves \ libncurses-dev git bc cpio kmod

对于 Red Hat 系发行版，则用：

sudo dnf groupinstall "Development Tools" sudo dnf install ncurses-devel openssl-devel elfutils-libelf-devel \ flex bison bc dwarves

我不太建议你在这一步随意删减软件包，因为后面配置阶段遇到各种报错时，往往就是某个工具链组件缺失导致的。比如缺libssl-dev，编译到中间某个模块时会报openssl/xxx.h: No such file or directory，这个报错一出现，网上查到的答案基本都是让你补装这个包。与其到时候手忙脚乱，不如一开始就装齐。

安装完毕之后可以先跑一下make --version和gcc --version，确认工具没有异常。

2.3 关于虚拟机还是物理机的选择

如果你用的是虚拟机，有一点必须提前知道：虚拟机里的 CPU 加速能力会直接影响编译速度。VMware 或 KVM 里开启硬件虚拟化支持的机器，编译速度和物理机差别不大；但如果没开嵌套虚拟化，编译时间会成倍上升。另外，虚拟机里编译完的内核，如果装的是精简版镜像，可能会缺少某些硬件驱动，进而出现网卡不识别这类问题。这不是你操作错了，是虚拟机虚拟硬件与内核配置不匹配导致的。我的建议是第一次实验尽量在物理机上做，跑通了再回到虚拟机上玩定制功能。如果手头没有物理机可操作，那就在虚拟机里多预留几个 GB 的 /boot 空间，后面恢复起来也容易一些。

3. 源码获取：版本选择与下载校验

3.1 到底该选哪个版本的内核

这是很多新手第一次面对选择就蒙圈的地方：内核官网明明挂着好几个版本分类，到底下哪个？

我的建议非常明确：选最新的长期支持版本。原因很简单，LTS 版本经过最充分的测试，稳定性在长期维护中不断得到验证，而且大部分主流发行版都基于 LTS 内核做打包，遇到问题时的网上讨论和补丁也最多。如果你下载最新 RC 版本或者激进的主线版本，也许能体验到新功能，但伴随而来的是某些第三方驱动没有及时适配，连编译都可能通不过。既然第一目标是成功跑起来，就别为难自己。

查看并选择版本可以到内核官网的发布页面，也可以在终端里直接访问：

curl -s https://www.kernel.org/ | grep -oP '最新版本号的正则此处省略'

更直白的方法，就是打开内核官网首页，看到标着 "mainline" 和 "stable" 的版本，优先选 stable 类目下版本号最大的那个。

3.2 下载源码的两种方式和校验

国内下载内核源码，从官网直接跑可能速度不稳，建议优先使用国内高校或云厂商的镜像站，这几年能选的源非常多，速度普遍能跑到几 MB 每秒。还有一种方式是直接从你用的发行版仓库里拿内核源码包，例如 Debian 系的apt source linux，这种包会带上发行版的定制补丁，跟系统当前的配置最贴近，理论上编译成功率最高，但缺点是你后续想跟踪上游特性时会被补丁干扰。

我平时习惯的做法是从镜像站下载标准主线源码包：

cd ~ wget https://mirrors.某edu.cn/linux/kernel/v6.x/linux-6.6.xx.tar.xz

下载完成后一定做校验。源码包旁边一般会有.sign文件，你可以用 gpg 验证签名，也可以偷懒用 sha256sum 对比官网公布的哈希值。这一步不是可有可无，万一你下到损坏的压缩包，解压时报错还是小事，编译到一半出现莫名的段错误才真的让人头疼。我在给别人排查编译失败问题时，就不止一次发现根源是下载损坏的源码包。

3.3 解压与源码目录初印象

校验没问题之后解压：

tar -xvf linux-6.6.xx.tar.xz cd linux-6.6.xx

第一次进入源码目录，很多人会对着上百个子目录发愣。这里不需要面面俱到，你只需要先认识这几个：

arch/ # 架构相关代码，x86 或 arm 的核心代码都在里面 drivers/ # 硬件驱动，占整个内核代码的绝大部分 fs/ # 文件系统实现 kernel/ # 核心调度、进程管理、信号等主逻辑 net/ # 网络协议栈 init/ # 内核初始化入口 mm/ # 内存管理

编译的时候，大部分时间会耗在drivers/和fs/这两个目录上，所以如果你看编译日志时发现大部分时间停在某个驱动文件上，不用意外。以后如果要做深度定制，你会在这些目录里寻找需要的模块代码位置。

提示：建议把源码目录放在家目录下，不要放在 /tmp 或 /root 下。一是 /tmp 可能被系统定期清理，二是某些发行版对 /root 目录的权限处理会更严格，编译过程中的临时文件可能引发奇怪的权限问题。

4. 内核配置：成败往往在此一举

4.1 make config 三兄弟到底怎么选

拿到源码之后，第一件正事就是生成配置文件。内核提供了三种主流交互方式：

第一次玩的话，我非常推荐make menuconfig。它在纯文本终端里就能打开，通过方向键上下选择、空格键切换状态、回车进入子目录，体验非常接近图形界面，而且不依赖显示服务器，按起来很顺手。

基于当前系统配置快速生成初始配置则是一个常用命令：

make localmodconfig

这条命令会扫描当前系统的内核模块加载情况，生成一份只包含当前硬件所需驱动的精简配置。对于只想快速成功跑起新内核的场景，这一步能省掉大量手动配置的时间。但注意它的局限性：如果你的某个外接设备当前没插着，或者某个功能模块当前没在运行，它就可能没有被包含进去，下次插上设备时会发现驱动缺失。

我在第一次实验时就犯过这个错误：用 localmodconfig 生成了配置，编译安装完后重启，发现无线网卡消失了。排查了半天才发现，我当前是用网线连接，无线网卡模块没有被加载，因此被它排除在配置之外。从那以后，我都是先用 localmodconfig 打底，再手动进入 menuconfig 把常用的文件系统和硬件驱动补全。

4.2 需要手动确认的基础配置项

在make menuconfig界面里，有几个核心设置项我建议每次都亲自过一遍，不要完全依赖默认值。

一是文件系统支持，进入File systems菜单，确认你的根分区类型被勾选。比如你平时系统装在 ext4 分区，就确保ext4后面的状态不是 M（模块）而是 *（内置）。如果你不确定，建议除了常用 ext4、XFS、Btrfs 之外，再把 F2FS 这类也勾上，反正现在磁盘空间不缺，多放几种文件系统支持有备无患。

二是启动时需要的块设备驱动。新机器用 NVMe 固态的非常多，建议进入Device Drivers→Block devices和NVMe support，确认 NVMe 协议支持被编译进内核，否则进系统时会找不到硬盘。老一点的机器则注意检查 SATA 控制器相关的 AHCI 支持。

三是 initramfs 的配置。内核本身不负责挂载根文件系统之前的所有准备工作，它需要借助 initramfs 来加载必要的驱动和工具。你在配置里看到的Initramfs source file这一项，我们一般保持默认即可，因为最终生成 initramfs 是交给发行版工具完成的。这个概念有点绕，你可以理解为内核是一个被掰成两半的行李箱，一多半是内核本体，另一半是 initramfs 这个应急包，两者相互配合才能完成启动。

4.3 模块编译方式的内置与模块化

内核源码里几乎每个功能都有三种编译状态：留空表示不编译、M 表示编译成模块、* 表示编译进内核镜像。这里新手最容易迷糊。

这个选择的本质是权衡启动速度、镜像大小和灵活性。编译进内核，开机时无需等待模块加载，立刻可用；编译成模块，则可以根据需要在系统启动后再加载，节省内存和内核体积。对于根文件系统挂载必需的驱动，一定要用 * 而不是 M，因为内核在执行挂载根分区时，模块还没被加载，驱动不在场，系统就崩在这一步。对其他外设驱动，用 M 更合理，反正现代系统都会用 initramfs 提前加载需要的模块。

我在 menuconfig 里只手动调了几处：确认 NVMe 为 *，确认 ext4 为 *，其余网卡、声卡这些设置都用 M。保存退出之后，配置文件会写入源码目录下的.config。这一步完成，你就成功绕过了整个流程中最大的认知门槛。

5. 编译：等待的艺术与参数调优

5.1 编译命令的完整流程

配置完成后，就是整个过程中最漫长也最解压的编译阶段。命令其实非常简单：

make -j8

这里的-j8是并行编译的线程数。理论上 8 表示同时用 8 个任务去编译，但并不是线程数越多越快。我踩过的坑是，在一台只有 4 个物理核心的机器上傻乎乎地开了-j32，结果编译到一半系统直接 OOM，鼠标键盘都卡住，最后强杀了进程。合理的选择是让并发数和你的 CPU 物理核心数相当，或者稍大一点。可以用nproc查看：

nproc

如果结果显示 8，你可以用-j10或-j12，留一点余量给系统本身使用。相反，如果内存不足，哪怕核心数很多，也建议降低-j数值。编译是 IO 密集且内存消耗不小的工作，别让并行任务吃光所有资源。

5.2 编译日志的阅读姿势

编译过程中，屏幕上会快速滚过大量编译命令。这些日志看起来吓人，但你只需要关注两类信息：headed warning 和 error。warning 一般不影响最终产物，比如某个变量未使用这类优化提示。error 则不一样，它会直接中断编译。

我遇到的 error 之一是在编译某版本时提示缺少openssl/xxx.h，这就是前面提到的依赖缺失问题。遇到这类情况，先别反复重试，停下来安装依赖包，然后继续编译。编译支持断点续跑，你不需要从零再来，直接重新执行make就可以，它会跳过已经完成的部分。

5.3 编译产物与模块编译安装

编译结束后，源码目录下会生成编译产物，其中最重要的有两个：一个是压缩后的内核镜像arch/x86/boot/bzImage，另一个是全部模块的编译输出。在安装之前，我们需要把模块安装到系统目录中：

sudo make modules_install

这条命令会把编译出的所有 .ko 模块文件按路径安装到/lib/modules/6.6.xx/下。这个目录结构以后排查驱动问题时非常有用，你可以用：

ls /lib/modules/6.6.xx/kernel/drivers/net/wireless/

来检查某个无线网卡驱动是否被正确安装。

紧接着安装内核本体：

sudo make install

这个命令会自动完成一系列工作：把内核镜像复制到/boot目录，在/boot下生成对应的 System.map 和 config 文件，并生成新的 initramfs。它也会尝试自动更新引导程序配置。不过发行版之间的 make install 行为差异比较大，所以我接下来单独讲一节启动引导的配置，因为这块最容易出现问题。

6. 引导配置与首次重启：关键几步不能省

6.1 initramfs 的生成

make install在 Debian 系发行版上通常会调用 update-initramfs 工具生成与内核版本对应的 initramfs。你可以在/boot目录下看到新生成的文件：

initrd.img-6.6.xx vmlinuz-6.6.xx System.map-6.6.xx config-6.6.xx

如果你发现/boot下没有 initramfs 文件，就用以下命令手动生成：

sudo update-initramfs -c -k 6.6.xx

其中6.6.xx是你刚刚编译出来的内核版本号。这个文件如果在安装阶段缺席，启动时系统会卡在挂载根文件系统之前，表现就是一个只有短暂光标闪烁的黑屏。我有一次自己写脚本自动化安装时就漏掉了这一环，连续折腾了三个小时才意识到，从此之后每次安装完内核，第一件事就是检查/boot目录的完整性。

6.2 引导程序的更新

make install不一定能顺利更新引导菜单，保险起见还是手动执行一下。Debian 系发行版执行：

sudo update-grub

Red Hat 系发行版执行：

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

执行完之后，可以查看一下是否有新内核条目出现。如果引导列表里还是只有旧内核，多半是你的引导配置对内核版本格式做了过滤，这时候需要检查一下/etc/default/grub里是否有类似GRUB_DISABLE_OS_PROBER或默认内核选择的限制参数。把限制项调整后再重新生成一次引导配置即可。

6.3 首次重启与必备的回退方案

万事俱备，终于可以重启：

sudo reboot

重启后，在 GRUB 菜单里你会看到新旧两个内核选项，此时选择新内核进入。如果一切顺利，你会看到熟悉的登录界面；如果失败，最常见的表现是启动过程中卡在 logo 界面、黑屏、或者直接进入紧急模式。

这里想重点说一个我事后才体会到价值的操作：进入新内核之前，先确认旧内核在引导菜单里仍然存在。只要旧内核还留在/boot里，出问题后重启选旧内核就能回到一个完全可用的系统。很多初学者焦虑的原因就是怕把系统弄坏，实际上下班后只要保留旧内核，你的恢复路径就一直畅通。

进不了系统时的应急手段是，在 GRUB 菜单界面按e进入编辑模式，找到以linux开头的行，在末尾加入：

systemd.unit=emergency.target

或者：

single

这样能以内核最小环境启动，绕过图形界面和用户态服务，帮你一步步排查问题。回退到旧内核后，再慢慢分析失败原因。

7. 启动失败排查与验证新内核

7.1 进不去系统的三板斧排查法

首次启动失败时，先别急着怀疑是内核有问题。我的排查顺序基本是这个逻辑。

第一步看 GRUB 里选择的新内核是否与/boot目录里的文件名一致。有时候安装时会留下多个版本号非常相似的内核文件，选择的条目和实际镜像不匹配可能是人为误选。

第二步看 initramfs 是否缺失或损坏。启动过程中如果报出unable to find root device之类的错误，多半就是 initramfs 与根文件系统驱动不匹配。这一步可以在 GRUB 编辑界面按e，查看initrd行指向的文件是否存在。如果文件名不对，有经验的修复思路是从紧急模式挂载系统根分区，手动重新生成 initramfs。

第三步看根文件系统类型是否有误。比如你根分区是 Btrfs，但你新内核配置里 Btrfs 被当成模块而不是内建，这就导致启动时找不到根设备。遇到这种情况，回到修复环境，重新改配置把相应文件系统改为 *，重新编译即可。

7.2 进入系统后的内核验证

假设成功进入系统，先用几个命令确认自己的确跑在新内核上：

uname -r dmesg | grep -i "linux version" cat /boot/config-$(uname -r) | grep CONFIG_LOCALVERSION

第一个命令看当前内核版本号，第二个看启动时打印的真实内核标识，第三个确认配置文件与编译时一致。这些信息以后写进博客或者向别人炫耀时，都是实打实的硬指标。

还可以检查模块加载数量：

lsmod | wc -l

如果你用 localmodconfig 生成了精简配置，这个数字通常会比发行版默认内核少很多。这也是很多人说自编内核“更快”的一个直观来源——模块少了，启动时要做的工作自然少。但说实话，相比模块数量，更关键的是你配置里关掉了一些不常用的调试选项，这部分对启动速度的提升更明显。不过这种提升在日常使用中体感也不一定特别夸张，除非你原本跑在视频输出的图形界面驱动都没有被正确匹配的场景。

7.3 新内核与旧内核的日常共存

内核编译安装是一个可反复进行的过程。你不必担心装上之后旧内核被覆盖。现代发行版都会保留多个内核版本，/boot下的文件按版本号区分，互不冲突。引导菜单里默认选哪个，可以通过修改GRUB_DEFAULT来控制。比如想默认进入新内核，可以查一下新内核在菜单中的编号，然后设置：

# 在 /etc/default/grub GRUB_DEFAULT=0

不同的引导器有不同编号规则，稳妥做法是把GRUB_DISABLE_OS_PROBER这类参数视情况调整，然后重新生成菜单。

依赖项目管理上也有小建议：每次编译新内核，旧版本的/lib/modules/目录都会继续保留，这是刻意的设计，方便你随时切换旧内核时模块完整。如果你确定短期内不会再回到旧内核，可以用sudo apt autoremove清理发行版自动管理的旧内核包，但自编译的版本需要手动删除/lib/modules/对应目录和/boot下对应文件。这个操作要谨慎，保留多一个内核始终是安全的。

8. 进阶玩法：定制选项与优化方向

8.1 使用本地配置快照来加速后续编译

当你成功编译过一个内核后，你会发现.config文件就是这个过程的核心资产。把它保存起来：

cp .config ~/kernel-config-backup-6.6.xx

下次下载新内核源码以后，直接复制回来再执行make oldconfig，它会询问你新旧配置之间的差异项，只有新增的选项需要你决定。这样几十秒就能完成配置，不用重新把所有菜单过一遍。这几乎是内核开发环境下最有效率的工作流。

8.2 常用性能与调试选项的取舍

编译阶段有几个配置开关值得了解。

CONFIG_DEBUG_INFO决定是否生成调试信息。开启后内核体积会显著增大，编译时间也会拉长。如果你不打算用 GDB 调试内核、不分析内核转储，可以关掉它。第一次编译成功之后，如果你想再编译一版精简内核，关闭它会是一个很明显的体积优化。部分发行版会默认开启，这也是为什么自编译内核用make localmodconfig打底后，体积通常变小的重要原因之一。

CONFIG_PREEMPT和调度相关选项会影响桌面交互流畅度。普通桌面用户可以试试CONFIG_PREEMPT开启，让内核更积极地响应中断和用户交互；服务器场景则往往选择不开或使用自愿抢占，换取更高的吞吐。

还有一些比较偏门的优化，比如CONFIG_CPU_FREQ_DEFAULT_GOVERNOR_PERFORMANCE，把 CPU 频率调节策略默认设为性能模式，适合笔记本外接电源时追求响应速度的场景。这类选项根据自己需求按需调整即可。

8.3 给内核打补丁与 kernel 模块开发的起点

等基本功扎实了，你可以尝试给内核打补丁。常见操作是拿到补丁文件放在源码目录下，然后：

patch -p1 < xxx.patch

补丁来源一般是一些特定硬件支持项目或者安全修复集合。打补丁之前一定要确认补丁与你当前内核源码版本兼容，否则 hunk 匹配失败会留下一堆标记冲突的文件，处理起来比较头疼。如果冲突，先git reset --hard或者重新解压一份源码再打。

如果你对内核模块开发有兴趣，可以直接在源码目录里创建一个小模块练手。写一个最简单的 hello world 模块，参考drivers/misc/下某个模块的 Makefile 形式，逐步理解module_init与module_exit的加载流程。这会让你对“内核是模块化设计”这个说法有更切身的体会，回头看之前配置界面里 M 的含义时会有一种豁然开朗的感觉。

8.4 从源码阅读中获得的回报

走到这一步，你可能会慢慢发现，编译内核最大的收获反而不是那个“更快”“更定制”的新内核，而是你对系统运作模式的直观理解。比如你之前可能会觉得/boot是一堆魔法文件，现在你能清楚说出 vmlinuz 是什么、initrd 是干什么的、System.map 为什么需要存在。日常系统出问题时的排查速度也会有质的变化，因为你对启动流程、驱动加载机制、模块依赖关系都建立起了自己的判断框架。

我个人编译到第三个版本之后，开始明显感受到系统里很多之前含糊的概念都映射到了具体的文件和流程上。比如“模块依赖”这个问题，过去只会用modprobe加个参数，之后则能根据lsmod输出的依赖树快速定位问题根源。这些东西教科书里写一百遍都不如你亲手编译一次内核体会得深。

9. 踩坑记录：那些教程不会告诉你的细节

9.1 编译过程中断后如何安全复用源码目录

内核编译支持增量构建，但有一个前提：源码目录的完整和干净。中断后你想重新编译，直接再跑make就好。但如果中间因为缺依赖等原因出现一些莫名其妙的残留状态，稳妥做法是清理：

make clean

如果连配置都想重置，则执行：

make distclean

注意distclean会删除.config，使用前一定做好备份。我之前因为忘备份又懒得重新配置，多花了一个多小时手工勾选选项，教训深刻。

9.2 编译时和运行时内核版本号的混淆

源码目录里的版本信息来自顶层 Makefile 的VERSION、PATCHLEVEL、SUBLEVEL、EXTRAVERSION。编译出来的内核版本号会体现在uname -r。有些发行版会在这个基础串上附加自己的字符串，比如带-generic后缀。如果你希望自己的内核带一个独特标识，可以在配置菜单里找到Local version - append to kernel release，写入类似-custom的字符串。这样/lib/modules/下的目录名和uname -r输出都会带上这个标识，多版本共存时一眼就能分辨。

我第一次没有设置这个标识，结果uname -r和发行版自带内核版本号完全一致，安装好之后连自己都差点分不清到底进的是哪个内核，折腾了一番才确认。从此我每次编译都会加上独特的本地版本字符串。

9.3 双显卡与特殊外设的驱动简谈

这部分挺多人在意。自编译内核后，NVIDIA 闭源驱动或某些网卡驱动往往不再适配默认的 DKMS 流程。通用解决方案是从驱动供应商提供的源码包里重新编译安装，让驱动模块与你的内核版本重新组合。如果你用的是开源驱动，情况会好很多，因为开源驱动的代码往往已经合入内核主线，只要你配置里勾选了对应硬件支持，就能直接使用。

虚拟机里常见的 VirtualBox 增强功能或 VMware Tools 也有类似问题，重新编译安装一次即可。

9.4 千万别碰的“危险”配置项

最后说几个建议不要随便动的配置。CONFIG_DEBUG_RODATA一类的安全防护项，看起来只是让内核某些段只读，但关掉它可能让系统在运行时出现无法预测的内存写错误。CONFIG_MODULE_SIG签名验证相关项，在实验性环境中可能会让模块加载直接失败。还有CONFIG_SMP，现代系统基本都默认开启，如果你因为想“精简”而关掉它，多核 CPU 就白白浪费了。

这些配置项大多是默认值就足够合理，它们不消耗多大性能，也不会显著拖慢启动，但它们在系统稳定性上扮演着重要角色。

10. 写在最后：内核编译就像组装一台只属于自己的车

整个流程走完，再回头看这些命令，你会发现它们无外乎就是“准备材料—配置—构建—安装”这样一个工程闭环。内核编译的技巧性并不在于某一条命令多神秘，而在于你能不能把每个环节背后的意图理解清楚。能做到这一点，以后不管换什么架构、什么发行版、什么版本的内核，你都可以从容应对。

如果你打算认真玩下去，我还有一个小建议：每成功编译一次，就把你的.config保存下来，并且记录一下这份修改相对于默认配置动了哪些选项、当时是为了解决什么问题。这个笔记习惯在后期会变成你宝贵的经验库。拿我自己来说，我早期随手改的一些选项后来反复踩坑，后来有了记录，一眼就能看出当时的权衡逻辑，少走了很多弯路。

最后再说一句：享受折腾的过程。内核是你机器上离硬件最近的一层软件，你对它做的每一处定制，都会直接反映到系统的行为和性能上。那种自己编译的内核启动完成后，看着登录界面弹出的感觉，和装好一个普通软件是完全不一样的。