如何让 KernelSU 模块真正覆盖 /systemmeta-overlayfs 元模块快速详解【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU装好重启后模块的system目录会被无感叠加到/system上生效而分区本身原封不动——这正是 KernelSU 的元模块meta-overlayfs为你做到的。本文先用三分钟讲清原理再带你装好并逐项自查。它到底怎么工作systemless 覆盖 /system 的三个概念先说元模块KernelSU 把模块挂载逻辑从内核核心剥离做成了独立可插拔的模块即metamodule。为什么这么拆挂载逻辑留在核心里核心就既是容易暴露的检测点也不好演进拆出去之后攻击面更小社区也能在不 fork 核心的前提下实现不同挂载方案。附带一条硬规则没装元模块时任何模块都不会被挂载。再说OverlayFSLinux 内核自带的分层文件系统把多层目录叠加成一个视图——原系统目录在底层模块的system目录在上层读文件时上层自动压过底层。meta-overlayfs就是官方参考实现用内核 OverlayFS 驱动这套叠加还可用 ext4 镜像modules.img存放模块文件覆盖 system、vendor、product、system_ext、odm、oem 多个分区。最后说systemless改动而不修改。应用看到的是合并后的视图磁盘上/system分区纹丝不动重刷 ROM 后修改自动消失。也就是说你改的是系统的视图不是系统本身。模块能力是否需要元模块system目录覆盖systemless 覆盖 /system、vendor 等需要post-fs-data.sh、service.sh 等启动脚本不需要sepolicy.rule不需要system.prop不需要initrc 注入、模块配置、WebUI不需要换句话说只有要动/system文件的模块才必须装元模块脚本类、策略类、属性类模块由 KernelSU 核心直接处理。安装实操从 ZIP 到生效的 5 步元模块的安装方式和普通模块完全相同不需要额外刷机工具前提只是 KernelSU 已装好且 Manager 里能看到 root 状态。为什么装完必须重启挂载发生在内核早期启动的 post-fs-data 阶段运行中的系统安装完根本不会走这个流程。下载 ZIP。把meta-overlayfs.zip存到设备能访问的目录——官方参考实现基于内核 OverlayFS 挂载。打开 Manager 点安装。进入 KernelSU Manager 应用点安装悬浮按钮进入安装流程。选择 ZIP 并确认。内置安装器会自动解压并放到/data/adb/modules下。重启并等待。开机过程中 post-fs-data 阶段会执行挂载脚本别在半途强杀系统。自查。打开 Module 页面看模块列表激活的元模块带专属标识下一节细说。也就是说你只动手两次装包、重启其余都是安装器的事。重启后自查清单模块挂载不生效就查这三步重启不等于一定成功按顺序核对以下三项元模块出现在列表里Manager 的 Module 页面中当前激活的元模块会显示在模块列表里带特殊的元模块标识。看不到它说明安装没落地回到上一步。目标模块没有标记文件模块目录下存在skip_mount表示该模块跳过挂载存在disable表示模块已禁用。两个文件有一个在system目录就不会被挂载。实际效果符合预期与系统同名的文件被覆盖、同名目录被合并。注意删除和整目录替换要额外操作删除需在模块内用mknod filename c 0 0建同名占位OverlayFS 会把它当作whiteout删除标记处理整目录替换则对同名目录执行setfattr -n trusted.overlay.opaque -v y TARGET或在customize.sh里声明REMOVE/REPLACE变量交给 KernelSU 自动处理。为什么删除必须走 mknod因为 OverlayFS 没有直接删除语义上层只能给文件打隐藏标记字符设备占位就是那个标记/system分区本身始终不变。换装与卸载元模块的坑⚠️ 元模块生命周期里有三个坑都直说同一时间只能装一个。装第二个会被 KernelSU 直接阻止。为什么卡这么死两套挂载逻辑会争抢同一批分区挂载点冲突后行为不可预测干脆从入口拦掉。卸载的副作用是全局的。卸载元模块影响所有模块此后所有模块都不会再被挂载设备能正常开机但全部文件修改停止生效。也就是说机器能用模块集体变成摆设换装新的元模块前都是这个状态。切换顺序别省步骤。卸载所有普通模块 → 卸载当前元模块 → 重启 → 安装新元模块 → 重装普通模块 → 再重启。中间两次重启不能省否则旧挂载状态可能残留。分不清当前激活的是谁元模块安装后 KernelSU 会创建符号链接/data/adb/metamodule指向/data/adb/modules/元模块ID。这是一条与 ID 无关的稳定路径排查时看它指向哪里就知道当前激活的是哪个元模块。延伸阅读为什么把链接放最后因为挂载钩子和生命周期细节展开起来太细放这里会打断主线元模块指南 里有metamodule1属性和metamount.sh等全部开发者钩子模块指南 讲清目录结构与各脚本阶段挂载机制的其他疑问可以看 FAQ还没装完 KernelSU 的新手先把 安装指南 走一遍。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
如何让 KernelSU 模块真正覆盖 /systemmeta-overlayfs 元模块快速详解【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU装好重启后模块的system目录会被无感叠加到/system上生效而分区本身原封不动——这正是 KernelSU 的元模块meta-overlayfs为你做到的。本文先用三分钟讲清原理再带你装好并逐项自查。它到底怎么工作systemless 覆盖 /system 的三个概念先说元模块KernelSU 把模块挂载逻辑从内核核心剥离做成了独立可插拔的模块即metamodule。为什么这么拆挂载逻辑留在核心里核心就既是容易暴露的检测点也不好演进拆出去之后攻击面更小社区也能在不 fork 核心的前提下实现不同挂载方案。附带一条硬规则没装元模块时任何模块都不会被挂载。再说OverlayFSLinux 内核自带的分层文件系统把多层目录叠加成一个视图——原系统目录在底层模块的system目录在上层读文件时上层自动压过底层。meta-overlayfs就是官方参考实现用内核 OverlayFS 驱动这套叠加还可用 ext4 镜像modules.img存放模块文件覆盖 system、vendor、product、system_ext、odm、oem 多个分区。最后说systemless改动而不修改。应用看到的是合并后的视图磁盘上/system分区纹丝不动重刷 ROM 后修改自动消失。也就是说你改的是系统的视图不是系统本身。模块能力是否需要元模块system目录覆盖systemless 覆盖 /system、vendor 等需要post-fs-data.sh、service.sh 等启动脚本不需要sepolicy.rule不需要system.prop不需要initrc 注入、模块配置、WebUI不需要换句话说只有要动/system文件的模块才必须装元模块脚本类、策略类、属性类模块由 KernelSU 核心直接处理。安装实操从 ZIP 到生效的 5 步元模块的安装方式和普通模块完全相同不需要额外刷机工具前提只是 KernelSU 已装好且 Manager 里能看到 root 状态。为什么装完必须重启挂载发生在内核早期启动的 post-fs-data 阶段运行中的系统安装完根本不会走这个流程。下载 ZIP。把meta-overlayfs.zip存到设备能访问的目录——官方参考实现基于内核 OverlayFS 挂载。打开 Manager 点安装。进入 KernelSU Manager 应用点安装悬浮按钮进入安装流程。选择 ZIP 并确认。内置安装器会自动解压并放到/data/adb/modules下。重启并等待。开机过程中 post-fs-data 阶段会执行挂载脚本别在半途强杀系统。自查。打开 Module 页面看模块列表激活的元模块带专属标识下一节细说。也就是说你只动手两次装包、重启其余都是安装器的事。重启后自查清单模块挂载不生效就查这三步重启不等于一定成功按顺序核对以下三项元模块出现在列表里Manager 的 Module 页面中当前激活的元模块会显示在模块列表里带特殊的元模块标识。看不到它说明安装没落地回到上一步。目标模块没有标记文件模块目录下存在skip_mount表示该模块跳过挂载存在disable表示模块已禁用。两个文件有一个在system目录就不会被挂载。实际效果符合预期与系统同名的文件被覆盖、同名目录被合并。注意删除和整目录替换要额外操作删除需在模块内用mknod filename c 0 0建同名占位OverlayFS 会把它当作whiteout删除标记处理整目录替换则对同名目录执行setfattr -n trusted.overlay.opaque -v y TARGET或在customize.sh里声明REMOVE/REPLACE变量交给 KernelSU 自动处理。为什么删除必须走 mknod因为 OverlayFS 没有直接删除语义上层只能给文件打隐藏标记字符设备占位就是那个标记/system分区本身始终不变。换装与卸载元模块的坑⚠️ 元模块生命周期里有三个坑都直说同一时间只能装一个。装第二个会被 KernelSU 直接阻止。为什么卡这么死两套挂载逻辑会争抢同一批分区挂载点冲突后行为不可预测干脆从入口拦掉。卸载的副作用是全局的。卸载元模块影响所有模块此后所有模块都不会再被挂载设备能正常开机但全部文件修改停止生效。也就是说机器能用模块集体变成摆设换装新的元模块前都是这个状态。切换顺序别省步骤。卸载所有普通模块 → 卸载当前元模块 → 重启 → 安装新元模块 → 重装普通模块 → 再重启。中间两次重启不能省否则旧挂载状态可能残留。分不清当前激活的是谁元模块安装后 KernelSU 会创建符号链接/data/adb/metamodule指向/data/adb/modules/元模块ID。这是一条与 ID 无关的稳定路径排查时看它指向哪里就知道当前激活的是哪个元模块。延伸阅读为什么把链接放最后因为挂载钩子和生命周期细节展开起来太细放这里会打断主线元模块指南 里有metamodule1属性和metamount.sh等全部开发者钩子模块指南 讲清目录结构与各脚本阶段挂载机制的其他疑问可以看 FAQ还没装完 KernelSU 的新手先把 安装指南 走一遍。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
