常见问题排查

约 2470 字大约 8 分钟

先别把所有开关都拨一遍。YukiSU 有 LKM、管理器认证、ksud、普通模块、MetaModule 和 YukiZygisk 好几层；找错层，日志看得再多也只是在绕路。

先把问题归类

现象	最可能的层级	第一份证据
设备刷入后无法启动	启动镜像、分区、槽位或 LKM	刷写记录、原厂镜像、bootloader 状态
系统能启动，管理器显示未安装	LKM 未加载或启动链没有生效	管理器首页、完整内核日志
显示已安装，但管理器无权限	包名/签名或 SuperKey 认证	认证模式、APK 来源、设备时间
Root 可用，模块脚本不运行	`ksud`、安全模式或模块状态	`ksud` 版本、模块状态、启动日志
脚本运行，但系统文件没出现	MetaModule 或 mount namespace	MetaModule 状态、`metamount.sh` 日志
普通模块正常，Zygisk 模块无效	YukiZygisk、ABI 或目标进程	管理器导出的 YukiZygisk 诊断
更新后才出现异常	版本组合或待处理状态	更新前后版本、第一条错误、变更清单

挑最像的一行往下查。名字里有 “SU”，不代表模块 WebUI 打不开也得怪内核。

收集最小环境信息

如果设备还能正常进入 Android，并且 ADB 已经授权，可以先用只读命令记录基本信息：

adb shell getprop ro.product.cpu.abi
adb shell uname -a
adb shell getprop ro.build.fingerprint
adb shell getprop ro.boot.slot_suffix

同时从管理器首页记录：

YukiSU / LKM 完整版本；
内核版本与 Hook 状态；
管理器版本；
内置与已安装 ksud 版本；
当前认证方式；
MetaModule、YukiZygisk 与安全模式状态。

日志先找第一条直接错误。后面几十行红字，很多只是前面那一处失败后的连锁反应。

LKM 无法加载

现象

管理器显示 YukiSU 未安装；
LKM 版本为空或无法读取；
刷入后系统仍能启动，但没有任何 YukiSU 内核能力；
内核日志出现 module、vermagic、symbol 或 relocation 相关错误。

排查顺序

确认设备范围：ARM64、GKI 2.0、Linux 5.10 及以上；
确认实际启动镜像：修补的是当前固件、当前启动路径使用的镜像；
确认槽位：A/B 设备当前启动槽位与写入槽位符合计划；
确认 KMI：LKM 与目标内核 KMI、符号版本和构建配置一致；
确认内核能力：Kprobes、Kretprobes、syscall tracepoints 可用；
查看首条内核错误：不要只截取最后一行 “failed”；
回到已知良好状态：如果无法确定输入镜像，先恢复匹配的原厂镜像重新判断。

不要这样做

不要强制加载不匹配 .ko；
不要关闭模块版本或符号检查来“试试看”；
不要把另一台同机型设备的 LKM 直接视为兼容；
不要在不清楚活动槽位时连续对两个槽位写入。

版本检查把不匹配的 .ko 挡在门外，其实是在帮你。强行绕过，只会把一条清楚的“拒绝加载”换成更晚、更难救的内核故障。

管理器显示已安装但无法认证

首页连 LKM 版本都读不到，先查加载；能读到版本、授权页面却进不去，才重点查认证。别把这两个问题混在一起。

使用默认签名认证

APK 是否来自 YukiSU Releases；
包名与 APK 签名是否保持官方预期；
LKM 是否来自同一项目，而不是其他 KernelSU 分支；
是否曾在安装时启用“禁用 APK 签名验证”。

使用 SuperKey

LKM 构建是否包含 CONFIG_KSU_SUPERKEY=y；
输入密钥是否与编译或修补时写入的一致；
设备日期和时间是否明显错误；
请求是否落在认证允许的时间窗口；
是否把全角字符、前后空格或不同编码误当成同一密钥。

不要公开 SuperKey、带密钥的修补参数或包含密钥的 LKM 构建日志。忘记密钥且签名认证已被禁用时，应重新修补并安装一个信任配置明确的 LKM。

Root 请求没有弹窗或被拒绝

确认管理器已经认证，而不是只安装了 APK；
检查应用是否出现在超级用户列表，授权是否被明确拒绝；
检查请求是否来自预期包名、UID 与进程；
暂时恢复该应用的默认 App Profile，排除错误身份或 SELinux domain；
检查 sulog 或相关诊断中的调用方和结果；
彻底结束目标应用后重新测试新的 su 请求。

改完授权后要重新发起 su。已经拿到 Root 的进程不会看见你点了“拒绝”就自觉降权。

`ksud` 版本不一致

管理器 APK 内置一份 ksud，设备的 /data/adb/ksud 是另一份已安装状态。常见现象包括：

管理器能认证，但模块操作或工具失败；
首页提示内置与已安装版本不同；
更新管理器后，新功能显示但后端命令不认识；
启动日志提示 UAPI 或版本不匹配。

先记下两边完整版本，再按发布说明决定是否同步。别从别的分支抓一个也叫 ksud 的文件覆盖过去；文件名一样，不代表它们说同一种协议。

模块脚本没有运行

依次确认：

模块不是禁用、待卸载或待更新状态；
YukiSU 没有进入会禁用全部模块的安全模式；
模块脚本使用 Unix 换行、正确 shebang，并且安装后权限合理；
post-fs-data.sh 没有等待尚未启动的 framework 或网络；
ksud 与 LKM UAPI 没有版本错配；
启动日志中能看到对应阶段开始与模块错误。

如果某个脚本必须依赖挂载后的文件，应移动到 post-mount 或更晚阶段，而不是在 post-fs-data 中假定 MetaModule 已完成。

模块安装成功但文件没有挂载

先确认模块确实需要挂载

模块只有脚本、system.prop 或 sepolicy.rule 时，本来就可能没有系统文件挂载。检查模块是否包含 system/ 文件树，以及是否存在 skip_mount。

再确认 MetaModule

只存在一个活动 MetaModule；
没有 disable、待更新或待卸载状态；
MetaModule 遵循上游接口，且具体后端支持当前设备与普通模块需求；
post-fs-data.sh 和 metamount.sh 没有失败；
普通模块安装时的 metainstall.sh 处理没有报错。

最后确认 namespace

Root shell 看得到、只有目标应用看不到，八成要查 namespace 或模块卸载策略。到处都看不到，才更像 MetaModule 根本没挂成功。

不要同时更换 MetaModule、更新普通模块和修改卸载策略；一次只改变一个变量。

模块导致系统异常或启动变慢

从最近安装或更新的模块开始禁用；
一次只处理一个怀疑对象；
检查 post-fs-data.sh 是否阻塞；
检查 service.sh 是否创建崩溃重启循环；
检查多个模块是否覆盖同一目标文件；
必要时进入 YukiSU 安全模式，让普通模块全部禁用。

安全模式一开就正常，模块层嫌疑最大；安全模式也救不了，再看 LKM、启动镜像或系统本身。

YukiZygisk 已启用但模块无效

“开关打开”“发现模块”“已经注入”“模块真有用”是四步，别看到第二步就宣布兼容成功。

确认普通 Root 与 MetaModule 环境本身稳定；
确认 YukiZygisk 没有进入安全模式；
确认 64 位/32 位目标与模块 ABI 匹配；
确认模块支持当前 Android、目标应用与目标进程；
只保留一个待测试 Zygisk 模块并完整重启；
在目标应用启动后查看当前注入目标；
从管理器导出 YukiZygisk 诊断，而不是只复制实时日志最后几行。

Zygote 连崩 3 次后，YukiZygisk 会停下注入。先关掉最近加的模块，再退出安全模式；反复强制打开，只是在让它按同样方式再崩一次。

更新后功能异常

按版本层拆分检查：

只更新了管理器 APK？
是否同步了设备侧 ksud？
LKM 是否也改变？KMI 是否相同？
MetaModule 是否处于待更新状态？
普通模块或 YukiZygisk 模块是否同时更新？

最有价值的结论是：“这套版本原本正常，只改了 X 就坏了。”一次把 APK、ksud、LKM 和模块全更新，再说“最新版坏了”，谁都只能靠猜。

设备无法启动

别继续乱刷，也别随机切槽位。先记下最后改了哪份镜像、哪个分区、哪个槽位，再按救砖与恢复回到确定能启动的状态。

如果问题发生在安装普通模块之后，优先尝试安全模式或禁用最近模块；如果发生在刷写 LKM 后且 Android 从未启动成功，应优先恢复原厂镜像，而不是从模块层排查。

提交问题前

一份可用的问题报告至少包含：

设备型号、Android 构建指纹、内核版本与架构；
YukiSU LKM、管理器、内置/已安装 ksud 完整版本；
安装方式、实际分区与槽位；
MetaModule 和相关模块版本；
问题出现前最后一次改动；
可重复的最短步骤；
第一条有效错误与完整诊断附件；
已做过的单变量排除结果。

分享日志前移除 SuperKey、个人路径、账号标识和不必要的应用数据。更多建议见如何有效提问。

版权所有

版权归属：Anatdx

许可证：署名-非商业性-相同方式共享 4.0 国际 (CC-BY-NC-SA-4.0)