简介面向Linux系统运维与嵌入式开发人员的内核裁剪实操文档围绕menuconfig逐项演示如何精简内核功能解决系统体积偏大、启动与响应变慢的问题。文档按步骤清单展开覆盖代码成熟度选项、General setup、可加载模块、块设备层、处理器类型、电源管理以及抢占式内核等关键配置区域并结合System V IPC、ACPI、主板按钮事件、内核抢占等概念说明每个选项的取舍依据避免盲目裁剪导致系统无法启动同时补充了超线程/多核调度、机器检查异常等进阶判断思路帮助读者根据硬件与应用场景选择合适的配置策略。文档不仅列出删除项还解释了为何保留System V IPC与模块加载支持以及ACPI、抢占式调度对系统响应的影响读者按步骤操作后可得到体积更小、运行更流畅的精简内核。资源为单个docx文档大小约80KB已有237人学习浏览。适合刚接触内核编译的初学者逐步实践也可作为后续内核配置与性能调优的速查手册。1. linux内核裁剪它解决什么你该不该动这个手linux内核裁剪的完整过程本质上不是“删代码”而是通过 Kconfig 配置体系把用不到的子系统、驱动、文件系统支持关掉让编出来的内核镜像更小、模块集更干净、启动路径更短同时缩小攻击面。很多人第一次做裁剪以为只要打开 make menuconfig 把不认识的选项全部取消就能成功结果往往是剪完起不来、模块加载报错甚至配置一改就是半天找不回原因。这篇文章会把具体过程按「准备 → 动手 → 编译 → 排查 → 验证」拆开讲覆盖常用命令、关键参数和真实会踩的坑适合三类读者嵌入式开发者想给板子瘦身云镜像维护者想缩小内核体积或者你只是想彻底看懂内核配置体系这篇也能帮你把黑匣子打开。裁剪值不值得做取决于你的交付物。如果你维护的是固定硬件平台裁剪收益非常明显镜像体积能缩小一半以上启动时间能省出可感知的几百毫秒如果你是做通用发行版内核替代那裁剪要克制保留的驱动面反而比体积更重要。动手之前先记住一个判断标准裁掉一个选项前先问它被谁依赖而不是先问它有没有用。2. 裁剪前把源码树和配置体系摸透Kconfig、Kbuild 与 .config 的联动不摸清内核的配置组织方式就直接开裁后面每一步都是玄学。内核源码里每个子目录下都有一个 Kconfig 文件它描述了这个目录下有哪些可配置项、依赖关系和默认值Kbuild 系统在编译时读取你生成的 .config决定哪些目录会被编进去、哪些文件会被编译成内建还是模块。三者联动裁剪的本质就是通过修改 .config 来影响 Kbuild 的编译决策。2.1 Kconfig 语法与菜单树你在 menuconfig 里看到的每一行来自哪里打开 make menuconfig 看到的是一个树状菜单这棵树的每个节点都来自各层目录的 Kconfig 文件。一个典型的配置项长这样config SND tristate Sound card support depends on SOUND help Say Y here to include support for sound cards.tristate 表示这个选项有三种状态Y内建、M编译成模块、N不编译。bool 则只有 Y 和 N。depends on 表示依赖项依赖不满足时这个选项在菜单里不会出现或者直接变灰。select 则是反向依赖表示选中当前项会自动选上某个其他项比如某个驱动 select 了某个通用框架。裁剪时最需要留意的就是 select它会在你没注意的情况下把一堆选项重新打开。理解 Kconfig 语法不用背拿一块真实配置来对照就行。你可以在源码根目录执行 make menuconfig 随便点进去看也可以直接查看某个驱动目录下的 Kconfig 文件。这里给一个积累手感的方法# 在源码树内查看某个具体配置项的来源和依赖 grep -rn config SND sound/ # 查看一个配置项被哪些地方 select grep -rn select SND sound/ drivers/ # 用 menuconfig 的搜索功能直接定位进入菜单后按 / 输入关键字搜索功能是裁剪时最高频的操作没有之一。进入 menuconfig 后按斜杠 / 输入关键词会列出所有匹配项并直接告诉你当前值是 Y/M/N、依赖关系、被谁 select以及选中状态是否有效。学会用 / 搜索光标上下翻菜单的效率差了不止五倍。2.2 最小可裁剪的源码准备与配置基线从 defconfig 出发还是从发行版配置出发裁剪前要有一个干净的源码树而不是在之前编译过的目录里乱改。常见做法是先 make distclean 清理然后确定配置基线。三种基线的选择决定了你后面要走的路基线来源适用场景优点风险厂商 defconfigarch/平台/configs/ 下的 defconfig嵌入式/开发板配置按硬件裁剪过体积小可能缺你想要的文件系统或网络功能发行版配置/proc/config.gz 或 /boot/config-*x86 桌面/服务器硬件兼容面广驱动全选项多、裁剪工作量大tinyconfig从零构建极端最小内核体积最小起点需要逐项加功能调试成本高我一般碰到的裁剪需求70% 是从厂商 defconfig 起步的因为你既然要裁剪说明你手里有一个明确的目标硬件剩下 30% 是在发行版配置基础上做减法比如给云镜像瘦身。从发行版配置起步有个好处它包含了发行版维护者踩过坑后的妥协方案比如某些固件加载路径、ACPI 处理、USB 支持的组合。直接从 tinyconfig 起手更适合学习不适合交付。归档当前使用的配置是裁剪前必须做的一步保证任何时候能退回起点这是你的后悔药# 把当前运行内核的配置导出为基线存档有 CONFIG_IKCONFIG 时 zcat /proc/config.gz /tmp/kernel-baseline.config # 如果 /proc/config.gz 不存在从 /boot 下取 cp /boot/config-$(uname -r) /tmp/kernel-baseline.config # 把基线配置放到源码树让 Kbuild 进入已配置状态 cp /tmp/kernel-baseline.config .config make olddefconfigmake olddefconfig 的作用是让新配置对应当前源码树的 Kconfig 规则自动补全缺失项并重置失效项相当于把旧配置“翻译”成当前源码树能识别的状态。这个命令在导入外部配置后必须执行跳过它直接 make 会得到一堆诡异的编译错误因为它们本来就是配置和源码不匹配的表现。2.3 配置落盘.config、auto.conf 与 autoconf.h 三者的关系和备份习惯裁剪操作最终落在 .config 文件上但你编译时真正被读的不只是它。Kbuild 会基于 .config 生成 include/config/auto.conf供 Makefile 读取和 include/generated/autoconf.h供 C 源码读取。所以当你手动改 .config 后必须重新执行配置同步命令否则源码里看到的宏和实际配置不一致编译出来的东西和你想要的对不上。手动改配置的常用流程是这样# 编辑 .config把 CONFIG_SND 改成 # CONFIG_SND is not set # 然后同步配置而不是直接 make make olddefconfig # 确认关键配置项确实生效 grep CONFIG_SND .config另一个强烈建议养成的习惯是使用 make savedefconfig。这个命令会把当前 .config 中所有非默认值压缩成最小配置生成的 defconfig 文件小、易读、适合放进版本管理。裁剪前后各保存一份配合 diff 就能精确看到你改了什么# 裁剪完成后生成最小配置 make savedefconfig cp defconfig /tmp/kernel-cropped.defconfig # 和基线对比 diff /tmp/kernel-baseline.defconfig /tmp/kernel-cropped.defconfig有了这份 diff你就能回答最常被问的问题“你这次裁剪到底动了什么”。没有它三个月后回头看自己的裁剪记录你会对着上千行 .config 无从下手。3. 动手裁剪从 menuconfig 到命令行的完整过程配置体系摸清楚之后动手裁剪就变成了一个“判断 操作”的重复过程。判断靠的是对目标硬件和启动路径的理解操作靠的是 menuconfig、命令行辅助脚本和配置工具。这一章按执行顺序展开从第一轮菜单操作到模块收敛再到最终编译验证。3.1 用 make menuconfig 做第一轮瘦身必关的子系统与保留项第一轮裁剪建议直接进菜单操作。启动 menuconfig 前先确认你已经装了 ncurses 开发库否则界面起不来# 进入配置界面界面操作核心就两个方向键移动、空格切换状态 make menuconfig进入菜单后按 / 搜索以下常见可裁剪项逐个评估配置项典型场景裁剪建议CONFIG_SND声卡无音频需求的嵌入式/服务器可关CONFIG_BT蓝牙非无线外设场景可关CONFIG_WLAN无线网卡只用有线网络可关CONFIG_INPUT_TOUCHSCREEN无触摸屏可关CONFIG_DRM显示子系统无显示输出可关CONFIG_HWMON硬件监控无传感器需求按需保留第一轮只做“明显的关闭”不要碰任何带 selected by 的项也不要试图一次性关掉几十个。每关一个子系统建议顺手看一眼它下面的依赖说明特别是 help 文本里有没有其他模块会依赖它的提示。GPU、声卡这类子系统往往会被多媒体框架 select关掉后反而破坏了你需要保留的视频编解码功能所以这类项要放到第二轮结合模块列表再处理。import 保留项也有底线。串口驱动CONFIG_SERIAL_8250 等必须保留这是嵌入式设备最重要的调试通道ext4、vfat 等目标根文件系统相关配置保留PCI/ACPI 电源管理基础项保留关掉它们会让硬件探测顺序变得不可预测。第一轮的目标不是一步到位而是先把明显冗余拿掉让 .config 体积下降一个量级。3.2 用 localmodconfig 快速收敛模块集合原理与三条适用前提菜单里手动关选项到后面会越来越累因为驱动项太多判断成本高。这时候可以用内核自带的 localmodconfig 来做一次“模块集合收敛”。它的原理很简单列出当前系统已经加载的所有内核模块集合把集合内模块对应的配置项保留为 M集合外看得到但未加载的模块直接关掉。# 前提当前系统正好是你目标环境的完整运行状态 # 收集当前已加载模块并生成收敛配置 make localmodconfig这个命令执行后会在当前 .config 基础上把所有未加载模块对应的选项关掉操作速度比手动找快几十倍。但它有严格的使用前提三条缺一不可第一你运行 localmodconfig 的机器必须已经完整跑过所有目标硬件路径。比如你的目标设备有 USB 转串口工具但你现在的系统从未插过它那么对应驱动就会被误关。第二lsmod 输出的模块列表必须能代表正常运行集如果你在精简系统里执行这个命令结果会把本应保留的驱动裁掉。第三模块之间的依赖链会被自动保留但如果某功能以 Y 方式内建且当前未使用localmodconfig 不会处理它你还是得靠 menuconfig。执行完后照例跑 make olddefconfig再 diff 一次看看收敛范围是否符合预期。localmodconfig 不是万能药它是“用运行事实代替人工判断”的加速器。我习惯先手动做一轮明显裁剪再跑 localmodconfig 兜底最后回到 menuconfig 检查几个关键项三层下来配置基本干净了。3.3 裁剪后的编译与尺寸核对make 的并行参数和 Image/vmlinux 的体积检查配置定稿后进入编译阶段。内核编译和普通项目不太一样先看常用命令# 并行编译-j 参数按 CPU 核数来 make -j$(nproc) bzImage # 单独编译模块供后续安装到目标环境 make -j$(nproc) modules # 如果你要完整安装到当前系统才执行 modules_install sudo make modules_install-j 后面的数字不是越大越好。内存小的机器开满核会触发 OOM实际经验是取 nproc 的一半到三分之二之间更稳妥比如 8 核机器用 -j616 核用 -j10编译内核时每个编译单元吃内存不小翻车概率高。编译成功后重点看两个产物arch/x86/boot/bzImagex86 平台是实际引导用的压缩内核vmlinux 是未压缩的 ELF前者决定你引导时读多大数据量后者反映代码段实际规模。# 查看镜像体积 ls -lh arch/x86/boot/bzImage ls -lh vmlinux # 查看模块集合体积 du -sh /lib/modules/$(uname -r) # 按大小排序找出最大的模块判断是否还有裁剪空间 find /lib/modules/$(uname -r) -name *.ko -exec ls -lh {} \; | sort -k5 -h | tail -20第一轮裁剪的成果在 bzImage 体积上通常立竿见影常见情况是从十几 MB 降到 5 MB 左右。模块目录体积则更依赖 localmodconfig 的收敛效果如果你的基线是发行版全量模块从几百 MB 降到几十 MB 很正常。如果 bzImage 体积变化不大说明你关掉的选项大多是模块而不是内建设备这时候要重点看模块列表而不是继续盯着镜像体积。4. 内核裁剪避坑剪完起不来、模块加载失败与配置失效的排查路径裁剪最痛苦的不是操作过程而是剪完之后的启动失败。这类问题没有统一报错故障现象五花八门但根因高度集中。这一章把最容易踩的五个坑按现象、原因、解决三个维度拆开每条都可以直接对着你的 dmesg 排查。4.1 驱动被剪但设备表还在启动日志里的 deferred probe 现象与处理现象裁剪后的内核能启动但原来能用的外设不工作dmesg 里频繁出现 platform ... deferred probe 或 -EPROBE_DEFER 错误。原因内核驱动和设备驱动的注册是异步的某个驱动的 probe 依赖另一个驱动先完成比如一个 I2C 触摸屏驱动依赖 I2C 控制器先就绪。当你裁剪时把依赖链上游的某个驱动关掉了下游驱动的 probe 就会反复延迟最终放弃。配置文件里看不到直接的因果关系因为它依赖的是设备树或 ACPI 表提供的兼容信息而不是 Kconfig 的 depends on。解决先定位 deferred probe 的具体设备再反查它需要的上游驱动。以内核日志为例# 查看 deferred probe 状态列表 ls /sys/kernel/debug/devices_deferred # 查具体设备的依赖信息以 i2c 设备为例 dmesg | grep -i deferred probe # 到 menuconfig 里搜索对应的上游驱动名比如 pinctrl、regulator、clock make menuconfig大多数情况下被裁掉的是某个 pinctrl 或时钟驱动。解决办法不是把整个子系统打开而是按需打开那个具体的厂商驱动选项。如果你分不清设备对应哪个驱动可以先用未裁剪的基线内核确认设备节点名再在裁剪内核里对比缺失的驱动目录。4.2 模块与内建交叉引用unknown symbol 与未导出的符号表现象模块能编译成功但 modprobe 时报 unknown symbol 或 -EINVALdmesg 里有 module ... has no symbol version 之类的提示。原因内核模块几乎都依赖内核导出的符号比如某个函数只在某个配置项开启时才导出。裁剪时如果关闭了导出该符号的配置项但保留了依赖它的模块选项编译阶段不报错运行加载时符号解析失败。这类问题在 lsmod 收集不完整的 localmodconfig 场景下尤其常见。解决用 modinfo 查看模块依赖和符号要求回到配置里打开对应的符号导出项。# 查看模块信息和依赖 modinfo module_name # 搜索模块引用的关键符号对应的配置项 grep -rn EXPORT_SYMBOL.*symbol_name /path/to/kernel/source/ # 打开对应配置后重新编译模块 make menuconfig make modules -j$(nproc)判断这类问题时不要试图手动在 .config 里加回某个 CONFIG_ 项然后直接编译你必须确保依赖项完整。建议查找该符号所在的 Kconfig 项后在 menuconfig 里重新打开它并保存然后跑 make olddefconfig 让依赖自动补全。4.3 initramfs 与根文件系统不匹配裁剪后找不到根设备的常见原因现象启动卡在 VFS: Unable to mount root fs on unknown-block或者提示不对根文件系统类型直接进入 initramfs 紧急 shell。原因裁剪时把根文件系统所在磁盘的控制器驱动或文件系统驱动关掉了。常见误伤对象是 NVMe 控制器、SATA AHCI、USB 存储驱动以及 ext4 之外的根文件系统格式。另一个隐蔽原因是 initramfs 里面存放的模块列表来自旧内核的 modules.dep新旧内核模块版本对不上导致 initramfs 加载不到正确驱动。解决先确认根文件系统所在设备类型再检查对应驱动配置# 确认根设备是 NVMe 还是 SATA 还是 USB lsblk # 检查关键配置项是否保留 grep -E CONFIG_NVME|CONFIG_ATA|CONFIG_USB_STORAGE|CONFIG_EXT4_FS .config # 重新生成 initramfs让驱动列表和新内核匹配 sudo update-initramfs -u -k your-kernel-version如果你用的是 dracut 体系对应命令是 sudo dracut --force。这一步经常被人忽略以为裁剪内核跟 initramfs 无关实际上 initramfs 里打包的模块列表就是按旧内核配置生成的。裁剪后不重建 initramfs驱动加载顺序和模块集合全部错位表现就是找不到根设备。4.4 固件文件缺失保留驱动但缺少 firmware设备静默失败现象设备在 dmesg 里没有任何报错但就是不出来或者明确提示 firmware: failed to load。原因有些驱动特别是网卡、GPU、DSP在 probe 时需要加载固件文件固件不在内核源码树里而在 /lib/firmware 下。裁剪内核时你把 CONFIG_FW_LOADER 关了或者没把固件文件路径编进内核驱动就静默失败。反过来如果驱动被裁剪固件加载代码还在日志里也会出现 failed to load 的误导信息。解决第一步区分是驱动问题还是固件问题。# 查看驱动声明的固件文件 modinfo driver_name | grep firmware # 检查固件文件是否存在 ls -lh /lib/firmware/firmware-name # 如果驱动已经裁剪先回 menuconfig 确认它的状态 # 如果驱动在但固件缺失把固件文件放到 /lib/firmware 对应路径内核支持把固件直接编入镜像对应配置项是 CONFIG_EXTRA_FIRMWARE。嵌入式裁剪场景我喜欢在 .config 里把目标固件路径写死这样可以减少对根文件系统的依赖。但要注意EXTRA_FIRMWARE 只在开启 CONFIG_FW_LOADER 时生效两者必须同时保留。4.5 配置碎片化没有版本管理裁剪就是一次性操作现象裁剪到第三轮时发现第一轮关掉的某个配置又莫名其妙地变回了 Y整个 .config 混乱到无法维护。原因配置之间通过 select、condition 等隐式依赖互相牵连你在 menuconfig 里关闭一个项可能顺手把另一处依赖它的选项也改变了而你根本没有察觉。更常见的是手动编辑 .config 后没跑 make olddefconfig第二次 make menuconfig 时被 Kbuild 静默修正。解决把配置当作代码来管。每次有效裁剪后做三件事备份 .config、生成 savedefconfig、记录 diff。一套顺手的方式是建一个配置管理目录mkdir -p /tmp/kernel-config-history # 每次裁剪后的固定动作 cp .config /tmp/kernel-config-history/config-$(date %Y%m%d-%H%M%S) make savedefconfig cp defconfig /tmp/kernel-config-history/defconfig-$(date %Y%m%d-%H%M%S)有了这些存档任何一轮裁剪出错都能快速二分定位先对比最近两次 defconfig 的差异看是哪个配置项导致的行为变化再决定回退还是修正。我自己吃过一次大亏裁剪到第三轮时一次误操作把 CONFIG_DEVTMPFS 关了系统起来后 /dev 下面全是空的排查了大半天才通过 defconfig 对比找到原因。从那之后固定执行这个备份流程再没在配置回滚上浪费过时间。5. 裁剪的验证与进阶启动时间、体积回归和自动瘦身手段验证比裁剪本身更重要。裁剪的效果不是“能起来”就算成功而是要有可量化的指标还要有对比基线。三类指标最值得记录。第一个是镜像体积。bzImage 大小直接体现在引导加载时间上vmlinux 大小反映了代码段规模。第二个是模块集合体积和数量这决定了根文件系统特别是 initramfs里要放多少东西。第三个是启动耗时用 systemd-analyze 或内核 printk 时间戳来测systemd-analyze systemd-analyze blame | head -20 # 更细的时段分布看内核初始化时间占比 dmesg | grep kernel booted把裁剪前后的三组数据记下来才是这次工作的完整交付物。光说“我剪小了”没有说服力拿出体积、模块数和启动时间的变化项目评审才过得去。配置审计用内核自带的 diffconfig 脚本最方便。它比普通 diff 更懂配置语义能自动把同一配置项的新旧值合并成有效变更行# 对比两个配置文件只显示有变化的项 scripts/diffconfig /tmp/kernel-baseline.config .config进阶手段方面如果你想把裁剪玩到极致可以从 tinyconfig 起步做白名单式配置先全部关掉再把目标硬件和文件系统需要的项逐个加回去。这条路前期成本高但产物最干净适合学习 Kconfig 依赖关系和做最小系统的场景。内核源码里还有 scripts/kconfig/merge_config.sh适合把碎片化的配置片段合并进基线配置里做自动化裁剪流程我一般配合脚本做每日构建时的配置回归测试。另一个常被忽略的优化是内核压缩方式。CONFIG_KERNEL_XZ 比默认的 gzip 通常能再缩小 20% 到 30%代价是启动解压时间变长没有通用最优解压到你的板子能接受的平衡点即可。我做内核裁剪这几年最大的教训就是开头那句判断标准先查依赖再动选项裁剪不是删文件是给内核做减法手术每一刀都得知道它切在哪里。养成裁剪前归档、裁剪后对比的习惯之后这套流程基本不再翻车。希望帮到你下次剪内核先 save 一份 defconfig 再动手。本文还有配套的精品资源点击获取