ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

MIUI 11 老机型 TWRP 永久固定与无密 data 避坑指南

MIUI 11 老机型 TWRP 永久固定与无密 data 避坑指南

刷完第三方恢复模式,重启进系统转一圈,再关机按组合键——原厂恢复界面又回来了。这个场景在老机器玩家圈子里几乎是入门必修课,尤其是 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 就行。

手段作用对象操作难度效果
删除系统分区还原文件开机自动还原低直接切断
刷入 Magiskboot 分区校验中间接稳定
放弃 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 顺序错了会怎样

把顺序列清楚:

  1. 进入 TWRP
  2. 挂载 vendor 分区
  3. 修改 fstab,去掉强制加密标志
  4. 格式化 data 分区
  5. 重启到系统

如果第 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 不需要密码,这三个条件都满足再开始恢复数据。多花这五分钟,能省掉后面几个小时的返工。

返回列表