tgoop.com/real5ec1cff/79
Create:
Last Update:
Last Update:
我的手机两年前上 Android 11 之后开机在第一屏一直都耗时很长，直到昨天才在 ksu 群的讨论中知道原因。
init 在 post-fs-data 的时候会执行一个 restorecon ，这会重置 /data 子目录下的所有文件的 selinux label 。这是一个很耗时的过程，正常来说只会在系统更新的时候执行，如果执行成功就会记录一个和当前系统相关的 hash （根据 plat_file_contexts 计算出来，持久化存储在 xattr security.sehash ），下次启动检查 hash ，如果和系统的匹配就不需要再重置了。但是某些设计不良的系统 因为某种原因导致这个过程失败（比如 selinux 规则不正确，某些文件无法被 init restorecon ），导致 hash 不会被记录。从而每一次重启都要执行完整的 restorecon ，因此开机经常要在第一屏卡上 1~2 分钟（具体时长取决于你手机中非 ce 存储的文件的数目）。（[1] [2]）
由于这条命令在 post-fs-data 阶段的早期执行，先于 adbd 启动，更没有进入开机动画（第二屏），所以卡在第一屏的这段时间完全没法进入系统查看情况，很容易让心急的人以为手机莫名其妙成砖了。
解决方法自然是让这个过程顺利完成，前人已经给出了方法（[1] [2]），也就是自己用 root shell 跑一遍成功的 restorecon .
/system/bin/restorecon -Rv /data
注意：Magisk 用户请勿直接执行上面的命令，最好在执行之前给 /data/adb/modules 盖一层 tmpfs ，否则会导致模块异常。
但是这样太浪费时间，还容易意外修改本来不该修改的 con ，因此我想了个捷径（以下为伪代码，请结合实际情况使用）：
# 在私有隔离 ns 中操作
BUSYBOX unshare -m sh
# 制造一个假的空 /data 目录
# 不用 tmpfs 是因为 restorecon 会跳过 tmpfs
mkdir /data/tmp
mount --bind /data/tmp /data
# 因为 /data 没有文件，restorecon 只会修改目录自身的 label 并记录 hash
restorecon -Rv /data
# 从假 /data 获取当前系统下 /data 的 sehash
getfattr -n security.sehash /data
<HASH>
# 把真正的 /data 目录的 sehash 修改为上面得到的 hash
umount /data
setfattr -n security.sehash -v '<HASH>' /data
这样操作之后 /data 的 sehash 直接被重置为和当前系统一致的 hash ，开机启动的 restorecon 就能成功跳过，终于不会再卡第一屏了。
BY 5ec1cff
Share with your friend now:
tgoop.com/real5ec1cff/79