当前位置:首页>Linux>从零构建 Linux|04 Rootfs、init 与服务

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

  • 2026-09-26 04:35:40
从零构建 Linux|04 Rootfs、init 与服务

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

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

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

内核空间 vs 用户空间

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

空间
住什么
权限与后果
内核空间(kernel space)
内核代码、驱动程序
权限高,可直接控制硬件与关键资源;崩了常常整机异常或重启
用户空间(user space)
应用程序、动态库、系统服务、shell
权限受限;想碰硬件通常得「求」内核;崩了通常只是该进程退出

两边怎么交流?主要通过系统调用(system call / syscall)。

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

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

Rootfs 到底是什么

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

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

路径
内容
/bin
/usr/bin
常用命令
/lib
/usr/lib
动态库
/etc
配置
/sbin
/usr/sbin
偏管理用的程序(常有 init)
/dev
/proc、/sys
设备节点与内核导出的虚拟文件系统挂载点
/home
用户目录

可以记一句很实用的话:

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

Rootfs 与 init 的关系

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

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

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

因此:

若 rootfs…
结果
没有 init,或路径/权限不对
内核挂载成功也会报 No init found,进不了用户空间
有 init,但缺它依赖的动态库
init 起不来(动态链接失败)
init 能跑,但配置为空/错误
可能停在黑屏、无登录、无网络
init 与配置正常
才会继续拉起服务和应用

把关系压成一句话:

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

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

最小 rootfs 必须有什么

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

类别
典型内容
说明
PID 1 程序
/sbin/init
(或 BusyBox 提供的 init)
用户空间总入口
动态链接器与基础库
ld-linux-*.so*
、libc.so* 等
若 init/shell 是动态链接,缺了就起不来;静态链接可省不少库
Shell 与基础命令
sh
、mount、ls 等
调试、挂载、看目录;嵌入式常用 BusyBox 一把梭
设备与伪文件系统挂载点
/dev
、/proc、/sys、/tmp、/run
运行时要挂 devtmpfs/proc/sysfs 等
初始化配置
/etc/inittab
 或 systemd 的 unit 树
告诉 init「开机干什么」
基础设备节点(视方案)
/dev/console
、/dev/null 等
有的系统靠 devtmpfs 自动生成,极简方案可能需预置

目录骨架示意(极简):

/├── 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. 处理关机/重启:收到信号或请求时,有序停止服务并关机。

常见实现:

实现
常见场景
配置风格
BusyBox init / SysV init
嵌入式、极简系统
inittab
 + /etc/init.d 脚本
systemd
Ubuntu、Debian、Fedora、CentOS 等
.service
 等 unit 文件
其他
OpenRC、runit 等
各有一套,思想类似「按依赖启动服务」

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

为何要启动这些服务

内核不会替你:

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

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

类型
例子
为何需要
登录相关
getty
 / login / sshd
没有它们,你很难「进入」系统操作
基础设施
挂载剩余文件系统、udev/mdev、日志(syslog/journald)
设备节点、日志、可写分区往往依赖它们
网络
networking
、NetworkManager、systemd-networkd
多数产品需要连网才能更新、通信、远程维护
业务相关
你的 demo 服务、Web、采集程序
真正的产品功能;常做成开机自启的 service

不做定制时,发行版会默认起一大串服务「保底好用」;嵌入式/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

白话翻译:

项
含义
sysinit
系统初始化时跑 rcS(里面常会挂载文件系统、启动基础服务)
respawn
在串口上启动登录程序,若退出就再拉起来
ctrlaltdel
按下 Ctrl+Alt+Del 时重启(嵌入式上是否生效看具体配置)

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

白话翻译:

字段
含义
After=network.target
尽量在网络相关目标之后启动(表达顺序/依赖意图)
ExecStart=
真正要跑的命令
Restart=on-failure
异常退出时尝试重启
WantedBy=multi-user.target
进入多用户运行目标时希望启用它

systemd 启动主线(概念):

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

与 initrc 的对比:

维度
initrc / SysV
systemd
配置形态
脚本 + inittab
声明式 unit
依赖与并行
主要靠编号顺序
明确依赖,可并行启动
进程监管
较弱,常靠 respawn 或额外工具
内建 Restart、cgroup 等
学习成本
低,适合极简系统
概念多,发行版上几乎是标配

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

服务与应用进程的关系

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

概念
含义
典型例子
服务(service)
由 init 系统管理、常驻后台、为系统或其他程序提供能力的进程(或一组进程)
sshd
、systemd-networkd、日志服务、你的开机自启 daemon
应用(application)
面向用户或业务目标的程序;可以前台交互,也可后台常驻
bash
、浏览器、你的业务 App

关系通常是:

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,来源可以差很多:

名称
角色
特点
BusyBox
rootfs 里的工具箱组件
一个可执行文件塞进很多精简 UNIX 命令;体积小,常见于极简嵌入式
Buildroot
生产 rootfs(及工具链)的工厂
配置相对直接,很快能做出根文件系统;适合嵌入式快速定制
Yocto Project
更完整的定制发行版工厂
可同时产出内核、bootloader、rootfs、镜像;本教程后半部分重点
Debian / Ubuntu
成品发行版
完整 rootfs + apt 生态;软件多、体系成熟,体积也大
debootstrap / multistrap
从 Debian/Ubuntu 仓库「 mixed」出 rootfs
适合要 apt 生态、又不想从零编译一切的场景
手工拼装
交叉编译后拷贝进目录树
教学/极简可行,工程上难维护依赖与升级

注意区分:

类型
例子
一句话
组件
BusyBox
rootfs 里的工具箱
构建工厂
Buildroot / Yocto
按菜谱生成 rootfs(以及更多东西)
成品或半成品
Debian / Ubuntu / debootstrap
已有或可快速得到完整用户空间

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

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

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

形态
典型后缀/形式
用途
目录树
rootfs/
、./ 打包前目录
开发调试、chroot、进一步打包
tar 归档
.tar
、.tar.gz、.tar.bz2、.tar.xz
便于传输;可解开到分区或容器
cpio / initramfs
.cpio
、.cpio.gz
常作 initramfs;早期用户空间
squashfs
.squashfs
只读压缩根文件系统,嵌入式常见
ext4 等磁盘镜像
.ext4
、.img
直接写成分区或整盘镜像
完整磁盘镜像
.wic
、.hddimg、.iso
含分区表 + boot + root,便于烧写/U 盘启动
容器相关
OCI/Docker 镜像(本质也是 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 等格式。

系列文章列表:

从零构建 Linux 系统
从零构建 Linux|01 启动流程总览
从零构建 Linux|02 Bootloader
从零构建 Linux|03 内核启动

最新文章

随机文章