I wiped all the partitions from my Moto G device with the TWRP recovery and installed Cyanogen 13 on it. Then I had issues when enabling Encryption: the phone just restarts but does not encrypt. This is a known issue and is described here.

I wanted to follow a procedure described in this answer (based on this), which reportedly works. The explanation is:

When encrypting the phone, partition /dev/block/mmcblk0pXX - originally containing an ext4 filesystem which is mounted as /data and /sdcard - now contains an encryption container. This will be decrypted early in the boot process and returns a logical partition /dev/block/dm-0 which then holds the ext4 filesystem for /data and /sdcard. (...)

To fix that, the filesystem in /dev/block/mmcblk0pXX needs to be at least 16KiB smaller than the partition itself, which can easily be done by resize2fs.

In short, the proposed solution is to resize the /data partition, removing some sectors from it...

Important is the number of blocks (...) From this number, we subtract 8, which leaves not 16KiB but a safe 32 KiB of space for the encryption header (you don't mind 16KiB on a 12GB volume, seriously)

The actual number of blocks to be removed from the /data partition depends on the sector size for the partition. In the example above it's 4KB, so 8x4 =32.

The problem

These instructions only apply to the ext2/3/4 file systems; the necessary commands (e2fsck, tune2fs, resize2fs) won't work with the F2FS partition used by Cyanogen v13.

I found fsck.f2fs in the /sbin directory, which I used instead of e2fsck and tune2fs. Below are the steps from the root ADB Shell, booted to TWRP:

~ # mount | grep data

/dev/block/platform/msm_sdcc.1/by-name/modem on /firmware type ext4 (rw,seclabel,relatime,data=ordered)
/dev/block/mmcblk0p36 on /data type f2fs (rw,seclabel,relatime,background_gc=on,user_xattr,inline_xattr,acl,inline_data,active_logs=6)
/dev/block/mmcblk0p36 on /sdcard type f2fs (rw,seclabel,relatime,background_gc=on,user_xattr,inline_xattr,acl,inline_data,active_logs=6)
/dev/block/mmcblk0p33 on /cache type ext4 (rw,seclabel,relatime,data=ordered)

~ # umount /dev/block/mmcblk0p36

~ # fsck.f2fs -f /dev/block/mmcblk0p36

Info: Force to fix corruption
Info: sector size = 512
Info: total sectors = 11583232 (in 512 bytes)


So, my /data partition is mmcblk0p36, and is 11 583 232 sectors in size. Each sector is 512 bytes, thus I must shrink the partition to a final size of 11 583 168 sectors in order to leave 32KB unallocated.

But how can it be done? Everything seem to indicate that shrinking an F2FS partition is not possible, but I'm not sure. If it is not, and assuming I did a full backup of the /data partition, what are the steps to delete and re-create it with a smaller size?

  • 1
    Recreating the partition with a smaller size wouldn't solve your issue, if I read the quotes correctly: To fix that, the filesystem in /dev/block/mmcblk0pXX needs to be at least 16KiB smaller than the partition itself (emphasis mine). I've no experience with F2FS, but is there a mkf2fs or mkfs.f2fs command available? You could then run that with the appropriate parameters to re-create the file system with the corresponding size (which of course would destroy all data on the current file system on that partition, so make a backup first).
    – Izzy
    May 30, 2016 at 5:45
  • @Izzy It worked! Thanks mate. I credited you on Unix & Linux SE.
    – Marc.2377
    May 30, 2016 at 7:57
  • 1
    Glad to read! And thanks for posting it as answer with details (upvoted ;)
    – Izzy
    May 30, 2016 at 8:43

1 Answer 1


As of today (May 30, 2016), the F2FS file system doesn't support shrinking. If it does by the time someone reads this, just let me know in the comments.

The solution is then to delete and re-create the entire filesystem for /data. From this related answer on Unix & Linux Stack Exchange:

mkfs.f2fs /dev/block/mmcblk0p36 11583168

This will do the trick. After rebooting and restoring the backup, and finally, rebooting to Android, the encryption process worked.

Important: Be sure to check Use rm -rf instead of formatting from the TWRP settings prior to restoring the backup.

  • 2
    resize.f2fs 1.12.0 supports shrinking as well as expanding. Jul 8, 2019 at 13:30
  • 1
    @IrfanLatif I can't find any evidence that shrinking should be supported - where did you read that? May 1, 2022 at 16:21
  • 2
    You can find f2fs-tools (including resize.f2fs) compiled statically for ARM here.
    – hacker1024
    Nov 2, 2022 at 15:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .