1、网络配置的“根”在哪里：理解rootfs与网络配置的关系，为什么传统方法治标不治本

1.1 一个让我头疼的现场故事

几年前，我接手了一个嵌入式设备的售后问题。

客户说设备重启后，网络就断了。每次都得手动配IP，烦得很。

我远程看了下，发现/etc/network/interfaces写得明明白白。静态IP、网关、DNS，一个不落。

可设备一重启，这些配置就像被风吹走了一样，全没了。

我当时的第一反应是：脚本没执行？还是服务没起来？

折腾了两天，最后发现——rootfs是只读的。

嗯，你没听错。系统启动时加载的是squashfs镜像，所有对/etc的写入，重启后全部归零。

从那以后，我养成了一个习惯：遇到网络配置问题，先问一句——你的rootfs是活的还是死的？

1.2 传统方法为什么“治标不治本”

很多人配置网络，习惯用ifconfig、ip addr，或者改/etc/network/interfaces。

这些方法在普通Linux桌面或服务器上没问题。但在嵌入式Linux里，情况完全不同。

你想想看，嵌入式设备的rootfs通常是什么？

• 只读文件系统：比如squashfs、initramfs。你改完配置，一重启就还原。
• 临时文件系统：比如tmpfs。重启后数据全丢。
• overlay文件系统：上层可写，但下层是只读的。配置改了，但上层空间有限，或者没被正确挂载。

说白了，传统方法是在“沙子上盖房子”。

你改的是运行时状态，不是持久化配置。

设备一断电，一切回到解放前。

1.3 rootfs与网络配置的关系

rootfs是什么？它是系统启动后挂载的第一个文件系统。

所有用户空间的程序、库、配置文件，都在这里面。

网络配置，本质上就是一组文件：

• /etc/network/interfaces 或 /etc/systemd/network/*.network
• /etc/resolv.conf
• /etc/hostname
• /etc/hosts
• /etc/ntp.conf 等等

这些文件放在rootfs里。rootfs怎么构建，决定了这些配置能不能持久化。

我见过一个项目，工程师用buildroot生成镜像，rootfs选的是squashfs。

他每次改IP都得重新编译整个镜像，再烧录到设备上。

你想想看，这效率得多低？

所以，理解rootfs的类型，是根治网络配置问题的第一步。

1.4 三种常见的rootfs类型

类型	特点	网络配置能否持久化	典型场景
只读rootfs（squashfs）	压缩、只读、启动快	不能，除非使用overlay	路由器、IoT设备
可写rootfs（ext4）	可读写、空间大	能，但需注意掉电保护	开发板、工控机
临时rootfs（initramfs）	内存中运行、重启丢失	不能，需额外存储	安装盘、急救系统

你看，只有可写rootfs才能直接持久化网络配置。

其他两种，都需要额外的手段。

1.5 我的避坑指南

1.6 根治的思路：从rootfs层面解决问题

传统方法是在运行时改配置。根治的方法，是在构建rootfs时就设计好网络配置的持久化机制。

具体来说，有几种思路：

1. 使用overlay文件系统：下层是只读rootfs，上层是可写分区。网络配置改在上层，重启后还在。
2. 分离配置分区：把/etc/network等目录挂载到独立的数据分区（比如ubifs、ext4）。
3. 使用配置管理工具：比如uci（OpenWrt用的），配置存在独立分区，不依赖rootfs。
4. 构建时预置配置：在编译rootfs时就把网络配置写好，适合批量部署。

我个人比较推荐overlay方案。它灵活，而且对应用层透明。

你改配置的方式跟普通Linux一样，但底层已经帮你做好了持久化。

1.7 一张图看懂核心逻辑

下面这张图，展示了传统方法和根治方法的区别：

1.8 小结

网络配置的“根”，不在/etc，不在脚本，不在服务。

它在rootfs的构建方式里。

你只有理解了rootfs是只读的还是可写的，是临时的还是持久的，才能真正解决网络配置的持久化问题。

传统方法改的是“症状”，我们这门课要做的，是“根治”。

从下一章开始，我会带你一步步搭建一个支持网络配置持久化的rootfs。