从裸核到能用的系统：Linux内核到发行版到底经历了什么？

很多朋友接触Linux都是从装系统开始的，Ubuntu、CentOS、Debian装上去就能用，图形界面、命令行、软件包管理器一应俱全。但你有没有想过，Linus Torvalds维护的那个Linux内核，说白了就是一个压缩包里的源代码，它是怎么变成你手里那个开箱即用的操作系统的？中间这一大段距离，到底发生了什么？

今天我就把这条链路从头到尾捋一遍，尽量把每个环节干了啥说清楚。我自己做运维这些年，编译内核、定制系统、做最小化镜像这些活儿也没少干，踩过的坑也不少，正好借这个机会整理一下。

先搞清楚：内核≠操作系统

这个概念很多人其实分不太清。Linux内核是操作系统的核心没错，但它本身不能算一个完整的操作系统。你拿一个编译好的bzImage扔到机器上，啥也干不了——没有shell，没有命令，没有文件系统的用户态工具，连个ls都跑不起来。

打个比方，内核就像一台车的发动机，发动机再强，没有方向盘、没有轮胎、没有座椅，你也开不走。而发行版就是把发动机装进车壳里，接上油路电路，装好方向盘座椅，最后还给你加满油交钥匙的那个人。

所以从内核到发行版，中间要做的事情非常多，我按顺序往下说。

第一步：把内核源码编译成可启动的镜像

这一步是整个链路的起点。内核源码从kernel.org下载下来之后，你得先把它编译成机器能跑的东西。

编译内核的过程其实挺有意思。你在源码目录敲下make，背后发生的事情远比你想象的多。根Makefile先读取版本号（VERSION、PATCHLEVEL、SUBLEVEL这些），然后检测你的CPU架构，设置编译器路径和编译选项，加载.config配置文件。这个.config就是你执行make menuconfig之后生成的那个文件，决定了哪些功能编译进内核、哪些编译成模块、哪些直接不编译。

编译的最终产物是vmlinux——一个未压缩的ELF格式的内核可执行文件。但这个文件还不能直接拿来启动，它太大了，而且格式也不对。接下来要做的事情是：

1. 用objcopy把vmlinux转换成纯二进制的vmlinux.bin
2. 用gzip对vmlinux.bin进行压缩
3. 生成一个叫piggy.S的汇编文件，里面包含了压缩内核的偏移信息
4. 编译引导部分的代码（arch/x86/boot/下的那些实模式代码），生成setup.bin
5. 最后把setup.bin和压缩后的vmlinux.bin拼在一起，生成bzImage

bzImage才是最终能被GRUB加载的内核镜像。注意bzImage里的bz不是bzip2的意思，是"big zImage"——因为早期的zImage只能加载到低端640K内存，大内核放不下，才搞了bzImage加载到高端内存。

编译完内核还得编译模块，就是那些.ko文件，放在/lib/modules/内核版本号/下面。驱动啊、文件系统啊、网络协议啊，很多都是模块形式存在的。

第二步：制作initramfs——启动过渡的桥梁

内核启动之后，它需要挂载根文件系统对吧？但问题是，根文件系统可能在各种地方——普通的ext4分区、LVM逻辑卷、RAID阵列、甚至是网络上的NFS。你要访问这些设备，得先加载对应的驱动和工具。

这就形成了一个鸡生蛋蛋生鸡的问题：内核要挂载根文件系统，但挂载需要的驱动和工具在根文件系统里。

initramfs就是解决这个问题的。它是一个临时的内存文件系统，在内核启动时被加载到内存中。里面包含了：

• 必要的内核模块（磁盘控制器驱动、文件系统驱动等）
• udev或mdev设备管理工具
• lvm、mdadm等存储管理工具
• 一个init脚本（通常是/init），负责加载驱动、找到真正的根分区、切换过去

我之前做过一个项目，需要从加密的LVM分区启动，那个initramfs里塞满了cryptsetup、lvm2这些工具，还得在init脚本里写交互式的密码输入逻辑。当时折腾了好久才搞明白initramfs的整个流程——先mkinitramfs或dracut生成镜像，内核加载后解压initramfs到内存，执行/init，init脚本完成工作后调用switch_root切换到真正的根文件系统。

不同的发行版用的initramfs工具不一样，Debian/Ubuntu用mkinitramfs，RHEL/CentOS/Fedora用dracut。dracut的模块化设计更灵活一些，你可以通过配置文件控制往initramfs里塞哪些模块。

第三步：搭建用户空间的基础——glibc和基本工具

内核和initramfs搞定之后，接下来就是用户空间了。这是发行版最核心的工作之一。

用户空间的基础是C标准库，绝大多数Linux系统用的是glibc（GNU C Library）。为啥它这么重要？因为几乎所有的用户态程序都依赖它。你写个hello world用printf，底层就是glibc在干活。glibc还封装了系统调用，你的程序通过glibc跟内核打交道。

glibc的编译和安装是个技术活。它需要配合内核的头文件（linux-headers）来编译，版本不匹配的话会出各种诡异的问题。我记得有一次在CentOS 7上手动升级glibc，结果版本没对上，直接导致ls、cp这些基本命令全部段错误，系统当场就废了，最后只能用救援模式恢复。从此以后我对glibc升级这事儿特别谨慎。

除了glibc，还有一些最基础的工具是必须的：

• coreutils：ls、cp、mv、rm、cat、mkdir这些最基本的命令
• bash：默认的shell
• util-linux：mount、fdisk、dmesg等系统管理工具
• shadow：passwd、useradd等用户管理工具
• sysvinit或systemd：init系统，后面单独说
• e2fsprogs：ext4文件系统工具
• procps：ps、top、kill等进程管理工具

这些工具大部分来自GNU项目，这也是为什么很多人坚持叫"GNU/Linux"而不是简单的"Linux"。内核确实只是Linus的，但用户空间的基础设施大部分是GNU搞的。

第四步：init系统——系统启动的总指挥

内核启动完之后，最后一步是启动PID为1的init进程。这个进程是所有进程的祖宗，负责把整个用户空间拉起来。

传统的init系统是SysVinit，来自Unix System V。它的启动流程是按运行级别（runlevel）来的，0-6七个级别，每个级别对应/etc/rc.d/rcX.d/下面的一堆脚本，以S开头的是启动脚本，以K开头的是停止脚本，后面的数字决定执行顺序。

SysVinit简单粗暴，但有个致命缺点——太慢了。脚本一个一个串行执行，开机启动时间动不动就好几分钟。在服务器上还能忍，在桌面和容器里就完全不能接受了。

所以后来就有了systemd。systemd这玩意儿争议很大，但不得不说它确实解决了不少问题：

• 并行启动：服务之间有依赖关系，systemd会分析依赖图，没有依赖关系的服务并行启动，启动速度大幅提升
• socket激活：服务不需要一直运行，有请求来了再通过socket通知启动
• cgroup管理：每个服务都放在cgroup里，资源控制更精确
• 日志系统：journald统一管理日志，不用再去/var/log下面翻一堆文件

现在主流发行版基本都切到systemd了，Ubuntu从15.04开始，CentOS从7开始。不过也有少数发行版坚持不用systemd，比如Devuan就是专门为了不用systemd而从Debian fork出来的。

我自己对systemd的感受比较复杂。从运维角度来说，systemctl status 服务名一条命令就能看服务状态、日志、cgroup信息，确实方便。但systemd越来越庞大，吞掉了logind、resolved、networkd这些原本独立的组件，有点"万物皆systemd"的意思，这让很多人不舒服。

第五步：包管理系统——发行版的灵魂

如果说内核是发动机，那包管理系统就是4S店的售后服务体系。没有包管理系统，你装软件就得自己编译源码、解决依赖、管理版本——那画面太美我不敢想。

主流的包管理系统分两大阵营：

Debian系（dpkg/apt）：

• .deb包格式
• dpkg是底层工具，负责安装、卸载、查询包
• apt是高级前端，负责解决依赖关系、从仓库下载包
• 仓库配置在/etc/apt/sources.list

Red Hat系（rpm/yum/dnf）：

• .rpm包格式
• rpm是底层工具
• yum（老）和dnf（新）是高级前端
• 仓库配置在/etc/yum.repos.d/下面

制作一个包可不是简单地把编译好的文件打个包。一个合格的包需要：

1. spec文件或debian目录：定义包的元信息、依赖关系、编译步骤、安装步骤、文件列表
2. 编译环境：干净的编译环境，通常是chroot或容器，避免宿主系统的残留文件污染
3. 依赖声明：Build-Depends（编译时依赖）和Depends（运行时依赖）必须准确
4. 安装脚本：preinst/postinst/prerm/postrm这些维护脚本，处理用户创建、配置文件更新等逻辑
5. 签名：用GPG对包签名，用户安装时可以验证包的完整性和来源

我之前在内部搞过RPM包的打包流程，写spec文件写到手软。最头疼的是依赖声明，漏了一个依赖，在别的机器上装就报错。后来搞了个CI流水线，在干净的容器里自动编译打包测试，才把这个问题解决掉。

第六步：仓库构建和发布

包做好了，还得有个地方放。这就是软件仓库。

仓库的构建是个系统工程：

• 仓库结构：每个发行版有固定的仓库结构，比如Debian的pool目录放包文件，dists目录放元数据索引
• 元数据生成：dpkg-scanpackages或createrepo生成包索引，apt/yum/dnf通过索引来查找和下载包
• 仓库分层：main/restricted/universe/multiverse（Debian系），BaseOS/AppStream/PowerTools（RHEL系）
• 签名和验证：仓库的Release文件要用GPG签名，客户端用公钥验证
• 镜像同步：全球各地的镜像站通过rsync同步仓库内容

一个完整版本的发布流程大概是这样的：先freeze仓库（不再接受新版本的上传，只接受bug修复），然后经过alpha→beta→RC→final的测试周期，确认没有重大问题后正式发布。发布后还要维护更新源，推送安全补丁和bug修复。

Ubuntu的LTS版本支持5年，RHEL支持10年，这意味着发行版维护者要从上游内核持续backport安全补丁到老版本内核上。这个工作量是非常大的，有时候一个CVE的修复要改好几百行代码，还得保证不影响老版本的稳定性。

第七步：内核补丁和定制

发行版通常不会直接用vanilla kernel（Linus发布的原版内核），而是会打上自己的补丁：

• 安全补丁backport：把新内核的安全修复移植到老版本内核
• 驱动补丁：某些硬件厂商提供的闭源驱动或特殊驱动
• 性能优化：针对特定工作负载的调度器优化、内存管理优化
• 功能增强：比如SELinux的支持、审计系统的支持
• Bug修复：社区发现但在主线内核中还没修复的问题

RHEL的内核跟主线内核差异特别大，Red Hat有专门的内核团队维护自己的内核分支。Ubuntu也有自己的内核团队，会在主线内核基础上加入一些硬件支持补丁。

我之前在某个国产化项目上，需要在4.19内核上加一个特定的网卡驱动，那个驱动只有5.4以上内核才有。花了两天时间把驱动代码从5.4 backport到4.19，改了一堆API适配的问题，编译通过的那一刻差点感动哭了。

第八步：文件系统目录结构标准化

Linux的目录结构遵循FHS（Filesystem Hierarchy Standard），这个标准定义了每个目录应该放什么：

• /bin和/sbin：基本命令和系统管理命令
• /lib：共享库和内核模块
• /etc：配置文件
• /var：可变数据（日志、缓存、数据库）
• /usr：用户级应用和库
• /tmp：临时文件
• /dev：设备文件
• /proc和/sys：内核和设备信息

发行版需要按照这个标准组织文件，确保软件包安装的文件放在正确的位置。不过现在有个趋势是/bin、/sbin、/lib都软链接到/usr下面，这就是usrmerge，Fedora和Debian都已经做了这个迁移。

第九步：安全加固和默认配置

发行版还得做大量的安全加固工作：

• SELinux/AppArmor：强制访问控制，限制进程能访问的资源
• 防火墙默认规则：firewalld或ufw的默认配置
• SSH安全配置：禁止root远程登录、禁止密码认证
• umask设置：默认文件权限
• 内核安全参数：/etc/sysctl.d/下的各种安全相关参数
• PAM配置：认证模块的配置
• sudo配置：权限提升的控制

不同发行版的安全策略差异很大。比如RHEL默认开启SELinux（enforcing模式），很多新手装完服务发现访问不了，查了半天才发现是SELinux拦了。Ubuntu默认用AppArmor，相对温和一些。Arch Linux基本不做安全加固，一切交给用户自己。

第十步：安装程序和ISO制作

最后一步是把所有东西打包成一个可安装的ISO镜像。

安装程序（installer）本身就是一个不小的工程。Debian用的是debian-installer，Ubuntu用的是Ubiquity，RHEL用的是Anaconda。安装程序要处理的事情包括：

• 硬件检测和驱动加载
• 磁盘分区和文件系统创建
• 软件包选择和安装
• 用户创建和密码设置
• 时区和语言设置
• 网络配置
• 引导加载器（GRUB）安装

ISO的制作通常用xorriso或genisoimage，需要把内核、initramfs、软件包仓库、安装程序都打包进去。对于Live ISO，还需要用squashfs把整个根文件系统压缩，启动时解压到内存中运行。

我之前用livecd-tools和kiwi做过定制化的Live ISO，整个过程就是：先装好一个最小系统→chroot进去定制→安装需要的软件包→清理缓存和日志→用工具打包成ISO。说起来简单，但每次都会碰到各种幺蛾子，比如某个服务在chroot里启动失败导致ISO制作中断，又比如忘记清理/etc/resolv.conf导致ISO里的DNS解析有问题。

总结

从Linux内核到一个可用的发行版，中间经历了：

1. 内核编译：源码→vmlinux→bzImage+模块
2. initramfs制作：启动过渡的临时文件系统
3. 用户空间基础：glibc、coreutils、bash等基础组件
4. init系统：systemd或SysVinit管理服务启动
5. 包管理系统：rpm/dpkg及对应的高级前端
6. 仓库构建：软件仓库的搭建、索引、签名、镜像
7. 内核定制：安全补丁、驱动backport、功能增强
8. 目录结构标准化：FHS规范
9. 安全加固：SELinux/AppArmor、防火墙、SSH安全配置
10. 安装程序和ISO制作：打包成可安装/可启动的镜像

所以说，发行版做的事情远不止"把内核和软件打包在一起"这么简单。它是一个系统工程，涉及编译构建、依赖管理、安全维护、用户体验等方方面面。这也是为什么CentOS宣布停止维护后那么多人慌了——维护一个发行版的长期稳定版本，真的是一件非常吃力的事情。

希望这篇文章能帮你理解Linux内核到发行版之间的完整链路。如果你觉得有用，帮忙转发给更多需要的朋友。

公众号：耕云躬行录

个人博客：躬行笔记