[Galaxy S III General] Lanchon:
well i cannot answer about scripts and procedures unknown to me but...

an encrypted disk typically is made of 2 things:

-the encrypted disk 'surface' or area (ie: the data)

-and metadata (data describing the data, ie: data describing the encrypted disk)

metadata typically contains:

-cipher info

-and the disk surface encryption key (generated at random), itself encrypted with the access key (such as a passphrase).

why the indirect key? without it:

-changing the passphrase (say, your phone lock pattern) would be a very dangerous operation that would require reading, reencrypting and writing the complete disk, would take a huge amount of time and would drain your battery completely

-erasing the disk would similarly take a long time.

with it:

-when changing the passphrase you just need to reencrypt the surface key with the new passphrase and rewrite the metadata.

-when erasing, just wipe the metadata.

for example the metadata in recent android phones with hardware backing store for keys probably contains:

-cipher info

-and the disk surface encryption key (generated at random), itself encrypted with a secondary key (also random).

the secondary key lives in the hardware keystore. it's generated there and can never leave that processor. the keystore will decrypt the surface key during boot, only if the main processor informs the right passphrase (say, the PIN or pattern). a 4-digit PIN would be very easy to bruteforce, except that the keystore throttles down guesses, and can even wipe the key (rendering the disk forever unreadable) after so many bad guesses.

the keystore should be tamper-proof: a silly small processor, but resistant to voltage spike attacks, rays, etc and decapping to read the storage, to pick up signals in traces, to inject signals in traces, to chip modifications, etc. think of it as the chip in any recent credit card or even some sim cards, but on the main circuit board.

anyway back to metadata in android: it needs to be stored somewhere. the obvious place is an ultra small metadata partition containing just the raw metadata, no file system or anything of the like. this is simple and works great, except for one detail: older phones don't have this partition. basically this means that an android upgrade couldn't give you encryption.

so android can use a "crypto footer": with this scheme the encryptable partition (say /data) has a file system that is 16KiByte short of filling the actual partition, and the 16KiB footer follows. the footer is the metadata.

when you repartitioned before, you probably created a file system that used the complete partition area. there was no space left for the footer, so encryption couldn't be enabled.

you could have solved your issue today by flashing repit with all-default parameters: repit always resizes the encryptable partition's file system to make room for the footer, if not already there.

in REPIT, these commits add general and ext4-particular support for crypto footers:

https://github.com/Lanchon/REPIT/commit/591961adb180a6a03594053a846b698240b4d507

https://github.com/Lanchon/REPIT/commit/de3d3af9813afef7de3a798ce5314c0fb210e30f

https://github.com/Lanchon/REPIT/commit/5c3360b572ff25c7c01d796cabb9400066451ec3

this configures the footer on the i9300:

https://github.com/Lanchon/REPIT/blob/f46b0aafdfeb7860be17a315b4aceb43966325f9/device/i9300.sh#L85