I have been trying to get Raspbian Jessie, installed from the image to boot with an encrypted root partition.

I was successful in following the guide here.

When I boot the Pi, it drops to an initramfs prompt, then I unlock the partition with

# cryptsetup luksOpen /dev/mmcblk0p2 sdcard
# exit

and it boots into Debian. Great!

However, there are some issues. When I try to update the initramfs file with:

# sudo mkinitramfs -o /boot/initramfs.gz

in Debian, the Pi doesn't successfully reboot to the initramfs prompt. It just hangs with a blinking cursor after showing the pixel logo. When I restore to my backed-up boot image, I get the initramfs prompt again and can boot from the encrypted root.

The second issue is that I did not properly configure dropbear; it appears to be configured to use DHCP. This means that when I log in it gets a random IP address. I need to update the configuration to a fixed IP address so that I can log into the Pi headless after a reboot, but without the ability to update the initramfs I don't know how to fix this.

Given that I can't even get an initramfs prompt after the update, I'm really not sure how to even start solving this problem, so any hints would be great. I'll provide whatever information that will be helpful to solving this issue.

  • 1
    I vaguely recall hearing a while back that systemd, the default init system going forward from the current "Jessie" version of Debian and thus Raspbian which is derived from it once had problems with encrypted file-systems. I'm guessing that at least some part of the issues were resolved but in your particular case you might wish to consider switching back to the sysV initwhich is what that 2013 article would be expecting (it mentions the "Wheezy" version of Raspbian which is the previous version which would have had a default init of the sysV one)...
    – SlySven
    Jan 6, 2017 at 19:07
  • 1
    It seems unlikely to be a problem related to systemd; I run several different standard Debian 8 systems with encrypted root partitions without problems. My suspicion is that the code to prompt for the encryption passphrase either isn't there or isn't compatible with whatever's putting up the splash screen logo. (I get a text mode prompt for the passphrase during the system boot.) When I get a chance, I'll compare the startup scripts on my Pi and on one of my Debian laptops.
    – cjs
    Apr 5, 2017 at 16:07
  • Regarding the DHCP. Lock it directly on your router. Not on the devices. It could be a pain in the arse otherwise.
    – kuzeyron
    Sep 10, 2017 at 17:56
  • I recommend you to have a look at the Encryption-guide of Robpol86 (robpol86.com/raspberry_pi_luks.html) when one thing I recognized in the guide you used is that there is no initramfs-rebuild script which runs after each of your kernel updates. I have been using the guide of Robpol on many Jessie and Stretch systems for a long time and never had any problems. Of course the guide will not help you regarding your dropbear issues. Jul 2, 2019 at 9:55

3 Answers 3


These suggestions are based on experience from Linux on x86 machines, rather than the RasPi.

  1. In my experience, whole-disk encryption is bad for performance, is tricky to troubleshoot and makes upgrades difficult. I would avoid it.
  2. What is preferable is to leave the root partition unencrypted, but keep a separate /home partition, where all your used data will be kept anyway, and encrypt just that. This has far less performance impact, and it is easier to get working.
  3. If you're going to run a server or something which might have private data outside of /home, then consider a 3-way split: /boot, root and /home. Leave /boot unencrypted and just encrypt root and /home. This is a little more involved than just /home but still a lot easier to get working.

Disable any splash screen and check the output during boot time. In the cmdline.txt (in /boot/cmdline.txt) make sure you have rootwait logo.nologo nosplash.

There must have been a problem with your update or the initramfs. Make sure you include the proper modules into it by pointing to the target kernel version like so: sudo mkinitramfs -o /boot/initramfs.gz -k -v 4.14.78-v7+ This will target the kernel module of that specific version installed, and grab all modules fro /lib/modules/ properly.

If there is a mismatch, there could be problems with loading the right kernel modules. Also check your initramfs-tools.conf and hooks / scripts.

Regarding the IP, you can have a fixed IP with he "IP=" kernel boot parameter. But it would be best to configure that on the DHCP server, which is most likely your router.


Try to revert firmware back and then try again:

To revert give the github commit hash.

To upgrade/downgrade to a specific firmware revision, specify its Git hash (from the https://github.com/Hexxeh/rpi-firmware repository) as follows:

sudo rpi-update fab7796df0cf29f9563b507a59ce5b17d93e0390

And to try upgrading again use:

sudo apt-get update && sudo apt-get upgrade
sudo shutdown -r now

Then after that process finishes update to the next rpi-update:

sudo BRANCH=next rpi-update
sudo shutdown -r now

After that you should be able to fallow the instructions here

make sure to skip the first 2 code blockes as I just modified those and gave the working one above!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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