Encrypting Your Root File System on Raspberry Pi - using LUKS & dm-crypt


Hi Phil, thank you for your help. Now it works! But I don’t know why. Maybe I made a fault during the installation several times? I’ve performed the getting started guide again and after bindig the key to the pi I made a backup image. Then I encrypted the PIs root partition and it works as expected. The system booted with the encrypted root partition.

Is it possible that the installation skript has made only a partial installation and zymkey is nevertheless bound to the pi? Or maybe the encrytion process run only partly? I’ve made the first installations with a gsm modem and the last one via lan.



Good to read that you now have your encrypted volume working.

Using a LAN connection is always preferred for a data intensive process like encryption. GSM should work, but could introduce some small errors if drop out happens.

(FYI, we have recently upgraded the script to make the process more robust for situations like this.)


@Gtewksbury we have noticed a few other customers having similar problems when encrypting on a Raspberry Pi model 3B+.

We have made a a few changes to the encryption script to deal with possible edge conditions. I suggest you try the process one more time, as these changes may also address your problem too. We suggest you restart from getting started, then following the encryption process.

Also please refer to @Scott_of_Zymbit post regarding using the correct partition: Encrypting Your Root File System on Raspberry Pi - using LUKS & dm-crypt

Let us know you progress.


Thanks for the suggested mitigations!


I have not seen this specific error. Having said that, we just fixed an edge case in our encryption script in the last couple of days that may have caused something like this to happen. It may be worth it to try again. Make sure to wipe out your external drive before proceeding.


@Gtewksbury, are you on Noobs? If so, the root file system is on partition 7 and the script will not work under its default conditions.



I also had interest (and still interested) in Kali for the purpose of an Edge Device. Primarily for LUKS Nuke functionality. (To work along side Zymkey)

Ran into some issues out of the box with Kali as by design, Kali wants to be left untraceable (you’ll need to tweak settings, etc which in the end makes Kali not Kali anymore). Controlling “over the wire/air” updates provides some other challenges as well. So depending on the purpose of your device, and experience with Kali, it may or may not be easy to get it working. The list is long to get it to work.

If you’re like me and the only intention for Kali was it’s Nuke functionality, there are other means of destroying Zymkey key storage when a breech is detected.

In the end, I reminded myself what my intent was, and then soon realized “I have a device that really isn’t Kali anymore.”

Out of curiosity, are you planning a fleet for Kali devices? Or single device? And for what intent do you want to run Kali?


Can you auto mount LUKS encrypted partition without entering password on boot for unattended setup.

How can you do this with Zymkey?


@doxo - this is exactly the purpose of Zymkey; it provides a “password” (named UKz - UserKeyZymbit) to LUKS, allowing for unattended operation. The “password” is based upon a measured system fingerprint (and other materials), and is automatically managed and protected by Zymkey.

This post explains how to installed Zymkey into your application. Top >

1 Like

During today’s external USB encryption process reports:
“Failed to fetch https://zk-sw-repo.s3.amazonaws.com/apt-repo-stretch/pool/main/z/zksaapps/zksaapps_1.0-8_armhf.deb Hash Sum mismatch”

I can not continue. Please help!


Some apt maintenance was the solution:
apt-get clean
rm -rf /var/lib/apt/lists/*
apt-get clean
apt-get update


Good to hear a little house cleaning solved your problem !