1

I am on Android 6 (AOKP), TWRP installed, and Xposed/Xprivacy. I wanted to encrypt the device from the settings dialog but apparently that failed - it just sits there with the boot animation doing nothing.

I can adb shell into it, logcat says:

06-03 03:58:47.076 E/BootAnimation(22199): couldn't find audio_conf.txt
06-03 03:58:51.208 W/vold    (  260): type=1400 audit(0.0:9568213): avc: denied { read } for name="fd" dev="proc" ino=3926686 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=dir permissive=0
06-03 03:58:51.208 W/vold    (  260): type=1400 audit(0.0:9568214): avc: denied { getattr } for path="/proc/248/cwd" dev="proc" ino=3926688 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=lnk_file permissive=0
06-03 03:58:51.208 W/vold    (  260): type=1400 audit(0.0:9568215): avc: denied { getattr } for path="/proc/248/root" dev="proc" ino=3926689 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=lnk_file permissive=0
06-03 03:58:51.208 W/vold    (  260): type=1400 audit(0.0:9568216): avc: denied { getattr } for path="/proc/248/exe" dev="proc" ino=3926690 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=lnk_file permissive=0
06-03 03:59:11.618 W/vold    (  260): type=1400 audit(0.0:9568217): avc: denied { read } for name="fd" dev="proc" ino=3926686 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=dir permissive=0
06-03 03:59:11.622 W/vold    (  260): type=1400 audit(0.0:9568218): avc: denied { getattr } for path="/proc/248/cwd" dev="proc" ino=3926688 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=lnk_file permissive=0
06-03 03:59:11.622 W/vold    (  260): type=1400 audit(0.0:9568219): avc: denied { getattr } for path="/proc/248/root" dev="proc" ino=3926689 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=lnk_file permissive=0
06-03 03:59:11.622 W/vold    (  260): type=1400 audit(0.0:9568220): avc: denied { getattr } for path="/proc/248/exe" dev="proc" ino=3926690 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=lnk_file permissive=0
06-03 03:59:11.679 E/Cryptfs (  249): unmounting /data failed: Device or resource busy
06-03 03:59:11.698 W/vold    (  260): type=1400 audit(0.0:9568221): avc: denied { read } for name="fd" dev="proc" ino=3926686 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=dir permissive=0
06-03 03:59:11.698 W/vold    (  260): type=1400 audit(0.0:9568222): avc: denied { getattr } for path="/proc/248/cwd" dev="proc" ino=3926688 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=lnk_file permissive=0
06-03 03:59:11.698 W/vold    (  260): type=1400 audit(0.0:9568223): avc: denied { getattr } for path="/proc/248/root" dev="proc" ino=3926689 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=lnk_file permissive=0
06-03 03:59:11.698 W/vold    (  260): type=1400 audit(0.0:9568224): avc: denied { getattr } for path="/proc/248/exe" dev="proc" ino=3926690 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=lnk_file permissive=0
06-03 03:59:11.752 W/vold    (  260): type=1400 audit(0.0:9568225): avc: granted { read write } for name="mmcblk0p32" dev="tmpfs" ino=9999 scontext=u:r:vold:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file
06-03 03:59:11.752 W/vold    (  260): type=1400 audit(0.0:9568226): avc: granted { read write open } for name="mmcblk0p32" dev="tmpfs" ino=9999 scontext=u:r:vold:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file
06-03 03:59:11.752 W/vold    (  260): type=1400 audit(0.0:9568227): avc: granted { getattr } for path="/dev/block/mmcblk0p32" dev="tmpfs" ino=9999 scontext=u:r:vold:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file
06-03 03:59:11.832 W/vold    (  260): type=1400 audit(0.0:9568228): avc: granted { read } for name="mmcblk0p47" dev="tmpfs" ino=10059 scontext=u:r:vold:s0 tcontext=u:object_r:userdata_block_device:s0 tclass=blk_file
06-03 03:59:11.832 W/vold    (  260): type=1400 audit(0.0:9568229): avc: granted { read open } for name="mmcblk0p47" dev="tmpfs" ino=10059 scontext=u:r:vold:s0 tcontext=u:object_r:userdata_block_device:s0 tclass=blk_file
06-03 03:59:11.832 W/vold    (  260): type=1400 audit(0.0:9568230): avc: granted { ioctl } for path="/dev/block/mmcblk0p47" dev="tmpfs" ino=10059 ioctlcmd=1260 scontext=u:r:vold:s0 tcontext=u:object_r:userdata_block_device:s0 tclass=blk_file
06-03 03:59:11.835 E/Cryptfs (  249): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/extra
06-03 03:59:11.841 D/Cryptfs (  249): Just asked init to shut down class main
06-03 03:59:11.841 W/vold    (  249): emulated unmount requires state mounted
06-03 03:59:11.841 W/vold    (  249): public:179_129 unmount requires state mounted
06-03 03:59:31.935 W/vold    (  260): type=1400 audit(0.0:9568231): avc: denied { read } for name="fd" dev="proc" ino=3926686 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=dir permissive=0
06-03 03:59:31.935 W/vold    (  260): type=1400 audit(0.0:9568232): avc: denied { getattr } for path="/proc/248/cwd" dev="proc" ino=3926688 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=lnk_file permissive=0
06-03 03:59:31.935 W/vold    (  260): type=1400 audit(0.0:9568233): avc: denied { getattr } for path="/proc/248/root" dev="proc" ino=3926689 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=lnk_file permissive=0
06-03 03:59:31.935 W/vold    (  260): type=1400 audit(0.0:9568234): avc: denied { getattr } for path="/proc/248/exe" dev="proc" ino=3926690 scontext=u:r:vold:s0 tcontext=u:r:logd:s0 tclass=lnk_file permissive=0
06-03 03:59:32.007 E/Cryptfs (  249): unmounting /data failed: Device or resource busy
06-03 03:59:32.007 W/SocketClient(  249): write error (Broken pipe)
06-03 03:59:32.007 W/SocketClient(  249): Unable to send msg '200 8 -1'

Now, is it possible to undo the beginning of the encryption, since apparently no sectors were encrypted yet? Maybe I could somehow overwrite the luks header, restore the original one, or maybe the key (if there is one) is still in memory? I do have a TWRP backup from maybe 2 months ago.

I cannot su anymore, so that may be a problem.... it just hangs. But I am afraid that if I reboot, every last chance of recovery will be gone.

mount says:

rootfs on / type rootfs (ro,seclabel,relatime)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,seclabel,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
none on /sys/fs/cgroup type tmpfs (rw,seclabel,relatime,mode=750,gid=1000)
tmpfs on /mnt type tmpfs (rw,seclabel,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
none on /sys/fs/cgroup/bfqio type cgroup (rw,relatime,bfqio)
/dev/block/platform/msm_sdcc.1/by-name/system on /system type ext4 (ro,seclabel,noatime,data=ordered)
/dev/block/platform/msm_sdcc.1/by-name/userdata on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic,data=ordered)
/dev/block/platform/msm_sdcc.1/by-name/cache on /cache type ext4 (rw,seclabel,nosuid,nodev,noatime,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic,data=ordered)
/dev/block/platform/msm_sdcc.1/by-name/radio on /firmware/radio type vfat (ro,context=u:object_r:firmware_file:s0,noatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro)
/dev/block/platform/msm_sdcc.1/by-name/adsp on /firmware/adsp type vfat (ro,context=u:object_r:firmware_file:s0,noatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro)
tmpfs on /storage type tmpfs (rw,seclabel,relatime,mode=755,gid=1000)
/dev/block/loop0 on /su type ext4 (rw,seclabel,noatime,data=ordered)
0

I finally found the answer here: Cryptfs : unmounting /data failed: Device or resource busy

In short: just rebooting worked, nothing was written to disk at all yet.

Note to self: always make a backup right before potentially destructive operations. Saves quite a lot of headaches :)

The answer above also says booting into safe mode fixes the problem. I have yet to verify that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.