简介基于 Docker 与 QEMU 构建的 Linux 内核实验环境主要面向内核学习者、开发者和测试人员用来解决本地交叉编译环境搭建繁琐、虚拟机启动缓慢等痛点。压缩包共 368 个文件大小只有 2.53MB其中有 84 个 Shell 脚本、59 个 Makefile、52 个 Markdown 文档还包含补丁、配置文件、C 源码、汇编和设备树文件等。脚本负责环境准备、镜像构建与一键启动Makefile 支撑多个内核版本的编译和配置Markdown 文档给出操作步骤与实验说明补丁文件则用于修复问题或增加特性。目前已有 131 人学习下载适合快速搭建实验台并反复验证内核改动。资源内收录了 Linux v2.6.10、v2.6.11.12 等版本的内核配置覆盖 versatilepb、malta、virt 等 QEMU 模拟目标同时提供 gdbinit 调试配置、ldt/misc_loop 驱动测试例程和 dockerfile可以直接启动实验环境、跟踪内核执行流程、验证驱动逻辑配套文档也能引导完成从环境初始化到内核编译的完整路径。1. 装了删、删了装的内核环境这次一次跑通了做内核驱动开发和调试的人大概率都经历过类似的尴尬为了验证一个ldt.c或者dio.c的补丁要专门准备一台物理机或者一个完整的虚拟机编译一次内核等十分钟算快的启动到一半卡在某个驱动上又得从头来想对比2.6.10和2.6.11.12两个版本的行为差异得维护两套工具链、两套根文件系统最后磁盘空间和耐心一起耗尽。这套基于Docker加QEMU的Linux内核实验环境就是为了终结这种状态而生的——它把内核编译、启动、调试、测试全部收进容器里宿主机只留一个Docker和几个命令行十分钟内就能拉起一个可随时销毁的内核实验台。无论你是刚学操作系统课程的学生还是需要在不同内核版本间快速切换验证的工程开发者这套方案都能让“装环境”不再是阻碍你碰内核的那道坎。2. 环境选型为什么是Docker QEMU以及要先看清的三个版本真相2.1 这套方案的核心设计思路先理解这套环境为什么这么组合。内核实验最折腾人的三件事是编译环境依赖多、启动需要完整引导链、调试时要随时重置系统状态。Docker解决的是第一件——它把交叉编译工具链、必备的库、构建脚本全部固定在一个镜像里任何一台装了Docker的机器都能复现一模一样的编译环境QEMU解决的是后两件——它模拟出一台完整的机器内核在这里面启动、崩溃、被GDB打断都不影响宿主机而且快照功能让你可以在任意时刻回滚系统状态。项目里那份Makefile.linux_v2.6.10和Makefile.linux_v2.6.11.12就是这套思路的落地点。它们不是简单的make命令封装而是把整个流程串了起来从准备根文件系统、生成磁盘镜像到调用QEMU启动、再把GDB挂上去全部由Makefile目标驱动。你只需要记住make加特定参数剩下的交给脚本。2.2 版本选择的三个关键点内核版本、架构、磁盘镜像这套环境里最先要认清的是内核版本选择。项目提供了2.6.10和2.6.11.12两个版本——2.6.x系列是Linux内核发展中承上启下的一个分支很多经典的驱动模型和内核API在这个时期定型。选择学习这个版本并不是因为它最强大而是因为它足够简单、足够经典没有后来那么多编译选项和子系统干扰看代码时能很快找到主线。要注意2.6.10和2.6.11.12之间的驱动API是有差异的项目把两个Makefile分开维护就是为了让你能明确感知这种差异而不是混在一起糊涂学。第二个关键是架构。项目里有个config.aarch64.virt.broken文件一看名字就知道这是个“坑位”——它在告诉你aarch64架构下的配置曾经出过问题。我一般建议新手老老实实先跑x86_64模式ARM64的virt平台配置等你把x86_64的流程跑通、理解了设备树和中断控制器这些概念后再折腾不迟。第三个关键是磁盘镜像。这套环境用的是块设备镜像而非网络文件系统这就意味着你在内核里mount、mkfs这些操作都是真实作用于一块虚拟磁盘上的实验结果可以被持久化保存。对比直接用initramfs的方式块设备镜像更贴近真实开发场景。2.3 Docker镜像准备的常规做法与推荐参数环境里需要跑起来的前置条件就一个Docker能正常运行。我一般会先用docker version确认客户端和服务端都在线然后拉取一个带完整构建工具链的基础镜像。docker pull ubuntu:22.04 docker run -it --name linux-lab \ -v /home/$(whoami)/linux-lab:/workspace \ --cap-addSYS_ADMIN \ ubuntu:22.04 /bin/bash这个命令有几个参数值得说清楚。-v把宿主机的linux-lab目录挂载进容器的/workspace这样内核源码和编译产物都在宿主机的磁盘上容器即使销毁了源码也还在--cap-addSYS_ADMIN是给容器内QEMU使用某些系统调用权限用的——不加这个QEMU在用户态模拟某些设备时会因为权限不足直接退出。也可以加上--device/dev/kvm来启用硬件加速但如果你没有KVM环境或不想折腾嵌套虚拟化先别加。进了容器之后要装的依赖比较常规但容易漏一样就会在编译时翻车apt-get update apt-get install -y build-essential flex bison libncurses-dev \ qemu-system-x86 qemu-utils gdb-arm-none-eabi \ make wget cpio bc dwarves这里flex和bison是内核构建的语法解析器工具libncurses-dev用于make menuconfig的图形界面显示bc是内核编译时会调用的小型计算器dwarves用于生成BTF调试信息——最容易被忽视的就是bc和cpio缺了前者编译到某个阶段会报找不到bc命令的奇奇怪怪错误缺了后者initramfs根本生成不了。3. 从Makefile到第一个启动的内核完整落地步骤3.1 拿到项目文件并理解Makefile目标结构假设你现在已经把项目文件下载到了本地目录里能看到若干个.c文件、Makefile.*和gdbinit.auto。核心操作对象是那两个带版本号的Makefile它们定义了不同内核版本的不同构建流程。直接执行make -f Makefile.linux_v2.6.10 list能列出这个Makefile支持的所有目标这一步强烈建议先做——它能帮你快速摸清这套环境的操作入口。不过要注意这份Makefile不会是开箱即用的——它内部引用了一个变量指向你的源码目录。需要打开Makefile.linux_v2.6.10看一眼头部找到类似LINUX_SRC或KERNEL_DIR的变量定义把它改成你内核源码实际所在的路径。这是最常规、也最容易让人卡住的一步。# Makefile.linux_v2.6.10 片段 LINUX_SRC : /workspace/linux-2.6.10 ARCH : x86_64 CROSS_COMPILE :注意v2.6.10这个版本年代久远直接用gcc 12去编译大概率会报一堆“代码与编译器不兼容”的错误。我一般建议先在容器里装一个老版本的编译器链比如gcc-9然后通过CROSS_COMPILE/usr/bin/gcc-9-来指定。2.6.11.12虽然晚了一个小版本其表现也好不到哪里去——对这些老内核来说越老的编译器越安全。3.2 编译内核参数选择与常见失败点配置内核有两种路线直接用Makefile里自带的默认配置适合快速验证或自己执行make oldconfig交互式调整适合深入实验。我自己的习惯是先用默认配置把整个链路走通确保QEMU能启动、能看到内核日志再回头来改配置做驱动实验。# 在容器内执行假设源码已解压到 /workspace/linux-2.6.10 cd /workspace/linux-2.6.10 make mrproper # 清理旧配置避免之前编译残留干扰 make x86_64_defconfig make -j$(nproc) bzImage这里make x86_64_defconfig会生成一个合理的基础x86_64配置-j$(nproc)可以充分利用CPU核心数加速编译。但注意老内核与高版本编译器存在一个极常见的坑——编译中报code model kernel does not support或者一堆implicit declaration的warning最终转error。可以加KCFLAGS-Wno-error或者直接改Makefile里-Werror为-Wno-error没必要卡在这里。等编译结束后确认一下arch/x86/boot/bzImage文件是否生成。这个文件就是内核本体后续QEMU启动会用到它。3.3 制作根文件系统和磁盘镜像内核要启动光有bzImage还不够需要一个可挂载的根文件系统rootfs。这里的选择有很多可以是BusyBox最小集也可以是完整的Ubuntu根文件系统。对于快速实验BusyBox足够而且写入极小。项目脚本里应该有对应的目标但它的逻辑同样不难理解# 先制作一块512MB的虚拟磁盘并格式化为ext4 dd if/dev/zero of/workspace/rootfs.img bs1M count512 mkfs.ext4 /workspace/rootfs.img # 把磁盘挂到临时目录并拷贝busybox等最小环境 mkdir -p /mnt/rootfs mount -o loop /workspace/rootfs.img /mnt/rootfs cd /mnt/rootfs mkdir -p bin sbin etc proc sys dev lib cp /bin/busybox bin/ bin/busybox --install bin/ cp /usr/bin/gdb bin/ # 容器里装好的gdb拷进rootfs方便后续内核态调试 umount /mnt/rootfs这里有一个非常容易踩的细节拷贝到rootfs里的busybox必须是静态编译的版本动态链接的busybox离开了容器环境会因找不到动态库而启动失败。检查可以用file bin/busybox | grep static如果显示dynamically linked就去apt-get install busybox-static换取静态版。3.4 用QEMU启动三个关键参数决定成败现在到了最让人兴奋的一步——用QEMU把编译好的内核和根文件系统一起跑起来。通常是Makefile里已经封装好了QEMU启动命令但你要理解每个参数在干什么出了问题才有排查方向。qemu-system-x86_64 -kernel /workspace/linux-2.6.10/arch/x86/boot/bzImage \ -drive file/workspace/rootfs.img,formatraw,ifide \ -append root/dev/sda rw consolettyS0 \ -nographic -no-reboot-kernel指定内核镜像路径-drive把rootfs.img作为IDE硬盘接入——注意老内核对应/dev/sda使用的是IDE驱动所以参数里用了ifide而不是ifvirtio-append里的consolettyS0把内核日志输出到串口配合-nographic把串口重定向到当前终端。这样你就能直接在当前终端看到内核的启动日志而不用去点一个可能不渲染文本的图形窗口。-no-reboot是为了让内核panic后直接退出QEMU而不是无限重启循环这对观察内核崩溃现场特别重要。执行这条命令后如果一切正常你会看到内核逐条打印启动信息最后停在/ #这个BusyBox shell提示符。到这一步你的第一个“可实验内核环境”就算跑通了。4. 深入调试与扩展利用gdbinit.auto和驱动示例代码4.1 gdbinit.auto的玩法一条命令挂起内核这套环境里最有价值的就是那份gdbinit.auto。用纯命令行调试内核最痛苦的是手动设置符号文件、连接远程端口、加载内核模块这一串动作而这份脚本把这一切自动化了。它的内容本质上是一系列GDB命令。# gdbinit.auto 内容示意 target remote :1234 file /workspace/linux-2.6.10/vmlinux set architecture i386:x86-64 add-auto-load-safe-path /workspace/linux-2.6.10/ break start_kernel continue用法是QEMU先启动并停在等待调试器接入的状态然后在另一个终端启动GDB并自动加载这份脚本。用-S参数让QEMU在启动时暂停CPU等待调试器以及-s让QEMU在TCP 1234端口开放GDB远程调试协议这两个QEMU参数要配合起来# 终端1启动QEMU并等待GDB介入 qemu-system-x86_64 -kernel /workspace/linux-2.6.10/arch/x86/boot/bzImage \ -drive file/workspace/rootfs.img,formatraw,ifide \ -append root/dev/sda rw consolettyS0 nokaslr \ -nographic -no-reboot -s -S # 终端2进入容器执行GDB gdb-multiarch -x /workspace/gdbinit.auto这里-s和-S是小写单字母分别是-gdb tcp::1234和-S的快捷写法。设置nokaslr很重要——如果内核启用了内核地址空间布局随机化KASLRGDB下断点的地址跟实际代码运行地址对不上断点根本不会命中这是新手最容易困惑的“为什么break start_kernel毫无反应”的原因。脚本里那个break start_kernel值得你多玩几次。start_kernel是内核启动的C语言入口点在这里断下来之后你可以单步执行 查看各种初始化阶段的全局变量状态对理解内核启动流程非常有帮助。4.2 驱动示例代码ldt.c、dio.c与misc_loop_drv.c怎么用项目里带了几个.c文件分别是ldt.c、dio.c、ldt_plat_drv.c和misc_loop_drv.c——从文件名能看出它们的定位有些是内核模块示例有些是设备驱动骨架。这些文件的价值在于给你一份可以直接编译加载进实验内核的“靶子”用来练习模块编写和调试技巧。以内核模块为例编译方式与普通内核模块一致但要在Makefile中指定内核源码目录和架构。把下面这个Makefile放在与你模块相同目录obj-m misc_loop_drv.o KERN_DIR : /workspace/linux-2.6.10 ARCH : x86_64 CROSS_COMPILE : all: make -C $(KERN_DIR) M$(PWD) ARCH$(ARCH) CROSS_COMPILE$(CROSS_COMPILE) modules clean: make -C $(KERN_DIR) M$(PWD) ARCH$(ARCH) clean执行make后得到misc_loop_drv.ko通过scp或者mount --bind方式把它拷贝到rootfs.img挂载目录中再在QEMU启动的内核里执行insmod misc_loop_drv.ko加载。如果模块代码里有printk日志会直接打到内核的环形缓冲里用dmesg查看输出。值得说明的是这几个示例并不是随意堆出来的——misc_loop_drv.c对应一个杂项设备驱动的完整模板ldt.c应该与系统的LDT局部描述符表机制相关可作为深入x86分段机制的切口。它们的共同点是都不依赖外部第三方库纯内核API就能编译通非常适合练习“读代码→改代码→加载模块→观察行为”这条内核学习主循环。4.3 从QEMU到真机的调试思维迁移这套环境能让你在十几秒内反复启动/崩溃内核这撞击试验里每一个被窗口关闭的panic现场累积的都是对内核异常处理机制的直觉。许多内核调试技巧比如在驱动代码里加dump_stack()看调用栈、用/proc/modules确认模块加载状态在这套虚拟环境里都可以得到与真实机器高度相似的反馈。区别只是虚拟化的中断控制器和真实硬件的时序略有差异但这对于学习“OS原理”层面完全够用。5. 避坑与排查那些反复折磨人的环境细节5.1 编译阶段老内核与新高版本工具链的兼容困局现象在Ubuntu 22.04容器里make执行到一半屏幕上刷出一堆以arch/x86/entry/entry_64.S开头的汇编错误或者报unsupported instruction之类的信息。原因Linux 2.6.10发布时gcc还停留在4.x时代。新版gcc对老代码的隐式声明要求更严格同时对x86指令集的描述也演变了很多老汇编代码在新汇编器下部分指令已不合法。这属于典型的“版本断层”问题不是代码本身有缺陷。解决我在容器里安装了gcc-9并修改Makefile中CROSS_COMPILE : /usr/bin/gcc-9-让编译走老工具链。这一改大量莫名其妙的报错直接消失。如果是ARM架构的实验同理要关注binutils和libc的版本优先选择2.25附近的老版本工具链。也可以尝试使用项目Makefile里自带的工具链路径变量在容器中建立软链接指到实际安装版本这样不改Makefile也能生效。5.2 启动阶段内核起来了但登录不了shell现象QEMU启动后看到内核日志正常输出但最后停在Kernel panic - not syncing: No init found.或者卡在init: cannot execute /bin/sh。原因根文件系统内容不完整或init程序缺失。BusyBox如果没被正确安装到/bin/sh位置或/sbin/init指向错误内核便找不到可以执行的顺序。还有另一种情况是/dev/console这个设备节点缺失导致内核无法打开标准输入输出。解决重新挂载rootfs.img使用busybox --install -s bin/强制加符号链接方式创建所有工具链并确认/bin/sh存在。此外手动建常用设备节点mknod -m 666 /mnt/rootfs/dev/console c 5 1 mknod -m 666 /mnt/rootfs/dev/null c 1 3 mknod -m 666 /mnt/rootfs/dev/ttyS0 c 4 64设备节点是内核与硬件交互的中介删掉/漏掉一个对应的功能就会异常。console节点常在启动阶段被内核要求提前存在新手常因忘记这一步而卡壳。5.3 调试阶段添加断点后内核不触发或直接失去响应现象在start_kernel下断点并执行continue之后GDB侧一直显示“Program received signal SIGTRAP”但被调试的内核似乎冻结或者继续跑飞了断点无法命中。原因多半是KASLR导致符号与地址对不上或者gdbinit.auto里的file指向了vmlinux而QEMU加载的是bzImage两者代码段地址存在偏移。解决在-append参数中显式添加nokaslr并确认GDB加载的vmlinux与QEMU加载的bzImage是同一build产物——它们的调试信息必须同源。具体检查file vmlinux应显示带debug信息的ELF可执行文件而不是被strip过的在GDB里执行info address start_kernel输出的地址应与nm vmlinux | grep start_kernel一致。若不一致考虑是否是CONFIG_RANDOMIZE_BASE未关闭导致编译期地址随机化此时需要改内核配置并重编。5.4 资源限制QEMU进程崩溃或容器内无法创建嵌套虚拟化现象容器内部直接执行qemu-system-x86_64时报Failed to open /dev/kvm或者运行几分钟后QEMU进程被OOM杀死。原因容器默认没有/dev/kvm设备节点且未限制内存的大容器里QEMU默认分配虚拟机内存可能过大触发了宿主机或容器的内存限制。这不是QEMU本身的问题而是嵌套虚拟化权限与资源配额没配好。解决有条件的话在docker run时加--device/dev/kvm --group-add$(stat -c %g /dev/kvm)让容器直接对接KVM设备。同时给QEMU加-m 512限制虚拟机内存为512MB这已经把老内核运行空间给得很宽裕。若容器平台不支持KVM透传就老实把-enable-kvm去掉保持纯软件模拟。此时启动会比KVM加速慢30%~50%但稳定性没问题。6. 验证跑通从启动日志到驱动模块加载的全流程检查环境装好、跑起来只是第一步真正能搬上学习台面还需要一套可重复的验证流程——确认内核、rootfs和调试链路每一项都实际可用。以下的验证方法我每次都强制自己完整走一遍大概一首歌的时间就能排查掉九成的环境隐患。先做一个快速启动冒烟测试。用系统自带的默认配置启动QEMU观察日志序列。健康的启动过程会依次出现实模式引导信息、Linux version开头的内核版本号、内存探测行大约在500MB左右、各个子系统初始化Calibrating delay loop这种计算行出现在启动中段最后看到VFS: Mounted root (ext4 filesystem) on device 0:7或类似挂载成功的日志并在约两秒后进入/ #提示符。在这个提示符下执行uname -a确认内核版本与你编译的v2.6.10或v2.6.11.12完全一致一个字符都不能差。这一步就过滤掉了那种“内核编译成功但QEMU实际加载的是另一个默认内核”的错乱情况。接着验证模块编译链。以项目里的misc_loop_drv.c为例模块能成功编译是基础更重要的是编译产物能被当前内核接受。在内核里insmod misc_loop_drv.ko后马上执行lsmod看模块是否出现在已加载列表里再执行dmesg | tail看驱动的初始化打印——一个规范的misc驱动模板会在probe函数里打出设备注册信息。如果insmod报Invalid module format这类错误第一反应不是怀疑驱动代码而是确认模块编译时的内核版本与运行内核是否完全同源——这是最容易埋头乱找一小时但实际答案很简单的地方。然后做一次GDB链路验证。这是判断整套环境有没有真正具备“内核调试能力”的分水岭。流程是以-s -S启动QEMU用gdb-multiarch -x gdbinit.auto连上在start_kernel下断点并continueGDB应当在秒级内命中该断点并暂停。此时执行bt能看到一组包括start_kernel在内的调用栈再用info registers验证寄存器组不是全零而是真实存在初始化现场。如果能走到这一步说明QEMU的远程调试协议、GDB的符号加载、KASLR关闭都同时生效——这套环境已经具备了专业内核调试工具链的基本盘。最后是rootfs读写与持久化验证。在QEMU的/ #提示符下创建一个文件然后干净关机重启比如touch /test_write reboot。重启后再次挂载rootfs执行ls /test_write确认文件还在就证明块设备镜像的读写持久化链路是通的。这一步看似多余但它决定了你能不能在内核里安装编译工具、保存实验产物——整个环境下半场的工作方式都建立在这上面。如果不做这个验证往往会突然发现rootfs其实是以只读方式挂载的或者写入只落在临时内存层等你折腾了半小时准备保存代码时全部丢失那种感觉真的是欲哭无泪。走完这四条验证线整套环境就算经受过一次完整体检了。从那以后我每次搭建内核实验环境都会强制走一遍这套流程——上面多数“玄学”问题都是因为当初跳过了其中某一步。希望这次记录能帮你少绕几圈弯路把精力留给你真正想研究的内核代码里。本文还有配套的精品资源点击获取 
长河君 · 2026/10/19 14:33:22 · 阅读 1.2k Docker+QEMU构建Linux内核实验环境：编译调试一站式方案
简介基于 Docker 与 QEMU 构建的 Linux 内核实验环境主要面向内核学习者、开发者和测试人员用来解决本地交叉编译环境搭建繁琐、虚拟机启动缓慢等痛点。压缩包共 368 个文件大小只有 2.53MB其中有 84 个 Shell 脚本、59 个 Makefile、52 个 Markdown 文档还包含补丁、配置文件、C 源码、汇编和设备树文件等。脚本负责环境准备、镜像构建与一键启动Makefile 支撑多个内核版本的编译和配置Markdown 文档给出操作步骤与实验说明补丁文件则用于修复问题或增加特性。目前已有 131 人学习下载适合快速搭建实验台并反复验证内核改动。资源内收录了 Linux v2.6.10、v2.6.11.12 等版本的内核配置覆盖 versatilepb、malta、virt 等 QEMU 模拟目标同时提供 gdbinit 调试配置、ldt/misc_loop 驱动测试例程和 dockerfile可以直接启动实验环境、跟踪内核执行流程、验证驱动逻辑配套文档也能引导完成从环境初始化到内核编译的完整路径。1. 装了删、删了装的内核环境这次一次跑通了做内核驱动开发和调试的人大概率都经历过类似的尴尬为了验证一个ldt.c或者dio.c的补丁要专门准备一台物理机或者一个完整的虚拟机编译一次内核等十分钟算快的启动到一半卡在某个驱动上又得从头来想对比2.6.10和2.6.11.12两个版本的行为差异得维护两套工具链、两套根文件系统最后磁盘空间和耐心一起耗尽。这套基于Docker加QEMU的Linux内核实验环境就是为了终结这种状态而生的——它把内核编译、启动、调试、测试全部收进容器里宿主机只留一个Docker和几个命令行十分钟内就能拉起一个可随时销毁的内核实验台。无论你是刚学操作系统课程的学生还是需要在不同内核版本间快速切换验证的工程开发者这套方案都能让“装环境”不再是阻碍你碰内核的那道坎。2. 环境选型为什么是Docker QEMU以及要先看清的三个版本真相2.1 这套方案的核心设计思路先理解这套环境为什么这么组合。内核实验最折腾人的三件事是编译环境依赖多、启动需要完整引导链、调试时要随时重置系统状态。Docker解决的是第一件——它把交叉编译工具链、必备的库、构建脚本全部固定在一个镜像里任何一台装了Docker的机器都能复现一模一样的编译环境QEMU解决的是后两件——它模拟出一台完整的机器内核在这里面启动、崩溃、被GDB打断都不影响宿主机而且快照功能让你可以在任意时刻回滚系统状态。项目里那份Makefile.linux_v2.6.10和Makefile.linux_v2.6.11.12就是这套思路的落地点。它们不是简单的make命令封装而是把整个流程串了起来从准备根文件系统、生成磁盘镜像到调用QEMU启动、再把GDB挂上去全部由Makefile目标驱动。你只需要记住make加特定参数剩下的交给脚本。2.2 版本选择的三个关键点内核版本、架构、磁盘镜像这套环境里最先要认清的是内核版本选择。项目提供了2.6.10和2.6.11.12两个版本——2.6.x系列是Linux内核发展中承上启下的一个分支很多经典的驱动模型和内核API在这个时期定型。选择学习这个版本并不是因为它最强大而是因为它足够简单、足够经典没有后来那么多编译选项和子系统干扰看代码时能很快找到主线。要注意2.6.10和2.6.11.12之间的驱动API是有差异的项目把两个Makefile分开维护就是为了让你能明确感知这种差异而不是混在一起糊涂学。第二个关键是架构。项目里有个config.aarch64.virt.broken文件一看名字就知道这是个“坑位”——它在告诉你aarch64架构下的配置曾经出过问题。我一般建议新手老老实实先跑x86_64模式ARM64的virt平台配置等你把x86_64的流程跑通、理解了设备树和中断控制器这些概念后再折腾不迟。第三个关键是磁盘镜像。这套环境用的是块设备镜像而非网络文件系统这就意味着你在内核里mount、mkfs这些操作都是真实作用于一块虚拟磁盘上的实验结果可以被持久化保存。对比直接用initramfs的方式块设备镜像更贴近真实开发场景。2.3 Docker镜像准备的常规做法与推荐参数环境里需要跑起来的前置条件就一个Docker能正常运行。我一般会先用docker version确认客户端和服务端都在线然后拉取一个带完整构建工具链的基础镜像。docker pull ubuntu:22.04 docker run -it --name linux-lab \ -v /home/$(whoami)/linux-lab:/workspace \ --cap-addSYS_ADMIN \ ubuntu:22.04 /bin/bash这个命令有几个参数值得说清楚。-v把宿主机的linux-lab目录挂载进容器的/workspace这样内核源码和编译产物都在宿主机的磁盘上容器即使销毁了源码也还在--cap-addSYS_ADMIN是给容器内QEMU使用某些系统调用权限用的——不加这个QEMU在用户态模拟某些设备时会因为权限不足直接退出。也可以加上--device/dev/kvm来启用硬件加速但如果你没有KVM环境或不想折腾嵌套虚拟化先别加。进了容器之后要装的依赖比较常规但容易漏一样就会在编译时翻车apt-get update apt-get install -y build-essential flex bison libncurses-dev \ qemu-system-x86 qemu-utils gdb-arm-none-eabi \ make wget cpio bc dwarves这里flex和bison是内核构建的语法解析器工具libncurses-dev用于make menuconfig的图形界面显示bc是内核编译时会调用的小型计算器dwarves用于生成BTF调试信息——最容易被忽视的就是bc和cpio缺了前者编译到某个阶段会报找不到bc命令的奇奇怪怪错误缺了后者initramfs根本生成不了。3. 从Makefile到第一个启动的内核完整落地步骤3.1 拿到项目文件并理解Makefile目标结构假设你现在已经把项目文件下载到了本地目录里能看到若干个.c文件、Makefile.*和gdbinit.auto。核心操作对象是那两个带版本号的Makefile它们定义了不同内核版本的不同构建流程。直接执行make -f Makefile.linux_v2.6.10 list能列出这个Makefile支持的所有目标这一步强烈建议先做——它能帮你快速摸清这套环境的操作入口。不过要注意这份Makefile不会是开箱即用的——它内部引用了一个变量指向你的源码目录。需要打开Makefile.linux_v2.6.10看一眼头部找到类似LINUX_SRC或KERNEL_DIR的变量定义把它改成你内核源码实际所在的路径。这是最常规、也最容易让人卡住的一步。# Makefile.linux_v2.6.10 片段 LINUX_SRC : /workspace/linux-2.6.10 ARCH : x86_64 CROSS_COMPILE :注意v2.6.10这个版本年代久远直接用gcc 12去编译大概率会报一堆“代码与编译器不兼容”的错误。我一般建议先在容器里装一个老版本的编译器链比如gcc-9然后通过CROSS_COMPILE/usr/bin/gcc-9-来指定。2.6.11.12虽然晚了一个小版本其表现也好不到哪里去——对这些老内核来说越老的编译器越安全。3.2 编译内核参数选择与常见失败点配置内核有两种路线直接用Makefile里自带的默认配置适合快速验证或自己执行make oldconfig交互式调整适合深入实验。我自己的习惯是先用默认配置把整个链路走通确保QEMU能启动、能看到内核日志再回头来改配置做驱动实验。# 在容器内执行假设源码已解压到 /workspace/linux-2.6.10 cd /workspace/linux-2.6.10 make mrproper # 清理旧配置避免之前编译残留干扰 make x86_64_defconfig make -j$(nproc) bzImage这里make x86_64_defconfig会生成一个合理的基础x86_64配置-j$(nproc)可以充分利用CPU核心数加速编译。但注意老内核与高版本编译器存在一个极常见的坑——编译中报code model kernel does not support或者一堆implicit declaration的warning最终转error。可以加KCFLAGS-Wno-error或者直接改Makefile里-Werror为-Wno-error没必要卡在这里。等编译结束后确认一下arch/x86/boot/bzImage文件是否生成。这个文件就是内核本体后续QEMU启动会用到它。3.3 制作根文件系统和磁盘镜像内核要启动光有bzImage还不够需要一个可挂载的根文件系统rootfs。这里的选择有很多可以是BusyBox最小集也可以是完整的Ubuntu根文件系统。对于快速实验BusyBox足够而且写入极小。项目脚本里应该有对应的目标但它的逻辑同样不难理解# 先制作一块512MB的虚拟磁盘并格式化为ext4 dd if/dev/zero of/workspace/rootfs.img bs1M count512 mkfs.ext4 /workspace/rootfs.img # 把磁盘挂到临时目录并拷贝busybox等最小环境 mkdir -p /mnt/rootfs mount -o loop /workspace/rootfs.img /mnt/rootfs cd /mnt/rootfs mkdir -p bin sbin etc proc sys dev lib cp /bin/busybox bin/ bin/busybox --install bin/ cp /usr/bin/gdb bin/ # 容器里装好的gdb拷进rootfs方便后续内核态调试 umount /mnt/rootfs这里有一个非常容易踩的细节拷贝到rootfs里的busybox必须是静态编译的版本动态链接的busybox离开了容器环境会因找不到动态库而启动失败。检查可以用file bin/busybox | grep static如果显示dynamically linked就去apt-get install busybox-static换取静态版。3.4 用QEMU启动三个关键参数决定成败现在到了最让人兴奋的一步——用QEMU把编译好的内核和根文件系统一起跑起来。通常是Makefile里已经封装好了QEMU启动命令但你要理解每个参数在干什么出了问题才有排查方向。qemu-system-x86_64 -kernel /workspace/linux-2.6.10/arch/x86/boot/bzImage \ -drive file/workspace/rootfs.img,formatraw,ifide \ -append root/dev/sda rw consolettyS0 \ -nographic -no-reboot-kernel指定内核镜像路径-drive把rootfs.img作为IDE硬盘接入——注意老内核对应/dev/sda使用的是IDE驱动所以参数里用了ifide而不是ifvirtio-append里的consolettyS0把内核日志输出到串口配合-nographic把串口重定向到当前终端。这样你就能直接在当前终端看到内核的启动日志而不用去点一个可能不渲染文本的图形窗口。-no-reboot是为了让内核panic后直接退出QEMU而不是无限重启循环这对观察内核崩溃现场特别重要。执行这条命令后如果一切正常你会看到内核逐条打印启动信息最后停在/ #这个BusyBox shell提示符。到这一步你的第一个“可实验内核环境”就算跑通了。4. 深入调试与扩展利用gdbinit.auto和驱动示例代码4.1 gdbinit.auto的玩法一条命令挂起内核这套环境里最有价值的就是那份gdbinit.auto。用纯命令行调试内核最痛苦的是手动设置符号文件、连接远程端口、加载内核模块这一串动作而这份脚本把这一切自动化了。它的内容本质上是一系列GDB命令。# gdbinit.auto 内容示意 target remote :1234 file /workspace/linux-2.6.10/vmlinux set architecture i386:x86-64 add-auto-load-safe-path /workspace/linux-2.6.10/ break start_kernel continue用法是QEMU先启动并停在等待调试器接入的状态然后在另一个终端启动GDB并自动加载这份脚本。用-S参数让QEMU在启动时暂停CPU等待调试器以及-s让QEMU在TCP 1234端口开放GDB远程调试协议这两个QEMU参数要配合起来# 终端1启动QEMU并等待GDB介入 qemu-system-x86_64 -kernel /workspace/linux-2.6.10/arch/x86/boot/bzImage \ -drive file/workspace/rootfs.img,formatraw,ifide \ -append root/dev/sda rw consolettyS0 nokaslr \ -nographic -no-reboot -s -S # 终端2进入容器执行GDB gdb-multiarch -x /workspace/gdbinit.auto这里-s和-S是小写单字母分别是-gdb tcp::1234和-S的快捷写法。设置nokaslr很重要——如果内核启用了内核地址空间布局随机化KASLRGDB下断点的地址跟实际代码运行地址对不上断点根本不会命中这是新手最容易困惑的“为什么break start_kernel毫无反应”的原因。脚本里那个break start_kernel值得你多玩几次。start_kernel是内核启动的C语言入口点在这里断下来之后你可以单步执行 查看各种初始化阶段的全局变量状态对理解内核启动流程非常有帮助。4.2 驱动示例代码ldt.c、dio.c与misc_loop_drv.c怎么用项目里带了几个.c文件分别是ldt.c、dio.c、ldt_plat_drv.c和misc_loop_drv.c——从文件名能看出它们的定位有些是内核模块示例有些是设备驱动骨架。这些文件的价值在于给你一份可以直接编译加载进实验内核的“靶子”用来练习模块编写和调试技巧。以内核模块为例编译方式与普通内核模块一致但要在Makefile中指定内核源码目录和架构。把下面这个Makefile放在与你模块相同目录obj-m misc_loop_drv.o KERN_DIR : /workspace/linux-2.6.10 ARCH : x86_64 CROSS_COMPILE : all: make -C $(KERN_DIR) M$(PWD) ARCH$(ARCH) CROSS_COMPILE$(CROSS_COMPILE) modules clean: make -C $(KERN_DIR) M$(PWD) ARCH$(ARCH) clean执行make后得到misc_loop_drv.ko通过scp或者mount --bind方式把它拷贝到rootfs.img挂载目录中再在QEMU启动的内核里执行insmod misc_loop_drv.ko加载。如果模块代码里有printk日志会直接打到内核的环形缓冲里用dmesg查看输出。值得说明的是这几个示例并不是随意堆出来的——misc_loop_drv.c对应一个杂项设备驱动的完整模板ldt.c应该与系统的LDT局部描述符表机制相关可作为深入x86分段机制的切口。它们的共同点是都不依赖外部第三方库纯内核API就能编译通非常适合练习“读代码→改代码→加载模块→观察行为”这条内核学习主循环。4.3 从QEMU到真机的调试思维迁移这套环境能让你在十几秒内反复启动/崩溃内核这撞击试验里每一个被窗口关闭的panic现场累积的都是对内核异常处理机制的直觉。许多内核调试技巧比如在驱动代码里加dump_stack()看调用栈、用/proc/modules确认模块加载状态在这套虚拟环境里都可以得到与真实机器高度相似的反馈。区别只是虚拟化的中断控制器和真实硬件的时序略有差异但这对于学习“OS原理”层面完全够用。5. 避坑与排查那些反复折磨人的环境细节5.1 编译阶段老内核与新高版本工具链的兼容困局现象在Ubuntu 22.04容器里make执行到一半屏幕上刷出一堆以arch/x86/entry/entry_64.S开头的汇编错误或者报unsupported instruction之类的信息。原因Linux 2.6.10发布时gcc还停留在4.x时代。新版gcc对老代码的隐式声明要求更严格同时对x86指令集的描述也演变了很多老汇编代码在新汇编器下部分指令已不合法。这属于典型的“版本断层”问题不是代码本身有缺陷。解决我在容器里安装了gcc-9并修改Makefile中CROSS_COMPILE : /usr/bin/gcc-9-让编译走老工具链。这一改大量莫名其妙的报错直接消失。如果是ARM架构的实验同理要关注binutils和libc的版本优先选择2.25附近的老版本工具链。也可以尝试使用项目Makefile里自带的工具链路径变量在容器中建立软链接指到实际安装版本这样不改Makefile也能生效。5.2 启动阶段内核起来了但登录不了shell现象QEMU启动后看到内核日志正常输出但最后停在Kernel panic - not syncing: No init found.或者卡在init: cannot execute /bin/sh。原因根文件系统内容不完整或init程序缺失。BusyBox如果没被正确安装到/bin/sh位置或/sbin/init指向错误内核便找不到可以执行的顺序。还有另一种情况是/dev/console这个设备节点缺失导致内核无法打开标准输入输出。解决重新挂载rootfs.img使用busybox --install -s bin/强制加符号链接方式创建所有工具链并确认/bin/sh存在。此外手动建常用设备节点mknod -m 666 /mnt/rootfs/dev/console c 5 1 mknod -m 666 /mnt/rootfs/dev/null c 1 3 mknod -m 666 /mnt/rootfs/dev/ttyS0 c 4 64设备节点是内核与硬件交互的中介删掉/漏掉一个对应的功能就会异常。console节点常在启动阶段被内核要求提前存在新手常因忘记这一步而卡壳。5.3 调试阶段添加断点后内核不触发或直接失去响应现象在start_kernel下断点并执行continue之后GDB侧一直显示“Program received signal SIGTRAP”但被调试的内核似乎冻结或者继续跑飞了断点无法命中。原因多半是KASLR导致符号与地址对不上或者gdbinit.auto里的file指向了vmlinux而QEMU加载的是bzImage两者代码段地址存在偏移。解决在-append参数中显式添加nokaslr并确认GDB加载的vmlinux与QEMU加载的bzImage是同一build产物——它们的调试信息必须同源。具体检查file vmlinux应显示带debug信息的ELF可执行文件而不是被strip过的在GDB里执行info address start_kernel输出的地址应与nm vmlinux | grep start_kernel一致。若不一致考虑是否是CONFIG_RANDOMIZE_BASE未关闭导致编译期地址随机化此时需要改内核配置并重编。5.4 资源限制QEMU进程崩溃或容器内无法创建嵌套虚拟化现象容器内部直接执行qemu-system-x86_64时报Failed to open /dev/kvm或者运行几分钟后QEMU进程被OOM杀死。原因容器默认没有/dev/kvm设备节点且未限制内存的大容器里QEMU默认分配虚拟机内存可能过大触发了宿主机或容器的内存限制。这不是QEMU本身的问题而是嵌套虚拟化权限与资源配额没配好。解决有条件的话在docker run时加--device/dev/kvm --group-add$(stat -c %g /dev/kvm)让容器直接对接KVM设备。同时给QEMU加-m 512限制虚拟机内存为512MB这已经把老内核运行空间给得很宽裕。若容器平台不支持KVM透传就老实把-enable-kvm去掉保持纯软件模拟。此时启动会比KVM加速慢30%~50%但稳定性没问题。6. 验证跑通从启动日志到驱动模块加载的全流程检查环境装好、跑起来只是第一步真正能搬上学习台面还需要一套可重复的验证流程——确认内核、rootfs和调试链路每一项都实际可用。以下的验证方法我每次都强制自己完整走一遍大概一首歌的时间就能排查掉九成的环境隐患。先做一个快速启动冒烟测试。用系统自带的默认配置启动QEMU观察日志序列。健康的启动过程会依次出现实模式引导信息、Linux version开头的内核版本号、内存探测行大约在500MB左右、各个子系统初始化Calibrating delay loop这种计算行出现在启动中段最后看到VFS: Mounted root (ext4 filesystem) on device 0:7或类似挂载成功的日志并在约两秒后进入/ #提示符。在这个提示符下执行uname -a确认内核版本与你编译的v2.6.10或v2.6.11.12完全一致一个字符都不能差。这一步就过滤掉了那种“内核编译成功但QEMU实际加载的是另一个默认内核”的错乱情况。接着验证模块编译链。以项目里的misc_loop_drv.c为例模块能成功编译是基础更重要的是编译产物能被当前内核接受。在内核里insmod misc_loop_drv.ko后马上执行lsmod看模块是否出现在已加载列表里再执行dmesg | tail看驱动的初始化打印——一个规范的misc驱动模板会在probe函数里打出设备注册信息。如果insmod报Invalid module format这类错误第一反应不是怀疑驱动代码而是确认模块编译时的内核版本与运行内核是否完全同源——这是最容易埋头乱找一小时但实际答案很简单的地方。然后做一次GDB链路验证。这是判断整套环境有没有真正具备“内核调试能力”的分水岭。流程是以-s -S启动QEMU用gdb-multiarch -x gdbinit.auto连上在start_kernel下断点并continueGDB应当在秒级内命中该断点并暂停。此时执行bt能看到一组包括start_kernel在内的调用栈再用info registers验证寄存器组不是全零而是真实存在初始化现场。如果能走到这一步说明QEMU的远程调试协议、GDB的符号加载、KASLR关闭都同时生效——这套环境已经具备了专业内核调试工具链的基本盘。最后是rootfs读写与持久化验证。在QEMU的/ #提示符下创建一个文件然后干净关机重启比如touch /test_write reboot。重启后再次挂载rootfs执行ls /test_write确认文件还在就证明块设备镜像的读写持久化链路是通的。这一步看似多余但它决定了你能不能在内核里安装编译工具、保存实验产物——整个环境下半场的工作方式都建立在这上面。如果不做这个验证往往会突然发现rootfs其实是以只读方式挂载的或者写入只落在临时内存层等你折腾了半小时准备保存代码时全部丢失那种感觉真的是欲哭无泪。走完这四条验证线整套环境就算经受过一次完整体检了。从那以后我每次搭建内核实验环境都会强制走一遍这套流程——上面多数“玄学”问题都是因为当初跳过了其中某一步。希望这次记录能帮你少绕几圈弯路把精力留给你真正想研究的内核代码里。本文还有配套的精品资源点击获取