给 /system 动刀子：KernelSU meta-overlayfs 元模块三步装好并验证生效
【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU
你删掉一个预装应用，重启，它又原样复活。因为 /system 是只读分区，文件根本没被动过。KernelSU meta-overlayfs 就是干这个的：它把模块里的 system 目录叠加到 /system 等系统分区上，覆盖、删除都能做，而真实分区一个字节都不改。这篇把底层原理、三步安装、验证与排障一次讲清。
先搞清楚：它到底做了什么
KernelSU 核心不亲自挂载，这事交给元模块——负责模块挂载的插件组件。官方参考实现 meta-overlayfs 会在开机 post-fs-data 阶段，以 systemless（叠加在表面、不改动原始分区）方式，把所有启用模块的 system 目录叠加到 /system、/vendor、/product、/system_ext、/odm、/oem 等分区上。好比给分区贴了层可撕的膜，随时撕掉，底层还是原装。
核心为什么不肯碰挂载？理由简单：内核里的挂载点越少，被检测到的面越小。挂载策略全交给插件，社区想换方案不用 fork KernelSU。元模块脚本的优先级还高于普通模块脚本，保证它先跑完。更多架构细节见元模块指南。
两个关键机制要记牢：
whiteout（用空占位符让原文件"看起来没了"）：生成同名零字节占位符，OverlayFS 会把原文件当作已删除。"去预装"就是靠它实现的。
mknod filename c 0 0opaque（标记目录不合并）：打上标记后，系统里同名目录不再参与合并，你看到的只有模块自己的文件，整目录替换常这么干。
setfattr -n trusted.overlay.opaque -v y <TARGET>
内核侧判断一个模块挂不挂，看的是模块挂载检查逻辑：只要存在system目录且没有skip_mount，就具备叠加资格。没有元模块的新装环境，模块的 system 目录一个都不会被挂载——这是最容易被忽视的前提。
我的模块到底需不需要它
不是每个模块都得配元模块。判断很简单：模块的改动最终要落到系统分区的文件上，才需要；全是脚本和属性，就不需要。对照下表：
| 模块用到的能力 | 是否需要 | 为什么 |
|---|---|---|
| 覆盖 /system 下的文件（换应用、去预装、整目录替换） | 需要 | system 目录必须靠元模块挂载才生效 |
| 只用开机脚本（post-fs-data.sh、service.sh 等） | 不需要 | 脚本独立执行，与挂载无关 |
| sepolicy.rule | 不需要 | KernelSU 核心直接加载 |
| system.prop | 不需要 | 直接作为系统属性载入 |
一句话：模块只用脚本、sepolicy.rule、system.prop 时，可以跳过元模块安装。如果你拿不准，就看模块目录里有没有 system 这一项：有，就装；没有，就省了。目录完整结构参考模块指南。
动手：三步装好
1. 准备
下载 meta-overlayfs 的 ZIP 包（meta-overlayfs.zip），官方参考实现，还支持 ext4 镜像读写层。装前务必确认设备上没有其他激活的元模块——KernelSU 同一时间只允许一个激活，装第二个会被直接拦下。⚠️
2. 安装
打开 KernelSU Manager，点页面上的悬浮加号按钮，选中刚下载的 ZIP，确认安装。整个过程约十秒，真正的等待在重启那一步。
3. 重启
重启设备，等待开机完成。此时元模块的挂载脚本已在 post-fs-data 阶段执行完毕，各模块的 system 目录已叠加到对应分区。
装完别急着走：确认它真的在工作
挂载脚本跑过了，可到底成没成？逐项过下面六项，全过才算数：
| 验证目标 | 操作或查看位置 | 预期结果 |
|---|---|---|
| 元模块标识 | KernelSU Manager 的 Module 页面 | meta-overlayfs 在列表里且带元模块标识 |
| 当前激活的是谁 | 查看符号链接/data/adb/metamodule | 指向元模块目录，实现见元模块管理 |
| 同名覆盖 | 读一个与系统同名的文件 | 内容是模块侧的 |
| whiteout 删除 | mknod filename c 0 0生成的同名占位符处 | 原文件不可见，/system 分区未变 |
| opaque 整目录替换 | 执行setfattr -n trusted.overlay.opaque -v y <TARGET>后 | 该目录内容全部来自模块侧 |
| 懒人做法 | 在customize.sh里声明REMOVE/REPLACE列表 | 占位符与 opaque 标记自动生成 |
符号链接这项最实用：不管元模块 ID 怎么变，这条路径永远指向当前激活的那个，排查问题时先看它。
翻车了怎么办：四个高频问题逐个拆
装第二个元模块被拒现象：安装第二个元模块时被直接拦下。 根因：单实例限制，防止两套挂载方案打架，这是设计出来的保护。 处理：卸载所有普通模块 → 卸载当前元模块 → 重启 → 装新的 → 重装普通模块 → 再重启。
卸载元模块后全部模块罢工现象：设备照常开机，但模块做的改动全部失效。 根因：卸掉的瞬间，所有模块都丢掉叠加能力。 处理：尽快装一个新的元模块；不换就不轻易卸载。
某个模块不挂载现象：元模块在列，只有这个模块的 system 文件夹没被叠上去。 根因：模块目录里存在skip_mount（跳过挂载）或disable（禁用模块）标记文件。 处理：删掉对应标记再重启。
装完 meta-overlayfs 仍不生效现象：重启了好几回，覆盖和删除都没体现。 根因：多半是元模块没进列表，或踩了上一条的 skip_mount 标记。 处理：先回模块页面确认元模块在列，再查标记；FAQ 里"为什么全新安装后模块不工作"的回答与此一致。
元模块就是模块改动 /system 的开关。装好它、确认它在列，挂载自然发生。
【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
