[Motorola Droid 3] JetpackJohn:
[Q] encryption, ext2/4, and "filesystem too large to mount safely" error fix?

Hello again,

With my Droid 3 (thanks to Minimoto) again working great, I've turned my attention back to encrypting some of my data on the external SD card. I had used "LUKS Manager" some time ago so that seemed the logical place to start.

Okay, the short *short* version is: What does the error message (from dmesg output) "EXT4-fs (dm-4): filesystem too large to mount safely on this system" mean and how do I fix it or work around it?

The details:

I have a 32 GB SD card with a normal ~20 GB FAT partition that Android sees and uses just fine. On my laptop I created an ext4 file system on the second partition (the remaining ~12 GB of space). Android does not see or use this, but from a terminal I *can* mount it without problems. I chose to mount /dev/block/mmcblk0p2 (external SD partition 2) at /mnt/sdcard-ext-p2. Just FYI, but I wrote a short script and put it at /etc/init.d/03mount_sdpart2 to mount this second partition at the correct mount point and it works fine. Even after a reboot the script runs without problems and now I always have my new ext4 file system present.

The reason for creating the ext4 file system is because FAT does not support files larger than 4 GB and therefore my encrypted volume cannot be larger than 4 GB *if* I create that volume on a FAT file system. With the new ext4 file system, now using the LUKS Manager app, I created a new volume at the above mount point with a size of approximately 11.25 GB. This worked fine, too. The last step, however, actually mounting this encrypted volume, keeps failing. It was supposed to be mounted at /mnt/sdcard/LUKS. Unfortunately, LUKS Manager did not produce much in the way of information about why it had failed.

A quick note about file sizes: If I use an app like "ES File Explorer" and go to /mnt/sdcard-ext-p2 where the large volume file exists, ES says the volume file has a size of -805306366 bytes, obviously wrong. Fortunately, if I use the terminal and look at the file size with "ls -l" it has the correct size. Furthermore, after I opened the volume below using lm.cryptsetup I can use its "status" command and after converting the values from sectors (each sector is 512 bytes) it also displays the correct size of the encrypted volume.

So, back to the terminal where I decided to do the steps manually and see where it failed. For the most part, I used different device and directory names than what LUKS Manager would have used, mostly to be sure I wouldn't accidentally conflict with another process/app. The 'lm.cryptsetup' binary is provided by LUKS Manager and placed in /system/bin. I have the version of busybox that, I assume, ships with Minimoto which is busybox v1.20.0. This is where the 'losetup' I am using comes from.

Concerning loopback devices: LUKS Manager defaults to using/creating high numbered loopback devices, 300 for the first volume created. On Android the loop devices are created in /dev/block, but some tools don't seem to look there. In particular, lm.cryptsetup complains about not being able to find a free loopback device and 'losetup -f' (which displays the next free/available loopback device) always refers to devices in /dev regardless of where they really are. Making symlinks such as "ln -s /dev/block/loop0 /dev/loop0" for each of the currently present loop devs (0 through 7, and 300) fixes both of these problems. That said, whatever manner LUKS Manager uses to execute the underlying tools works properly with the loop devs being located in /dev/block. This can be verified by using "lm.cryptsetup status <crypt_dev>" and the status output shows that it is correctly attached to, for example, /dev/block/loop300. Making these symlinks is more of a convenience/fix for when one is working directly on the command line.

Where, before, 'losetup -f' indicated that /dev/loop0 was free (even though it did not exist), after making the symlinks the same command indicates that /dev/loop4 is the next free loop. On my phone, at that moment in time, that was the correct answer. loop4 also makes sense because I have four apps that I have "moved to SD" and for each app that you do this one loopback device is used (so loop0 - loop3 were used by apps "moved" from main internal storage). Creating these symlinks also made lm.cryptsetup stop complaining/erroring about not being able to find a free loop dev. Finally, running "losetup" without arguments is supposed to list the used loop devs and what is using them. Before making the symlinks is produced no output, and now, after the symlinks, it displays:

/dev/loop0: 0 /mnt/secure/asec/blah_appA.asec
/dev/loop1: 0 /mnt/secure/asec/blah_appB.asec
/dev/loop2: 0 /mnt/secure/asec/blah_appC.asec
/dev/loop3: 0 /mnt/secure/asec/blah_appD.asec
/dev/loop5: 0 /ss/safestrap/rom-slot2/cache.img
/dev/loop6: 0 /ss/safestrap/rom-slot2/userdata.img
/dev/loop7: 0 /ss/safestrap/rom-slot2/system.img

As you can see, loop4 is missing/available. Also, rom-slot2 is correct as it is where I opted to install Minimoto, rom-slot1 currently containing CM 10.1.

With the loop device issues taken care of, the steps I performed are as follows:

$ su
# lm.cryptsetup luksOpen /mnt/sdcard-ext-p2/MyCrypto.vol MyCrypto
<type in passphrase>
# ls /dev/mapper
MyCrypto control
# mkdir /mnt/sdcard/luks-tst
# mount /dev/mapper/MyCrypto /mnt/sdcard/luks-tst
mount: mounting /dev/mapper/MyCrypto of /mnt/sdcard/luks-tst failed: File too large
# dmesg | tail -2
[20665.748504] EXT4-fs (dm-4): filesystem too large to mount safely on this system
[20665.750732] EXT4-fs (dm-4): filesystem too large to mount safely on this system

You can see from the above block my commands and the output, especially errors, that followed. Clearly, the file is "too large"... but how? The whole point of this extra partition and ext4 file system stuff was specifically to get around the FAT 4GB file size limitation. Unfortunately, while these errors tell me that something is too large, what *part* is too large? Is the 11.25 GB volume *container* too large, or the ext2/4 file system that exists inside the volume? And if either is too large, what is the maximum size I can make them? I did try adding "-t ext2" and "-t ext4" to the mount command, but neither one changed the outcome nor did they change the messages that were output.

The 'mount' binary (like most others) is provided by busybox, so it could possibly be part of the problem. However, the last two errors above come from the kernel log (via dmesg) which means that at least part of the issue is the kernel, maybe the file system modules. I also checked the logcat output, just in case, but it did not contain anything related or useful. Minimoto 1.7 is using kernel version 2.6.35.7 and perhaps it has some maximum size issues I am unaware of. With the exception of my Droid 3, I haven't used a 2.6.x Linux kernel in a very long time.

I've searched around here as well as the fairly small LUKS Manager message board and the Net at large, but I haven't been able to find the answers I'm looking for. Any ideas as to what I might have done wrong, or something I haven't done but should? I'm not sure how to proceed. Just to be perfectly safe, I did try rebooting but it made no difference.

--John Gruenenfelder