KernelSU meta-overlayfs 快速上手模块装了不生效先装好这个再谈挂载【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU先说一个最常见的症状模块装好了重启也重启了脚本在跑sepolicy 和 system.prop 都生效唯独你想覆盖的/system文件还是原装的。问题基本可以锁定在这里——KernelSU 本身不做模块挂载挂载这件事被下放给一个叫元模块metamodule负责模块挂载的插件组件的附加组件而全新安装的 KernelSU 默认没有任何元模块模块的 system 目录自然永远不会叠到系统分区上。官方参考实现就是meta-overlayfs下面把它从判断、安装到验证、排错的完整路径走一遍。症状倒推模块装了到底卡在哪按模块用到的东西分三条线排查只用post-fs-data.sh、service.sh这类脚本 → 不依赖挂载不用查挂载链路用了 system 目录覆盖文件、去预装、整目录替换→ 必须确认元模块已激活元模块明明在列表里、也重启过唯独某个模块不生效 → 去该模块目录找skip_mount跳过挂载和disable禁用模块两个标记文件存在就删掉再重启website/docs/guide/faq.md 里为什么全新安装后模块不工作给出的结论和上面一致挂载相关的失效九成是元模块缺失或标记文件在挡路。动手前先判断你的模块到底需不需要挂载meta-overlayfs只对一种场景有意义——模块的改动落在系统分区上。对照一下模块里带 system 目录 → 必须装。挂载后它会被叠加到 system、vendor、product、system_ext、odm、oem 六个分区只有 shell 脚本 → 不需要脚本独立执行sepolicy.rule→ 不需要由 KernelSU 核心直接加载system.prop→ 不需要直接作为系统属性载入只用到后三样就可以跳过后面所有步骤。模块目录的完整结构参考 website/docs/guide/module.md。三步装完 meta-overlayfs 并重启装之前先确认设备上没有其他激活的元模块——KernelSU 同一时间只允许一个装第二个会被直接拦下这是防止两套挂载方案打架的单实例限制。下载meta-overlayfs.zip安装包打开 KernelSU Manager点右下角悬浮按钮➕选中刚下载的 zip确认安装然后重启设备重启后不需要任何手动操作在 post-fs-data文件系统就绪阶段元模块的挂载脚本自动执行把各模块的 system 目录以 systemless只叠加在表面、不改动原始分区的方式叠到对应分区上——相当于贴了层随时能撕的膜底下的/system原封不动。重启之后用四个检查确认挂载真的生效打开 Module 页面meta-overlayfs 出现在列表里且带元模块专属标识执行ls -l /data/adb/metamodule这个符号链接应指向元模块目录与 ID 无关排查当前激活的是谁最直接覆盖验证模块里与系统同名的文件读取到的应是模块侧内容删除验证用mknod filename c 0 0生成一个同名零字节占位符OverlayFS 会把原文件当作 whiteout用空占位符让原文件看起来没了处理原文件不可见而分区本身未变整目录替换还有两条路对模块内同名目录执行setfattr -n trusted.overlay.opaque -v y TARGET打上 opaque不合并的不透明目录标记该目录就只保留模块自己的内容或者偷懒在customize.sh里声明REMOVE/REPLACE列表KernelSU 会自动替你把 mknod 和 opaque 标记做掉。切换与卸载前绕开两个雷区想换成别的元模块单实例约束下唯一路径是卸载所有普通模块卸载当前元模块重启安装新的元模块重装普通模块再重启一次卸载元模块后所有模块立即失去挂载能力设备能正常开机但在装回新元模块之前任何模块改动都不会生效所以不换就别轻易动它。如果真踩了坑导致全部模块罢工最快的恢复动作就是装一个新的元模块。官方对执行顺序、符号链接机制和单实例约束的完整说明见 website/docs/guide/metamodule.md。现在就去 Module 页面确认 meta-overlayfs 出现在列表里带标识的那一个。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
阅读完成 · 觉得有帮助?