[dm-crypt] Initializing dm-crypt on Android results in "device lookup failed"

Ondrej Kozina okozina at redhat.com
Mon May 23 10:17:37 CEST 2016

Hello Roman,

I'm no Android developer, so just according to what I can see in your logs:

On 05/22/2016 11:31 AM, Roman Schlegel wrote:
> 01-01 03:20:03.592 I/Cryptfs (  254): load_crypto_mapping_table:
> crypt_params = aes-cbc-essiv:sha256 0A66F89B0D3DFC0B05D9BD23B3453A70 0

Don't post your volume key publicly! If it was just a test device it's 
not so big deal but it's generally good rule to follow so that you don't 
post your VK for real device accidentally.


> /dev/block/platform/mtk-msdc.0/by-name/userdata 0 1 allow_discards 0
> 01-01 03:20:08.619 E/Cryptfs (  254): Cannot load dm-crypt mapping table.
> at the same time, the kernel log prints the following messages:
> <3>[  138.163773] (5)[327:vold]device-mapper: table: 253:0: crypt:
> Device lookup failed

The kernel driver complaints that it can't access a block device 
referenced by path /dev/block/platform/mtk-msdc.0/by-name/userdata. Is 
it block device? If it's supposed to be a symlink does a referenced 
block device exist?

The thing is kernel accepts only limited set of paths as device 
identifier in DM table. Usually major:minor numbers, kernel path, 
part_uuid. The translation from arbitrary path '
/dev/block/platform/mtk-msdc.0/by-name/userdata' to something DM driver 
is able to parse should be done in userspace. Usually, it's libdevmapper 
library what does that. Given that kernel complaints, it seems userspace 
haven't done the translation properly or there was a race maybe. Could 
you pass major:minor for /dev/block/platform/mtk-msdc.0/by-name/userdata 
directly in userspace utility that's supposed to establish device 


More information about the dm-crypt mailing list