很多朋友接触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 - 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就是解决这个问题的。它是一个临时的内存文件系统，在内核启动时被加载到内存中。里面包含了：
- • 必要的内核模块（磁盘控制器驱动、文件系统驱动等）
- • 一个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这些最基本的命令
- • util-linux：mount、fdisk、dmesg等系统管理工具
- • shadow：passwd、useradd等用户管理工具
- • sysvinit或systemd：init系统，后面单独说
- • 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）：
- •
apt是高级前端，负责解决依赖关系、从仓库下载包 - • 仓库配置在
/etc/apt/sources.list
Red Hat系（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都软链接到/usr下面，这就是usrmerge，Fedora和Debian都已经做了这个迁移。
第九步：安全加固和默认配置
发行版还得做大量的安全加固工作：
- • SELinux/AppArmor：强制访问控制，限制进程能访问的资源
- • 防火墙默认规则：firewalld或ufw的默认配置
- • SSH安全配置：禁止root远程登录、禁止密码认证
- • 内核安全参数：
/etc/sysctl.d/下的各种安全相关参数
不同发行版的安全策略差异很大。比如RHEL默认开启SELinux（enforcing模式），很多新手装完服务发现访问不了，查了半天才发现是SELinux拦了。Ubuntu默认用AppArmor，相对温和一些。Arch Linux基本不做安全加固，一切交给用户自己。
第十步：安装程序和ISO制作
最后一步是把所有东西打包成一个可安装的ISO镜像。
安装程序（installer）本身就是一个不小的工程。Debian用的是debian-installer，Ubuntu用的是Ubiquity，RHEL用的是Anaconda。安装程序要处理的事情包括：
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及对应的高级前端
- 7. 内核定制：安全补丁、驱动backport、功能增强
- 9. 安全加固：SELinux/AppArmor、防火墙、SSH安全配置
- 10. 安装程序和ISO制作：打包成可安装/可启动的镜像
所以说，发行版做的事情远不止"把内核和软件打包在一起"这么简单。它是一个系统工程，涉及编译构建、依赖管理、安全维护、用户体验等方方面面。这也是为什么CentOS宣布停止维护后那么多人慌了——维护一个发行版的长期稳定版本，真的是一件非常吃力的事情。
希望这篇文章能帮你理解Linux内核到发行版之间的完整链路。如果你觉得有用，帮忙转发给更多需要的朋友。
公众号：耕云躬行录
个人博客：躬行笔记
