从零构建 Linux|04 Rootfs、init 与服务

系列第 4 篇｜用户空间如何从 init 展开到应用读完本篇，启动阶段与流程的后半段就齐了

内核挂好根文件系统并启动 init 之后，故事进入用户空间（user space）。本篇解决这些事：

1. 内核空间和用户空间差在哪？
2. rootfs 与 init 是什么关系？最小 rootfs 必须有哪些东西？
3. init 如何按 initrc / systemd 拉起服务？为何要启动这些服务？
4. 服务与应用进程是什么关系？
5. 常见 rootfs 制作工具与镜像格式有哪些？

内核空间 vs 用户空间

可以把一台在跑的 Linux 想成两层楼：

两边怎么交流？主要通过系统调用（system call / syscall）。

你日常用 C 写的大多数程序，都在用户空间。程序调用 printf、open、read、malloc，底层往往落到 libc，再通过系统调用进入内核。打开 /dev 下的设备节点、读写普通文件，最后也多半是这条路。

为什么启动流程要强调这个分界？因为「内核启动完成」只意味着底层引擎就绪；真正让你登录、开网络、跑业务程序的，是用户空间里的 init、服务和应用。而这些东西，全都住在 rootfs 里。

Rootfs 到底是什么

Rootfs = Root File System = 根文件系统。

当内核把某个文件系统挂载为 / 之后，你看到的整棵目录树（至少是根那一层）就是 rootfs 的内容，例如：

可以记一句很实用的话：

内核镜像是发动机；rootfs 是车厢里的座位、说明书和乘客（程序）。两者都要有，车才能载人上路。

Rootfs 与 init 的关系

第 3 篇讲到：内核挂上 / 之后，会执行第一个用户进程——通常是 /sbin/init（可用 cmdline 的 init= 覆盖）。

这里有一个容易漏掉、但对做系统至关重要的事实：

init 不是内核自带的，而是 rootfs 里的一个普通可执行文件。

因此：

把关系压成一句话：

内核负责「找到并执行」init；rootfs 负责「提供」init、它的库、配置，以及后续所有服务与应用。

对 C 开发者，可把 init 想成用户空间的 main()：内核只调用它一次；之后整个用户态世界由它（以及它拉起的子进程）展开。

最小 rootfs 必须有什么

「能启动到可用 shell」的最小集合，通常至少包括：

目录骨架示意（极简）：

/├── bin/          # 或与 /usr/bin 合并（UsrMerge）├── sbin/         # init、getty…├── lib/          # 或 lib64；动态库与 ld-linux├── etc/          # inittab、fstab、rc 脚本或 systemd 配置├── dev/          # 设备节点挂载点├── proc/         # procfs 挂载点├── sys/          # sysfs 挂载点├── tmp/└── root/         # 或 home/

记住：最小不等于「只有这几个空目录」。空目录里还要有真正能执行的二进制和正确的配置。发行版 rootfs 庞大，是因为在此基础上叠了大量软件、库、本地化和默认服务。

用户空间后半段总览

init → services (initrc / systemd) → application

完整过程：

1. 内核启动 init（PID 1）。
2. init 读取配置，决定启动哪些服务（services）——如 getty（登录）、网络、日志、时间同步等。
3. 服务就绪后，用户登录，或服务自动拉起应用程序（application）。

init：用户空间的总开关

init 是第一个用户进程，也是很多后续进程的祖先。它若异常退出，系统通常无法按正常方式继续运行。

init 的核心职责可以概括为四件事：

1. 系统初始化：挂载必要的文件系统、设置主机名、加载模块等。
2. 拉起服务：按配置启动守护进程（daemon）与登录环境。
3. 收养孤儿进程：父进程退出后，子进程往往由 PID 1 接管。
4. 处理关机/重启：收到信号或请求时，有序停止服务并关机。

常见实现：

本教程重点对比 initrc（SysV/BusyBox 风格） 与 systemd。

为何要启动这些服务

内核不会替你：

• 在串口/虚拟终端上弹出登录提示；
• 配好网卡 IP、起 DHCP；
• 写系统日志；
• 同步时钟；
• 自动跑你的业务程序。

这些都是用户空间服务的工作。可以按「必要性」粗分：

不做定制时，发行版会默认起一大串服务「保底好用」；嵌入式/Yocto 场景则会只保留真正需要的服务，以节省内存、缩短启动时间、减少攻击面。

initrc / SysV 风格：用脚本接力

在 BusyBox init 或传统 SysV init 里，常见做法是：

• 用 inittab 描述「开机执行什么、哪个终端上跑登录程序」；
• 用 /etc/init.d/ 下的脚本，按编号启动 / 停止服务；
• 用 /etc/rcS.d、/etc/rc2.d 这类目录里的符号链接，控制启动顺序（S 开头启动，K 开头停止）。

BusyBox inittab 示意：

::sysinit:/etc/init.d/rcS::respawn:/sbin/getty 115200 ttyS0::ctrlaltdel:/sbin/reboot

白话翻译：

rcS / init.d 里常见的一段逻辑（概念示意）：

#!/bin/shmount -t proc proc /procmount -t sysfs sysfs /sysmount -t devtmpfs devtmpfs /dev# 按需启动服务/etc/init.d/networking start/etc/init.d/syslog start

启动流程可以记成：

内核 → /sbin/init     → 读 inittab     → 跑 sysinit（rcS / init.d 脚本）     → 挂载、基础环境     → 启动各项服务脚本     → respawn getty → 用户登录 → 跑应用

特点：直观、脚本化、好改；依赖关系多靠「命名编号」人工保证，复杂系统上容易乱。

systemd：用 unit 文件描述服务

现代 Ubuntu、Debian、Fedora、CentOS 等大多使用 systemd 作为 init 系统。它用 unit 文件（常见为 .service）描述「一个服务怎么启动、依赖谁、失败了是否重启」，并用 target（如 multi-user.target）表达「运行到哪个阶段」。

最小示例：

[Unit]Description=Hello Demo ServiceAfter=network.target[Service]ExecStart=/usr/bin/helloRestart=on-failure[Install]WantedBy=multi-user.target

白话翻译：

systemd 启动主线（概念）：

内核 → /sbin/init（实际常是 systemd）     → 进入默认 target（如 multi-user.target / graphical.target）     → 按依赖并行拉起各 unit     → getty / display manager / 你的 .service     → 用户登录或业务进程就绪

与 initrc 的对比：

你不必一次学完 systemd，但要建立印象：服务不是凭空出现的，而是被 init 系统按配置拉起来的。

服务与应用进程的关系

日常口语里「服务」和「应用」常混用。做系统时建议这样区分：

关系通常是：

init（PID 1）  ├── 服务 A（如网络）  ├── 服务 B（如 sshd）  ├── 服务 C（你的业务 daemon）─── 可能再 fork 出工作进程  └── getty / 登录 shell ─────────── 用户再手动启动应用

三点务实结论：

1. 应用可以是服务：把业务程序写成 systemd unit / init.d 脚本，开机自动跑，它就既是应用也是服务。
2. 应用也可以不是服务：登录后手动执行一次的程序，一般不算系统服务。
3. 服务常常是应用的依赖：例如你的网络 App 依赖网络服务已就绪；没有日志服务，排障会困难很多。

在完整发行版上，安装这些程序最常见的方式，就是下一篇的包管理器（apt / yum）。在 Yocto/Buildroot 场景，则更多是在构建 rootfs 时就把二进制和服务配置打进去。

常见 rootfs「从哪来」

同样叫 rootfs，来源可以差很多：

注意区分：

后面学 Yocto 时你会发现：Yocto 做的事情，本质上也包括「按你的菜谱生成一套 rootfs，并决定里面默认有哪些服务和应用」。

Rootfs 常见制作形态与镜像格式

构建系统通常先得到一个「目录形式的 rootfs」，再按目标介质打包成镜像：

实践中常见流水线：

选工具制作 rootfs 目录  → 写入 init、库、配置、应用  → 打包成 tar / ext4 / wic / …  → 烧写到 SD/eMMC/U 盘，或交给 QEMU

对本教程后续 Demo 的预告：Yocto 会按 MACHINE 产出可在 QEMU 运行或可烧写到 x86_64 机器的镜像；你改的往往就是 rootfs 里有哪些包、哪些服务默认启用。

把本篇嵌回整条启动链

到这里，第 1 篇那条链的每一截你都应该能用白话解释了：

power on → bootloader → linux kernel→ rootfs → init → services → application

1. 前半段（到 kernel）解决「引擎与装载」；
2. 后半段（rootfs 起）解决「用户空间世界如何展开」：
• rootfs 提供 init 与全部用户态文件；
• init 按 initrc/systemd 拉起服务；
• 服务支撑登录与运行环境，再落到应用。

自定义系统时，你裁剪最多的往往正是 rootfs 和服务集合——这也是 Yocto 最常动手的地方。

本篇小结

1. 内核空间管底层；用户空间跑应用；中间靠系统调用连接。
2. Rootfs 是挂载为 / 的目录树；init 是其中的 PID 1 程序，二者缺一不可。
3. 最小 rootfs 至少要有：init、必要库、shell/基础命令、挂载点与初始化配置。
4. init 拉起服务是为了登录、设备、网络、日志和业务自启；initrc 与 systemd 是两种常见机制。
5. 服务多由 init 监管；应用可由服务自动拉起，也可由用户登录后手动运行。
6. BusyBox / Buildroot / Yocto / 发行版 / debootstrap 是获取 rootfs 的不同路线；产物常再打包为 tar、squashfs、ext4、wic 等格式。

系列文章列表：