[Verizon HTC Droid Incredible 4G LTE] Slick1123:
Device encrypt success! (changes needed)

TL;DR: We need a handful of changes to support device encryption on the Incredible 4G LTE in CyanogenMod 10.1 But it's doable! See To other readers at the bottom of this post.

I figured out why, using

ps -t | grep -i vold

to find all the vold threads and then attaching to each using

strace -p <thread_id>

Check out this output:

hell@android:/ # strace -p 188
Process 188 attached - interrupt to quit
select(15, [9 12 14], NULL, NULL, NULL) = 1 (in [14])
read(14, "9 cryptfs enablecrypto inplace 1"..., 255) = 38
open("/fstab.qcom", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/fstab.qcom", O_RDONLY) = -1 ENOENT (No such file or directory)
open("", O_RDONLY) = -1 ENOENT (No such file or directory)
ioctl(-1, BLKGETSIZE, 0x404fd394) = -1 EBADF (Bad file number)
writev(6, [{"\6", 1}, {"Cryptfs\0", 8}, {"Cannot get size of block device "..., 34}], 3) = 43

(I later realized "strace -F -p" would have made my life a lot easier.)

Looks like vold is looking for the fstab in /fstab.qcom, but the real filename is /fstab.fighter. According to get_fstab_filename() in cryptfs.c, that "qcom" is coming from the "ro.hardware" property. The only place I can find this set is "androidboot.hardware=qcom" on the kernel command line (in the boot.img header).

Anyway, I tried remounting / read-write and created a symlink to fstab.qcom. This got further along, but errored out with:

E/Cryptfs ( 120): unmounting /data failed
E/Cryptfs ( 120): Error enabling encryption after framework is shutdown, no data changed, restarting system

strace shows:

[pid 189] umount("/data", 0) = -1 EBUSY (Device or resource busy)

While attempting encryption, I ran as root:

while true; do sleep 1; lsof | grep /data; done

This showed:

dhcpcd 949 dhcp 4 ??? ??? ??? ??? /data/misc/dhcp/dhcpcd-wlan0.pid

So I turned off WiFi during the encryption process. This got a little further:

D/Cryptfs ( 119): unmounting /data succeeded
D/Cryptfs ( 119): Just triggered post_fs_data
...
E/Cryptfs ( 119): Error enabling encryption after framework is shutdown, no data changed, restarting system

Hmm, a further strace showed that vold was timing out waiting for something to happen. Searching for post-fs-data, I found this page:

http://source.android.com/tech/encryption/android_crypto_implementation.html

And then I looked at the post-fs-data clause in /init.rc:

# If there is no fs-post-data action in the init.<device>.rc file, you
# must uncomment this line, otherwise encrypted filesystems
# won't work.
# Set indication (checked by vold) that we have finished this action
#setprop vold.post_fs_data_done 1

Hmm, init.qcom.rc almost does that:

on post-fs-data
# double check perms and set owner
chown root root /devlog
chmod 0700 /devlog

# Set indication (checked by vold) that we have finished this action
setprop vold.post_fs_done 1

# prepare kernel for wifi module
setprop ro.product.wireless WCN3660
write /dev/wcnss_wlan 1

Whoops, is that supposed to be post_fs_data_done, not post_fs_done? In any case, init.rc also includes init.cm.rc to handle that clause, and it appeared that the latter was running last. So I added

setprop vold.post_fs_data_done 1

to the post_fs_data clause in init.cm.rc.

At this point, the device successfully executed a warm reboot and, after a few minutes, encrypted itself. It rebooted itself fully afterward, but then showed an Encryption Unsuccessful message upon boot. I suspected this was because of the fstab naming mismatch. So I went into the boot image and changed init.target.rc (this file: https://github.com/CyanogenMod/android_device_htc_fireball/blob/cm-10.1/rootdir/etc/init.target.rc) to use fstab.qcom instead, then renamed fstab.fighter to fstab.qcom. So instead of resetting the phone, I did a battery pull and rebooted into the bootloader, then booted the new boot image with these changes.

SUCCESS!

So in summary, to get the phone encrypting, we need:

change recovery.fstab to leave slack space on the /data block device (this post: http://xdaforums.com/showthread.php?p=40533033#post40533033)

rename fstab.fighter to fstab.qcom

modify init.target.rc to use fstab.qcom instead of fstab.fighter

add ",encryptable=footer" after "wait" on the /data line of fstab.qcom

add "setprop vold.post_fs_data_done 1" to the end of the "on post_fs_data" clause in either init.qcom.rc or init.cm.rc

Whew, that's a relief.

(To other readers: If you don't mind running mke2fs manually from CWM/TWRP (to make a smaller-than-maximum /data filesystem size; I used

mke2fs -t ext4 /dev/block/mmcblk0p35 1212396

to get the right size), then you can use the attached boot image to get the remaining four bullets above. NOTE that this is completely unofficial and unsupported! USE AT YOUR OWN RISK! I will not answer any questions about it other than those related to rolling these changes into the mainstream. Plus it's derived from the Avatar ROM, though I doubt the boot image is any different...)