一、rootfs概念与依赖管理概述

各位同学，今天我们来聊聊嵌入式Linux里一个绕不开的话题——rootfs。说白了，rootfs就是根文件系统，是整个系统启动后挂载的第一个文件系统。我刚开始做嵌入式时，总觉得这玩意儿不就是一堆文件嘛，有什么好研究的？直到有一次，我辛辛苦苦编译完一个系统，启动后却卡在kernel panic，提示找不到init进程……嗯，从那以后，我再也不敢小看rootfs了。

1.1 什么是rootfs

rootfs，全称root filesystem，是Linux系统启动后挂载的第一个文件系统。它包含了系统运行所需的一切：可执行程序、库文件、配置文件、设备节点等等。你可以把它想象成一座房子的地基——没有它，上层应用根本站不住脚。

我个人习惯把rootfs分成两类：

• 完整版rootfs：包含完整的工具链、开发库、调试工具，适合开发板调试阶段使用。我记得第一次用Buildroot生成一个200MB的rootfs，烧进去后系统跑得挺欢，但后来发现很多工具根本用不上。
• 精简版rootfs：只保留运行所需的最小文件集，适合量产产品。说白了，就是能省则省，一个ls命令都可能是busybox提供的。

你想想看，一个嵌入式设备可能只有64MB的Flash空间，你总不能把整个Ubuntu塞进去吧？所以rootfs的裁剪和依赖管理，就成了嵌入式工程师的必修课。

1.2 为什么需要包依赖管理

好，问题来了——为什么我们需要包依赖管理？

我遇到过这样一个场景：项目组A开发了一个网络服务程序，依赖libssl.so.1.1。项目组B负责打包rootfs，他们用的libssl版本是1.0.2。结果呢？服务启动时直接报错，说找不到符号。排查了半天，才发现是库版本不匹配。

这就是典型的依赖问题。没有依赖管理，你会遇到：

• 版本冲突：两个程序需要同一个库的不同版本
• 缺失依赖：安装A时，不知道还需要B和C
• 卸载风险：卸载一个包，可能连带删掉其他包需要的库
• 升级灾难：升级某个库，导致依赖它的程序全部罢工

我曾经在一个项目中，因为手动拷贝了一个.so文件到rootfs里，结果破坏了整个系统的库依赖链。那一次，我花了整整两天才把系统救回来。所以，依赖管理不是锦上添花，而是刚需。

1.3 常见包管理工具对比

目前主流的嵌入式Linux包管理工具有三个：dpkg（Debian系）、rpm（Red Hat系）、apk（Alpine系）。它们各有千秋，我分别说说我的使用感受。

特性	dpkg	rpm	apk
所属发行版	Debian/Ubuntu	Red Hat/Fedora	Alpine Linux
包格式	.deb	.rpm	.apk
依赖解析	apt-get/aptitude	yum/dnf	内置依赖解析
体积	较大	较大	小巧
事务支持	部分支持	支持	支持
嵌入式适用性	中等	中等	优秀

我个人的经验是：

• dpkg：如果你用Debian/Ubuntu做开发，dpkg是最自然的选择。它的依赖管理通过apt完成，功能强大但体积偏大。我在一个项目中用dpkg构建rootfs，结果光包管理数据库就占了十几MB，对于Flash空间紧张的产品来说，有点奢侈。
• rpm：Red Hat系的包管理，在企业级Linux中很常见。它的依赖解析能力很强，但同样体积不小。我记得有一次在嵌入式设备上尝试用rpm，发现它的数据库操作比较重，不太适合资源受限的环境。
• apk：Alpine Linux的包管理工具，也是我目前在嵌入式项目中最常用的。它设计简洁，依赖解析是内置的，不需要额外的工具。apk的包格式是.tar.gz，安装脚本用shell编写，非常轻量。我建议做资源受限的嵌入式产品时，优先考虑apk。

1.4 知识体系结构图

为了让大家更直观地理解本章的知识结构，我画了一张图：

这张图把本章的核心内容串起来了。你想想看，rootfs不是孤立的，它由多个要素组成，这些要素之间存在着复杂的依赖关系。而包管理工具，就是帮我们理清这些关系的利器。

好了，这一章的内容就到这里。下一章我们会深入dpkg的实战操作，看看如何用dpkg构建一个可用的rootfs。到时候我会分享一些我在项目中踩过的坑，希望能帮大家少走弯路。