刷完第三方恢复模式,重启进系统转一圈,再关机按组合键——原厂恢复界面又回来了。这个场景在老机器玩家圈子里几乎是入门必修课,尤其是 MIUI 11 这一代设备,很多人第一次尝试永久固定刷入 TWRP 时都会遇到同样的问题:镜像明明刷进去了,fastboot flash recovery也返回了 OKAY,可就是用不了几次就被系统悄悄换回去。另一边,无密 data 分区的处理更是容易翻车,顺序错一步,轻则开机卡 logo,重则内部存储全清、传感器校准丢失。这篇就把这套流程从头到尾拆一遍:TWRP 为什么会被回写、永久固定到底固定的是什么、无密 data 分区改的是哪一层配置、格式化与改 fstab 的先后顺序为什么不能颠倒,以及刷完之后那几类高频故障该怎么按顺序排查。适合已经解锁 bootloader、手头有一台 MIUI 11 老机器、想把恢复模式和 data 加密状态彻底掌握在自己手里的玩家,也适合刚入门、想少走几遍弯路的新手。
1. 老机器上TWRP“刷了又没”的真相:recovery分区被系统回写的机制
很多人把“刷入 TWRP”理解成一个一次性动作:镜像写进 recovery 分区,事情就结束了。实际并不是。在 MIUI 11 这一代设备的启动链路里,recovery 分区属于“可被系统自我修复”的区域,系统在特定条件下会主动把原厂恢复镜像写回去,覆盖掉你刚刷进去的 TWRP。不理解这个回写机制,后面所有的“永久固定”操作都是碰运气。
1.1 临时启动和永久写入差在哪一步
先用一句话区分两个概念。fastboot boot twrp.img是把镜像加载到内存里跑起来,分区内容一个字节都没动,重启即消失;fastboot flash recovery twrp.img才是真正写进 recovery 分区。前者适合验证镜像和这台机器是否匹配,后者才是持久化。
我见过不少人跳过临时启动这一步,直接 flash,结果镜像版本和当前系统底包不匹配,进 TWRP 就黑屏或者触摸失灵,然后误以为“刷坏了”。临时启动的成本极低,风险几乎为零,因为它不写分区,出问题拔线重启就恢复原状。这个验证动作建议每次都做,尤其是换了新版本 TWRP 镜像之后。
临时启动成功后,还要确认三件事:TWRP 能不能正常挂载 data、能不能识别内部存储容量、触摸和按键是否正常。这三项里任何一项异常,都说明镜像和机型不匹配,此时绝对不能执行 flash。分区写入是不可逆的(除非你有原厂 recovery 备份),而临时启动是可逆的,先易后难是基本纪律。
1.2 谁在偷偷把recovery换回去
回写的来源主要有三条路径,理解它们才能针对性处理。
第一条是系统分区里的恢复脚本。很多 MIUI 11 机型的 system 分区里带有一个恢复镜像文件和配套的安装脚本,系统在检测到 recovery 分区被改动后,会在开机过程中执行还原。这类文件通常位于系统分区的固定路径下,名字里带 recovery 字样。处理方式是在 TWRP 里挂载 system 分区,把这类文件删除或改名,切断还原链路。
第二条是 OTA 更新包本身。系统更新时,更新包会完整重写 boot 和 recovery 分区,TWRP 必然被覆盖。这一条没法“防”,只能靠流程规避:更新前先备份,更新后重新刷入。
第三条是部分机型的 bootloader 校验逻辑。某些版本在检测到 recovery 分区签名不一致时,会触发自动修复。这种情况相对少见,但如果前两条都处理了还是被覆盖,就要考虑这一层。
| 回写来源 | 触发时机 | 处理方式 | 彻底程度 |
|---|---|---|---|
| 系统分区恢复脚本 | 每次开机检测 | 删除或改名相关文件 | 高 |
| OTA 更新包 | 系统更新时 | 更新后重刷 | 无法预防,只能重做 |
| bootloader 自动修复 | 签名校验失败 | 关闭校验或降级 | 中等 |
提示:判断是不是被回写,最直接的办法是刷完 TWRP 后先进一次恢复模式确认可用,再正常开机,然后再进一次恢复模式。如果第二次进不去了,基本可以确定是回写,而不是刷写失败。
2. 动手前的状态盘点:解锁、分区布局与版本对齐
真正决定成败的往往不是刷写命令本身,而是动手前的状态确认。我见过太多案例是解锁没完成、分区布局判断错、底包版本对不上,然后在刷写阶段反复失败,最后把问题归咎于镜像有问题。这一节把这些前置条件一条条过一遍。
2.1 bootloader解锁状态与解锁后的副作用
刷任何非官方镜像的前提是 bootloader 已解锁。MIUI 11 时代的解锁流程通常需要通过官方工具申请,并且有一个等待期,短则几小时长则数天。这个等待期没法跳过,也不要相信任何“秒解”方案,那些方案要么无效,要么会带来更麻烦的后果。
解锁完成的标志是开机时出现解锁警告画面,或者在 fastboot 模式下执行查询命令能读到 unlocked 状态。这里要提醒一个容易被忽略的点:解锁动作本身会清空全部用户数据,包括内部存储。所以正确的顺序是先备份、再解锁,而不是解锁完发现数据没了才想起来。
解锁之后还有两个副作用需要接受。一是部分机型的指纹支付、部分金融类应用会检测解锁状态并拒绝运行,这是系统层面的限制,刷机解决不了。二是保修状态可能受影响,这一点自行权衡。
2.2 分区表决定你该刷哪个位置
MIUI 11 这一代设备绝大多数是 A-only 分区布局,recovery 是独立分区,这也是“刷 recovery 分区”这个操作能成立的前提。但并不是所有机型都这样,少数机型采用了 recovery 与 boot 合并的方案,这种情况下你往 recovery 分区写东西是无效的,必须走 boot 分区打补丁的路线。
判断方法很直接:在 fastboot 模式下执行分区列表查询,看输出里有没有独立的 recovery 条目。有,就是传统布局;没有,就是合并布局。这一步判断错了,后面所有操作都是白费力气。
除了 recovery,还要关注三个分区:vbmeta(校验相关)、vendor(fstab 配置所在)、boot(内核与 Magisk 补丁目标)。无密 data 的配置改动落在 vendor 分区的 fstab 文件里,这一点在第四节会详细展开。
2.3 必须提前备份的几个分区
备份这件事,做的时候觉得多余,丢的时候追悔莫及。下面这几个分区,我建议在刷任何东西之前全部导出到电脑上存一份。
| 分区 | 作用 | 丢失后果 |
|---|---|---|
| boot | 内核与 ramdisk | 无法开机,需重新提取原厂镜像 |
| recovery | 原厂恢复模式 | 无法回退到官方恢复 |
| vbmeta | 启动校验信息 | 校验失败导致无法启动 |
| persist | 传感器校准、指纹等数据 | 相机异常、指纹失效,且几乎无法恢复 |
| modem | 基带相关 | 无信号、无法通话 |
导出方式是在 fastboot 模式下逐个执行镜像读取命令,把输出文件保存到本地。persist 分区尤其重要,它存储的是出厂时写入的校准数据,一旦被覆盖或者清空,普通手段基本救不回来。我个人的习惯是把这些镜像按日期建文件夹存放,同时在文件名里标注系统版本,方便后续对照。
注意:备份文件不要只存在手机内部存储里。格式化 data 会连内部存储一起清空,备份必须落在电脑或外部介质上。
3. 从fastboot boot到fastboot flash:把TWRP钉死在recovery分区
前置条件都确认完之后,进入实际刷写阶段。这一节按操作顺序拆成四步,每一步都有明确的验证点,不要跳步。
3.1 先临时启动验证镜像可用性
把 TWRP 镜像放到电脑上,手机进入 fastboot 模式,连好数据线,执行:
fastboot devices fastboot boot twrp.img第一条命令确认设备被识别,如果输出为空,说明驱动或者数据线有问题,先解决这个再往下走。第二条命令是临时加载,手机会直接进入 TWRP 界面。
进入之后立刻做三项检查:触摸是否正常、能否挂载 data、内部存储容量是否显示正确。如果 TWRP 提示输入密码才能挂载 data,说明当前 data 还是加密状态,这是正常的,先跳过,后面格式化时会处理。如果内部存储显示 0MB 或者一堆乱码目录,说明镜像的 fstab 和这台机器的分区布局不匹配,换镜像版本。
这一步验证通过,才说明镜像可用。此时不要急着执行 flash,先把 TWRP 的语言、时区这些基础设置调好,顺便确认一下版本号,记录下来。
3.2 关掉dm-verity和AVB校验
这一步是最容易被跳过、也最容易导致后续开机失败的一步。现代安卓系统的启动校验链条里,dm-verity 负责校验系统分区完整性,AVB 负责校验启动镜像签名。你改了 recovery、改了 vendor 里的 fstab,校验就会失败,表现就是卡在开机第一屏反复重启。
处理方式是在 fastboot 模式下关闭这两项校验。前提是你已经从原厂固件包里提取了 vbmeta 镜像:
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img这条命令的含义是把原厂 vbmeta 重新写回去,但同时在头部标记里关掉校验标志位。注意必须用原厂镜像,不能用第三方修改过的,否则可能直接变砖。
不同机型的参数写法略有差异,有的版本需要用--disable-verity和--disable-verification分开执行,有的需要在 flash 之后额外执行一次格式化。执行完之后建议重启一次到 fastboot,确认没有报错再继续。
3.3 正式写入与首次进入的注意事项
镜像验证过、校验关掉了,现在正式写入:
fastboot flash recovery twrp.img输出里出现 OKAY 或者 Finished 就代表写入完成。此时不要直接执行fastboot reboot,而是用音量键组合直接进入恢复模式,确认 TWRP 能正常启动。
第一次进入 TWRP 时,它会提示是否允许修改系统分区。这个提示必须选允许,否则后续挂载 system 删除回写脚本的操作做不了。选完之后 TWRP 可能会提示“未安装 root,是否安装”,如果没有提前准备 Magisk 包,选不安装即可,后面再单独刷。
进入主界面后,第一件事是去挂载菜单确认 system 和 vendor 都能正常挂载。挂载不上,说明分区布局判断有误,需要回头检查。
3.4 防止OTA把TWRP冲掉的几个手段
写入成功只是第一步,让它留下来才是“永久固定”的核心。前面分析过回写来源,这里给出对应的处理手段。
最直接的是切断系统分区里的还原链路。在 TWRP 的文件管理器里进入系统分区,找到名字里带 recovery 的还原镜像和配套脚本,删除或者改名加后缀。这一步做完,开机时的自动还原就失效了。
第二个手段是刷入 Magisk。Magisk 在安装过程中会处理 boot 分区的校验相关逻辑,同时对系统分区的还原行为有一定抑制作用。但要注意,Magisk 本身不负责保护 recovery 分区,它只是让整个修改链条更稳定。
第三个手段是控制更新方式。既然 OTA 一定会覆盖 recovery,那就干脆不走 OTA,改为手动下载完整包、在 TWRP 里刷入。这样虽然麻烦一点,但整个流程可控,刷完重新刷一次 TWRP 就行。
| 手段 | 作用对象 | 操作难度 | 效果 |
|---|---|---|---|
| 删除系统分区还原文件 | 开机自动还原 | 低 | 直接切断 |
| 刷入 Magisk | boot 分区校验 | 中 | 间接稳定 |
| 放弃 OTA 改手动更新 | 更新覆盖 | 中 | 完全可控 |
4. 无密data到底在改什么:FBE加密链路与格式化顺序
“无密 data 分区”这个说法容易让人误解成“把密码删掉”,实际上它改的是系统的加密策略。理解这一层,才能明白为什么顺序错一步就会前功尽弃。
4.1 强制加密是怎么生效的
MIUI 11 这一代设备默认启用基于文件的加密。开机时,系统读取 vendor 分区里的 fstab 配置文件,看到某个分区条目上带着强制加密标志,就会在挂载时调用加密服务,用设备密钥或者用户密码派生出的密钥对 data 分区进行加密。这个标志的典型写法是在挂载参数里带forceencrypt或者fileencryption字样。
所谓“无密”,就是把这个强制标志去掉,改成“可加密”或者干脆不加密。改完之后,系统启动时不会主动加密 data,TWRP 也就不需要密码就能直接读写。
这里有个关键认知:加密状态不是存在某个开关里的,而是由 fstab 配置和分区实际状态共同决定的。你光格式化 data 不改 fstab,系统下次启动照样会重新加密;你光改 fstab 不格式化,已有的加密数据还在,TWRP 依然读不了。两件事必须都做,而且顺序有讲究。
4.2 改fstab还是刷补丁
两种路线,各有适用场景。
改 fstab 是手动路线。在 TWRP 里挂载 vendor 分区,找到 fstab 配置文件,用文件编辑器打开,定位到 data 分区那一行,把强制加密参数删掉或者改成可加密。改完保存,注意保持文件权限不变。这个路线的好处是透明可控,你能清楚看到改了什么;坏处是不同机型 fstab 文件名和路径可能不同,需要先找对位置。
刷补丁是省事路线。社区里有现成的解密补丁包,直接在 TWRP 里刷入,它会自动完成 fstab 修改。好处是省事,坏处是补丁包和系统版本强相关,版本不匹配可能改错位置或者改漏。
我个人的建议是:第一次操作走手动路线,把 fstab 的位置和内容搞清楚,以后再考虑用补丁包提高效率。因为一旦出问题,你知道去哪里回退。
4.3 格式化data的正确姿势与数据抢救
格式化 data 用的是 TWRP 里的“格式化 Data 分区”功能,不是普通的“清除”。这两者区别很大:普通清除只删文件,加密状态和分区结构不变;格式化会重建文件系统,加密状态一并清除。
操作路径是:清除菜单 → 格式化 Data 分区 → 输入确认词 → 执行。执行完之后,data 分区就是全新的、未加密的状态。
这一步会清空内部存储里的所有内容,包括照片、下载文件、应用数据。所以在格式化之前,必须把需要保留的东西拷到电脑上。如果手机已经无法正常开机,只能在 TWRP 里拷,那就先挂载 data(如果能挂载),把文件拉出来再格式化。
如果 TWRP 因为加密无法挂载 data,那就只能用 adb 拉取,或者接受数据丢失的现实。这也是为什么我一直强调备份要提前做。
4.4 顺序错了会怎样
把顺序列清楚:
- 进入 TWRP
- 挂载 vendor 分区
- 修改 fstab,去掉强制加密标志
- 格式化 data 分区
- 重启到系统
如果第 3 步和第 4 步颠倒,也就是先格式化再改 fstab,那么系统首次启动时读到的还是带强制加密标志的配置,会立刻重新加密 data。你重启进 TWRP,又要密码,白忙一场。
如果只做了第 4 步没做第 3 步,结果一样,系统会重新加密。如果只做了第 3 步没做第 4 步,data 里还是旧的加密数据,系统启动时可能因为密钥不匹配而反复重启。
所以这两步是绑定的,缺一不可,顺序也不能反。
提示:改完 fstab 之后,建议先用 TWRP 的文件管理器确认修改已经保存,再执行格式化。有些版本的编辑器保存后不会立即刷写到分区,需要手动同步一次。
5. 卡开机、无限重启、TWRP读不到存储:几类典型故障的排查顺序
刷机出问题是常态,关键是排查要有顺序,不要一上来就乱刷。下面按现象分类,给出从简到繁的排查链路。
5.1 卡在第一屏或logo循环
这是最高频的故障,原因通常集中在三处:校验没关、fstab 改错、Magisk 与系统版本不匹配。
排查顺序建议这样走:先进 TWRP,确认能不能正常挂载 system 和 vendor。能挂载,说明分区结构没坏,问题在配置层;不能挂载,说明分区可能被写坏,要考虑重刷底包。
配置层的排查,先看 vbmeta 校验有没有关。如果之前漏了这一步,重新执行一次关闭校验的命令。再看 fstab 改动是否正确,把改动前后的内容对照一遍,确认只删了加密标志,没有误删挂载点或者文件系统类型。最后看 Magisk,如果刷了 Magisk 之后才出问题,进 TWRP 刷卸载包移除,再重启验证。
如果以上都排除了还是卡第一屏,考虑是不是刷错了镜像版本。临时启动能进不代表永久写入能用,某些镜像在临时启动时走的是兼容路径,写入后走的是完整路径,差异会暴露出来。
5.2 TWRP里data显示0MB或乱码
这个现象基本可以锁定为加密未解除或文件系统不匹配。
先确认 fstab 是否已经改过。如果没改,先改再格式化。如果改过了还是这样,检查文件系统类型。MIUI 11 这一代设备 data 分区可能是 ext4 也可能是 f2fs,格式化时要选对类型。选错了,系统启动时会尝试挂载失败,表现就是反复重启。
还有一种情况是分区表本身出了问题,这种比较少见,通常伴随其他分区也异常。判断方法是看 TWRP 能不能挂载 system,如果 system 也挂不上,那就不是单纯 data 的问题了。
5.3 刷完Magisk后无法开机
Magisk 的原理是修改 boot 分区里的 ramdisk,注入自己的启动逻辑。版本不匹配、补丁目标错误、和系统自带的安全机制冲突,都会导致无法开机。
处理方式是进 TWRP 刷 Magisk 的卸载包,把 boot 分区恢复原状,然后重启验证系统能正常启动。确认系统没问题之后,再换一个版本的 Magisk 重试。建议优先选择和当前安卓版本明确兼容的稳定版,不要追新。
另外一个容易忽略的点是:如果之前改过 fstab 去掉加密,又刷了 Magisk,两者可能产生交互。排查时建议一次只改一个变量,改完验证,再改下一个。
5.4 OTA更新后回到原厂recovery
这个不算故障,是预期行为。前面说过 OTA 会重写 recovery 分区,更新完之后 TWRP 消失是正常的。
处理流程是:更新完成后,重新走一遍刷入流程。因为此时系统版本变了,vbmeta 也可能变了,所以关闭校验这一步要重新做,用的 vbmeta 镜像要换成新版本固件包里的。fstab 的改动同样会被覆盖,需要重新改一遍,改完再格式化 data。
这也是为什么我建议把整个流程写成清单,每次更新后照着走一遍,避免漏步骤。
| 现象 | 最可能原因 | 首选排查动作 |
|---|---|---|
| 卡第一屏 | 校验未关或 fstab 改错 | 进 TWRP 检查挂载与配置 |
| data 显示 0MB | 加密未解除或文件系统类型错 | 确认 fstab 与格式化类型 |
| 刷 Magisk 后不开机 | 版本不匹配 | 刷卸载包回退 |
| 更新后 TWRP 消失 | OTA 覆盖 | 重走刷入流程 |
6. 长期使用的维护习惯:OTA、Magisk版本与分区快照
把一次刷机做成功不难,难的是让它稳定用下去。这一节聊几个长期维护上的习惯,都是从反复折腾里总结出来的。
6.1 系统更新前后的固定流程
我的习惯是把更新当成一次完整的刷机来做,而不是点一下“检查更新”就完事。具体流程是:更新前用 TWRP 做一次完整备份,至少包含 boot、recovery、vendor、data;更新时用完整包而不是增量包,避免增量包在修改过的系统上校验失败;更新完成后立刻重新刷 TWRP、重新关校验、重新改 fstab、重新格式化 data。
这一套下来确实费时间,但好处是每次更新后系统状态都是可预期的。用增量包图省事,经常会出现更新到一半失败、系统处于半损坏状态的情况,处理起来更麻烦。
6.2 保留一份可回退的镜像
电脑上常备一份当前系统版本对应的原厂镜像集合,包括 boot、recovery、vbmeta、vendor。这份东西的作用是在系统被改坏、无法进 TWRP 的时候,能用 fastboot 直接把机器救回来。
我一般会按“机型代号 + 系统版本号”建文件夹,里面放原厂镜像、TWRP 镜像、Magisk 包、解密补丁。时间久了会积累好几个版本,但每个版本对应一次成功的配置,出问题时能快速定位到可用的组合。
6.3 什么情况下该放弃无密data
无密 data 带来的是便利,代价是安全性下降。设备丢失时,data 分区里的内容没有任何加密保护,任何人拿到机器都能直接读取。所以如果这台机器还承担着日常通信、支付、存照片的角色,我个人不建议长期保持无密状态。
比较折中的做法是:折腾阶段用无密 data 方便反复刷写,等配置稳定了,把 fstab 改回去,重新格式化一次,恢复加密。日常使用保持加密,需要折腾时再临时处理。这个切换成本不高,但安全性提升明显。
另外一个判断标准是设备的使用场景。如果这台机器只是放在家里当测试机、刷机练手用,无密完全没问题;如果是主力机,那就得掂量一下。
最后分享一个实际操作里的小经验:每次改完 fstab、格式化完 data、刷完 Magisk 之后,不要急着装应用,先重启两次,确认系统能稳定进入、TWRP 能稳定进入、data 不需要密码,这三个条件都满足再开始恢复数据。多花这五分钟,能省掉后面几个小时的返工。