KernelSU 开机循环Bootloop救援指南安全模式、ksud 命令与 Recovery 手动清理全解【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU本指南聚焦 KernelSU 场景下设备变砖brick后的紧急救援手段覆盖刷写 boot 分区失败、模块导致无法开机两大典型故障并深入讲解 KernelSU 内置于内核的安全模式、ksud命令行模块管理以及 Recovery 手动清理等恢复路径。读完本文你将掌握一套从「轻量故障」到「彻底变砖」逐级递进的完整救援方法论并理解其背后的内核与用户空间实现原理。何时会发生变砖以及为什么大多可以救回在给设备刷写或更新 KernelSU 的过程中设备有可能进入无法正常开机的文镇化brick状态。好消息是只要问题出在boot 分区写入或模块安装这类可控操作上而不是物理硬件损坏绝大多数情况都可以通过正确的操作恢复。官方文档 rescue-from-bootloop.md含 中文版给出了完整的救援路线本文将其与仓库源码结合展开。刷写 boot 分区导致的变砖三种典型诱因在 KernelSU 中刷写 boot 分区导致设备无法启动通常由以下几种情况引起刷入了错误格式的 boot 镜像。例如设备的分区格式是gz却刷入了lz4格式的镜像内核无法解压设备自然起不来。设备需要禁用 AVB 校验才能正常启动。这类设备通常需要在刷写前擦除全部数据wipe data如果未按要求处理启动时校验失败即陷入循环。内核存在 bug 或与设备不兼容。自行编译或修改过的内核可能无法在该设备上正常引导。恢复方法刷回原厂 boot 镜像无论属于哪种情况恢复手段是统一的刷回原厂stockboot 镜像。因此官方文档在安装指南中强烈建议刷写之前先备份原厂 boot 分区。如果当时没有备份也可以从使用同型号设备的其他用户处获取或直接从官方固件factory firmware中提取原厂 boot。这一建议与 KernelSU 的安装方式直接相关无论是 GKI 还是非 GKI 设备KernelSU 都以 patch boot 镜像boot_patch.rs的方式注入因此保留一份原厂 boot 即可随时「撤销」整个 KernelSU 安装。模块导致的变砖先记住一条红线模块Module是导致设备变砖的最常见原因之一。模块以 root 权限运行可以改写系统分区、注入 init.rc、替换关键文件一旦来自不可信来源可能对设备造成不可逆的伤害。官方文档给出明确警告绝对不要安装未知来源的模块如果安装的是被证实安全、但恰好导致设备无法启动的模块那么 KernelSU 提供了内置的救援机制可以轻松恢复。普通模块导致的变砖使用安全模式Safe ModeKernelSU 内置了安全模式进入后Manager 模块页面中的所有模块都会被禁用但卸载操作仍然可用因此你可以借此移除导致问题的模块。安全模式有两种进入方式系统内置安全模式部分系统通过长按音量下键进入部分系统如 MIUI/HyperOS从 Recovery 中进入。进入系统安全模式后KernelSU 检测到系统安全模式标志也会自动禁用模块。KernelSU 内置安全模式在第一个开机画面出现之后连续快速按下音量下键 3 次以上。注意是按→松→按→松→按→松的连按不是长按。源码视角内核如何记住你的按键KernelSU 的内置安全模式实现在内核侧由输入事件钩子驱动因此不会因为事件被拦截而漏掉关键输入。核心逻辑位于 ksud_integration.cstatic unsigned int volumedown_pressed_count 0; static bool is_volumedown_enough(unsigned int count) { return count 3; } int ksu_handle_input_handle_event(unsigned int *type, unsigned int *code, int *value) { if (*type EV_KEY *code KEY_VOLUMEDOWN) { int val *value; if (val) { // key pressed, count it volumedown_pressed_count 1; if (is_volumedown_enough(volumedown_pressed_count)) { ksu_stop_input_hook_runtime(); } } } return 0; } bool ksu_is_safe_mode() { ... if (is_volumedown_enough(volumedown_pressed_count)) { // pressed over 3 times safe_mode true; return true; } return false; }可以看到内核统计KEY_VOLUMEDOWN的按下次数EV_KEY事件中value为真时计数达到 3 次即判定进入安全模式并立即停止输入钩子ksu_stop_input_hook_runtime()。ksu_is_safe_mode()的结果通过 supercall 暴露给用户空间见 dispatch.c 中的do_check_safemode。用户空间侧ksud在 utils.rs 中综合判断安全模式pub fn is_safe_mode() - bool { let safemode getprop(persist.sys.safemode) .as_ref() .is_some_and(|prop| prop 1) || getprop(ro.sys.safemode) .as_ref() .is_some_and(|prop| prop 1); if safemode { return true; } let safemode ksucalls::check_kernel_safemode(); safemode }即先检查系统属性persist.sys.safemode/ro.sys.safemode对应系统内置安全模式再通过 ksucalls.rs 中的check_kernel_safemode()查询内核判定结果对应KernelSU 内置安全模式。在 init_event.rs 的on_post_data_fs阶段ksud检测到安全模式后会跳过所有 post-fs-data 脚本并禁用全部模块module.rs 中的disable_all_modules()为每个模块目录写入禁用标记文件实现批量禁用。两个必须注意的时序问题官方文档特别提醒两点时序窗口很窄KernelSU 在内核模块初始化期间LKM 模式下内核执行 init 进程时注册音量键监听并在on_post_fs_data阶段开机动画之前注销。对应源码见 boot_event.con_post_fs_data()中调用ksu_stop_input_hook_runtime()停止输入钩子。因此必须在第一个开机画面出现后迅速连按 3 次音量下键如果设备启动过快或操作不及时安全模式可能不会被触发。init.rc 注入不受安全模式保护如果模块向 initrc 写入了不合理代码导致无法启动这些代码在安全模式下仍然会执行此时安全模式救不了你需要走下面的手动救援。手动救援两条路线如果安全模式无法解决问题可以根据设备当前状态选择以下两种手动方案。方法 1通过 ADB 使用 ksud 管理模块如果设备还能通过 ADB 获得 root shell可以直接用ksud命令行禁用或卸载问题模块adb shell su ksud module list # 列出所有模块 ksud module disable id # 禁用有问题的模块 ksud module uninstall id # 或直接卸载 reboot对应实现位于 module.rsdisable_module()L750-L764在模块目录下创建禁用标记文件uninstall_module()L702-L719则创建移除标记文件二者都会调用regenerate_preinit_rc()重新生成 preinit rc确保下次启动不再加载该模块。Recovery 模式下也能用挂载metadata与data分区后可以在 Recovery 模式下直接运行/data/adb/ksud来管理模块。由于 GKI 设备共享initKernelSU 内核模块在 Recovery 模式下仍会被加载因此ksud的大部分功能如功能开关配置可以正常使用。方法 2通过 Recovery 手动清理如果系统进不去、ADB 也连不上就需要借助第三方 Recovery如 TWRP。KernelSU 的模块加载依赖内核侧的 init.rc 注入文件与用户空间的 ksud 进程删除这些文件并重启后KernelSU 就不会再加载任何模块。操作步骤如下进入 Recovery如 TWRP。挂载 data 分区mount /data部分设备需要先解密 data 分区具体操作取决于设备与解密方式。删除 ksud阻止模块加载rm -f /data/adb/ksud可选挂载 metadata 分区删除模块生成的 init.rc 注入文件mount /metadata rm -f /metadata/ksu/modules.rc rm -f /metadata/watchdog/ksu/modules.rc重启设备reboot重启后 KernelSU 会跳过所有模块的加载进入系统后可以重新打开 KernelSU Manager 处理模块问题。源码佐证这些路径并非凭空而来。defs.rs 定义了常量PREINIT_DIR_DEFAULT /metadata/ksu/与MODULES_RC_FILE modules.rcmodule.rs 的注释说明modules.rc由所有已启用模块的*.rc文件拼接生成而 init_event.rs 提到会刷新/metadata/watchdog/ksu/modules.rc供下次启动的内核钩子读取。删除ksud可执行文件/data/adb/ksud与这些 rc 文件即从根本上切断了模块脚本被收集→注入 init.rc→随启动执行的链路。最后的底线格式化数据或送修如果以上所有方法都无法救回设备那么极大概率是所安装的模块存在恶意行为或已通过其他方式损坏了设备。此时官方文档给出的建议只有两条擦除数据并完整刷回官方系统wipe data 刷入官方固件。联系售后after-sales服务。这条底线意味着对于任何 root 方案而言备份原厂 boot、只安装可信来源的模块永远是成本最低的保险——它能让绝大多数变砖在几分钟内原地复活而不是走到格式化甚至送修这一步。小结按故障等级选择救援手段故障场景首选方案备选方案刷错 boot 镜像 / 内核不兼容刷回原厂 boot 镜像从同型号用户或官方固件获取原厂 boot可信模块导致无法开机KernelSU 安全模式开机画面后连按 3 次音量下键系统安全模式MIUI/HyperOS 等安全模式无效可进 ADBksud module disable/uninstallRecovery 下运行/data/adb/ksud系统与 ADB 均不可用Recovery 删除/data/adb/ksud与 modules.rc擦数据刷官方系统 / 送修恶意模块或数据损坏擦数据刷官方系统联系售后救援逻辑自下而上层层递进先尝试最轻量的安全模式再尝试命令行管理最后才是 Recovery 手动清理与格式化重刷。理解ksud、modules.rc与内核安全模式钩子的实现位置ksud_integration.c、boot_event.c、init_event.rs、module.rs你就能在任何 Rescue 场景下快速定位问题、选择正确的恢复路径。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 KernelSU 开机循环（Bootloop）救援指南：安全模式、ksud 命令与 Recovery 手动清理全解
KernelSU 开机循环Bootloop救援指南安全模式、ksud 命令与 Recovery 手动清理全解【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU本指南聚焦 KernelSU 场景下设备变砖brick后的紧急救援手段覆盖刷写 boot 分区失败、模块导致无法开机两大典型故障并深入讲解 KernelSU 内置于内核的安全模式、ksud命令行模块管理以及 Recovery 手动清理等恢复路径。读完本文你将掌握一套从「轻量故障」到「彻底变砖」逐级递进的完整救援方法论并理解其背后的内核与用户空间实现原理。何时会发生变砖以及为什么大多可以救回在给设备刷写或更新 KernelSU 的过程中设备有可能进入无法正常开机的文镇化brick状态。好消息是只要问题出在boot 分区写入或模块安装这类可控操作上而不是物理硬件损坏绝大多数情况都可以通过正确的操作恢复。官方文档 rescue-from-bootloop.md含 中文版给出了完整的救援路线本文将其与仓库源码结合展开。刷写 boot 分区导致的变砖三种典型诱因在 KernelSU 中刷写 boot 分区导致设备无法启动通常由以下几种情况引起刷入了错误格式的 boot 镜像。例如设备的分区格式是gz却刷入了lz4格式的镜像内核无法解压设备自然起不来。设备需要禁用 AVB 校验才能正常启动。这类设备通常需要在刷写前擦除全部数据wipe data如果未按要求处理启动时校验失败即陷入循环。内核存在 bug 或与设备不兼容。自行编译或修改过的内核可能无法在该设备上正常引导。恢复方法刷回原厂 boot 镜像无论属于哪种情况恢复手段是统一的刷回原厂stockboot 镜像。因此官方文档在安装指南中强烈建议刷写之前先备份原厂 boot 分区。如果当时没有备份也可以从使用同型号设备的其他用户处获取或直接从官方固件factory firmware中提取原厂 boot。这一建议与 KernelSU 的安装方式直接相关无论是 GKI 还是非 GKI 设备KernelSU 都以 patch boot 镜像boot_patch.rs的方式注入因此保留一份原厂 boot 即可随时「撤销」整个 KernelSU 安装。模块导致的变砖先记住一条红线模块Module是导致设备变砖的最常见原因之一。模块以 root 权限运行可以改写系统分区、注入 init.rc、替换关键文件一旦来自不可信来源可能对设备造成不可逆的伤害。官方文档给出明确警告绝对不要安装未知来源的模块如果安装的是被证实安全、但恰好导致设备无法启动的模块那么 KernelSU 提供了内置的救援机制可以轻松恢复。普通模块导致的变砖使用安全模式Safe ModeKernelSU 内置了安全模式进入后Manager 模块页面中的所有模块都会被禁用但卸载操作仍然可用因此你可以借此移除导致问题的模块。安全模式有两种进入方式系统内置安全模式部分系统通过长按音量下键进入部分系统如 MIUI/HyperOS从 Recovery 中进入。进入系统安全模式后KernelSU 检测到系统安全模式标志也会自动禁用模块。KernelSU 内置安全模式在第一个开机画面出现之后连续快速按下音量下键 3 次以上。注意是按→松→按→松→按→松的连按不是长按。源码视角内核如何记住你的按键KernelSU 的内置安全模式实现在内核侧由输入事件钩子驱动因此不会因为事件被拦截而漏掉关键输入。核心逻辑位于 ksud_integration.cstatic unsigned int volumedown_pressed_count 0; static bool is_volumedown_enough(unsigned int count) { return count 3; } int ksu_handle_input_handle_event(unsigned int *type, unsigned int *code, int *value) { if (*type EV_KEY *code KEY_VOLUMEDOWN) { int val *value; if (val) { // key pressed, count it volumedown_pressed_count 1; if (is_volumedown_enough(volumedown_pressed_count)) { ksu_stop_input_hook_runtime(); } } } return 0; } bool ksu_is_safe_mode() { ... if (is_volumedown_enough(volumedown_pressed_count)) { // pressed over 3 times safe_mode true; return true; } return false; }可以看到内核统计KEY_VOLUMEDOWN的按下次数EV_KEY事件中value为真时计数达到 3 次即判定进入安全模式并立即停止输入钩子ksu_stop_input_hook_runtime()。ksu_is_safe_mode()的结果通过 supercall 暴露给用户空间见 dispatch.c 中的do_check_safemode。用户空间侧ksud在 utils.rs 中综合判断安全模式pub fn is_safe_mode() - bool { let safemode getprop(persist.sys.safemode) .as_ref() .is_some_and(|prop| prop 1) || getprop(ro.sys.safemode) .as_ref() .is_some_and(|prop| prop 1); if safemode { return true; } let safemode ksucalls::check_kernel_safemode(); safemode }即先检查系统属性persist.sys.safemode/ro.sys.safemode对应系统内置安全模式再通过 ksucalls.rs 中的check_kernel_safemode()查询内核判定结果对应KernelSU 内置安全模式。在 init_event.rs 的on_post_data_fs阶段ksud检测到安全模式后会跳过所有 post-fs-data 脚本并禁用全部模块module.rs 中的disable_all_modules()为每个模块目录写入禁用标记文件实现批量禁用。两个必须注意的时序问题官方文档特别提醒两点时序窗口很窄KernelSU 在内核模块初始化期间LKM 模式下内核执行 init 进程时注册音量键监听并在on_post_fs_data阶段开机动画之前注销。对应源码见 boot_event.con_post_fs_data()中调用ksu_stop_input_hook_runtime()停止输入钩子。因此必须在第一个开机画面出现后迅速连按 3 次音量下键如果设备启动过快或操作不及时安全模式可能不会被触发。init.rc 注入不受安全模式保护如果模块向 initrc 写入了不合理代码导致无法启动这些代码在安全模式下仍然会执行此时安全模式救不了你需要走下面的手动救援。手动救援两条路线如果安全模式无法解决问题可以根据设备当前状态选择以下两种手动方案。方法 1通过 ADB 使用 ksud 管理模块如果设备还能通过 ADB 获得 root shell可以直接用ksud命令行禁用或卸载问题模块adb shell su ksud module list # 列出所有模块 ksud module disable id # 禁用有问题的模块 ksud module uninstall id # 或直接卸载 reboot对应实现位于 module.rsdisable_module()L750-L764在模块目录下创建禁用标记文件uninstall_module()L702-L719则创建移除标记文件二者都会调用regenerate_preinit_rc()重新生成 preinit rc确保下次启动不再加载该模块。Recovery 模式下也能用挂载metadata与data分区后可以在 Recovery 模式下直接运行/data/adb/ksud来管理模块。由于 GKI 设备共享initKernelSU 内核模块在 Recovery 模式下仍会被加载因此ksud的大部分功能如功能开关配置可以正常使用。方法 2通过 Recovery 手动清理如果系统进不去、ADB 也连不上就需要借助第三方 Recovery如 TWRP。KernelSU 的模块加载依赖内核侧的 init.rc 注入文件与用户空间的 ksud 进程删除这些文件并重启后KernelSU 就不会再加载任何模块。操作步骤如下进入 Recovery如 TWRP。挂载 data 分区mount /data部分设备需要先解密 data 分区具体操作取决于设备与解密方式。删除 ksud阻止模块加载rm -f /data/adb/ksud可选挂载 metadata 分区删除模块生成的 init.rc 注入文件mount /metadata rm -f /metadata/ksu/modules.rc rm -f /metadata/watchdog/ksu/modules.rc重启设备reboot重启后 KernelSU 会跳过所有模块的加载进入系统后可以重新打开 KernelSU Manager 处理模块问题。源码佐证这些路径并非凭空而来。defs.rs 定义了常量PREINIT_DIR_DEFAULT /metadata/ksu/与MODULES_RC_FILE modules.rcmodule.rs 的注释说明modules.rc由所有已启用模块的*.rc文件拼接生成而 init_event.rs 提到会刷新/metadata/watchdog/ksu/modules.rc供下次启动的内核钩子读取。删除ksud可执行文件/data/adb/ksud与这些 rc 文件即从根本上切断了模块脚本被收集→注入 init.rc→随启动执行的链路。最后的底线格式化数据或送修如果以上所有方法都无法救回设备那么极大概率是所安装的模块存在恶意行为或已通过其他方式损坏了设备。此时官方文档给出的建议只有两条擦除数据并完整刷回官方系统wipe data 刷入官方固件。联系售后after-sales服务。这条底线意味着对于任何 root 方案而言备份原厂 boot、只安装可信来源的模块永远是成本最低的保险——它能让绝大多数变砖在几分钟内原地复活而不是走到格式化甚至送修这一步。小结按故障等级选择救援手段故障场景首选方案备选方案刷错 boot 镜像 / 内核不兼容刷回原厂 boot 镜像从同型号用户或官方固件获取原厂 boot可信模块导致无法开机KernelSU 安全模式开机画面后连按 3 次音量下键系统安全模式MIUI/HyperOS 等安全模式无效可进 ADBksud module disable/uninstallRecovery 下运行/data/adb/ksud系统与 ADB 均不可用Recovery 删除/data/adb/ksud与 modules.rc擦数据刷官方系统 / 送修恶意模块或数据损坏擦数据刷官方系统联系售后救援逻辑自下而上层层递进先尝试最轻量的安全模式再尝试命令行管理最后才是 Recovery 手动清理与格式化重刷。理解ksud、modules.rc与内核安全模式钩子的实现位置ksud_integration.c、boot_event.c、init_event.rs、module.rs你就能在任何 Rescue 场景下快速定位问题、选择正确的恢复路径。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考