I've scoured the internet for help on this, and it seems I'm one of the only people with this problem.

I recently downloaded a fresh copy of Kali Linux ARM for the Raspberry Pi 3 Model B+, and I want to set it up as a portable hacking station with an external encrypted media drive (encrypted with LUKS) that will be automatically unlocked at boot. I configured /etc/fstab and /etc/crypttab to correctly unlock and mount my encrypted partitions respectively (using a key file).

I noticed that this process would consistently fail on boot, giving the error that it "cannot allocate memory" when unlocking the drive through /etc/crypttab. After doing some more digging and testing, I found that the problem was only on the Raspberry Pi itself, because I could use the exact same key file to unlock the drive manually on my laptop: cryptsetup luksOpen --key-file /root/keyfile /dev/sdb1 sdb1_crypt. When I tried this same command on the Raspberry Pi, it would wait for a few seconds (just as it did on my laptop while it took time to unlock the drive), and finish with a successful error code. However, the drive would not be unlocked, and running lsblk would still show the locked drive (it also did not appear in /dev/mapper/sdb1_crypt), whereas the drive would be successfully unlocked when done on my laptop. The luksRemoveKey command also did not work on the Raspberry Pi. I didn't try every cryptsetup command, but I'm convinced that those aren't the only ones that don't work. Nevertheless, I could still use my password (key slot 0, and the key file was key slot 1) to unlock the drive on both devices: cryptsetup luksOpen /dev/sdb1 sdb1_crypt.

My guess is that the problem lies with the kernel, and I don't have the skills to fix it. I thought about posting this over at the Kali Linux forums, but I was hoping someone else might have the same problem on another OS that they fixed.

Thanks in advance, any help is appreciated.


I did a little more research into the memory warnings cryptsetup was giving me, and I found this post by @rscottbailey.

It turns out cryptsetup chooses some parameters that effectively are scaled based on the performance of your current system (in an attempt to reach some vaguely consistent level of "hardness"?) -- what works well for the Core i7 is too difficult for my Raspberry Pi.

My workaround, since I didn't have any data on the device yet that I couldn't regenerate, was to repeat the formatting operation on the rpi 3. This gave me something that was usable on both systems.

After reformatting my drive and creating a new LUKS partition from my Raspberry Pi 3 Model B+, the errors ceased to occur. To anyone else looking to create an encrypted LUKS partition on any external/portable drive, I suggest you encrypt it using the slowest/lowest-capacity device you have.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.