So, to begin with, I've read the guides and posts about getting a full root encryption going. I don't want to do that for several reasons, one of which is performance. I should probably add here that I'm using a Raspberry Pi 4, so no hardware AES. I'm using the faster xchacha20,aes-adiantum-plain64 as recommended by a number of guides (which certainly did benchmark a lot faster on my RPi) but it's still going to take away from the already extremely limited CPU power to access things and I'd rather as much as possible not require this. I see absolutely no reason why the non-private, fairly standard and even expected system files should be encrypted anyway. I'm hoping to try to use this thing for stuff where that limited CPU power may be a problem as it is, so I definitely don't need to minimize that background usage. (Yes I know it's not much, but again, not necessary and things will be tight, so why waste?) All the actually private data I'll ever have on here will be in my home folder, so there really isn't a security issue in this. Of course, the point is to have a password prompt on startup, not a keyfile.
Now I've done all the obvious stuff. Of course I installed cryptsetup and cryptsetup-initramfs as any Debian-based system would need. Just to be sure, I went ahead and installed initramfs-tools and manually added the crypto stuff to the /etc/initramfs-tools/modules as well as changing MODULES from dep to most in /etc/initramfs-tools/initramfs.conf then regenerating the initial ramfs via "update-initramfs -u -k all". I even verified with lsinitramfs that even the system generated initial ramfs include the cryptsetup binary as well as the encryption modules. Just installing cryptsetup-initramfs likely already did all that — I'm just covering all bases here. Just for kicks and giggles I even tried adding "cryptdevice=/dev/mmcblk0p3:crypthome" to /boot/firmware/cmdline.txt though, as expected, that made no difference. (And yeah, if you haven't guessed from that, my encrypted partition is a third partition I made on the same Micro-SD card. Naturally I created an appropriate crypttab and edited fstab. I'll go ahead and include them since someone will ask:
/etc/crypttab:/etc/fstab:I also tried identifying the partitions by UUID in both parts (yes, using the correct two separate UUIDs,) but with no visible change. Under the circumstances that seems pointless anyway (/dev/mmcblk0 shouldn't move around.)
Now, what currently happens is no password prompt happens, but since /home is auto, it eventually times out. It takes quite a long while. I have enabled the root account (and of course set a password on it) so I can log in as root for the debug console then manually run cryptsetup luksOpen and mount the mapped partition once it's opened. This works 100% and then if I exit the debug console the bootup process continues without error and I have an encrypted /home. There are a few reasons it would be problematic to noauto it, not the least of which being that things like NetworkManager are expecting the user's home folder (so no Internet access until it gets around to it!) Anyway, this proves the necessary modules are in there and I can mount it correctly manually. The only thing lacking, I guess, is the usual script isn't running to actually do the prompt and mounting. I don't know enough about initial ramfs stuff to know how to manually fix that.
(And yes, to be clear, I know that sometimes the password prompt is hidden in a mess of startup text. I'm used to that on my other systems. There is not a hidden prompt. There simply just is no prompt. I've tried.)
I feel like it may be just as simple as telling it to run whatever script cryptsetup-initialramfs is supposed to be adding — unless that's just missing from the aarch64 version of the package? If so, could it be copied over? I believe it's just a script, not a binary (cryptsetup is the binary and that's definitely in there already.)
Is there anything at all I'm missing? Anything else I can try? This is with the current Trixie-based RaspiOS, fully updated and I do have Debian Trixie installed on a partition on my main PC, so can even access the x86-64 version of the exact same thing directly, but I don't know what really to look for. (Again, messing with an initial ramfs isn't really my thing.)
And in case there is any confusion or doubt about this, an encrypted /home but not encrypted / (root) does work in most standard distros on PC. I've done this setup with Debian Bookworm, Trixie, Linux Mint (and I think Xubuntu and/or Lubuntu as well,) Arch, CachyOS (Arch-Based,) Manjaro (also Arch-based,) and I think even Fedora. Aka, on PC it Just Works™. So that means whatever is different is specific to whatever changes are made in the aarch64 package or how it's set up.
---
The guides and posts I can most remember having gone over:
viewtopic.php?t=395799
viewtopic.php?t=363217
https://rr-developer.github.io/LUKS-on-Raspberry-Pi/
https://ianhomer.com/raspberry-pi-encrypted-drive/
And, well, a bunch of others. I did a lot of searching around. But these were the most helpful and direct I guess. It doesn't help that most predate a lot of changes made some two or three years ago.
Now I've done all the obvious stuff. Of course I installed cryptsetup and cryptsetup-initramfs as any Debian-based system would need. Just to be sure, I went ahead and installed initramfs-tools and manually added the crypto stuff to the /etc/initramfs-tools/modules as well as changing MODULES from dep to most in /etc/initramfs-tools/initramfs.conf then regenerating the initial ramfs via "update-initramfs -u -k all". I even verified with lsinitramfs that even the system generated initial ramfs include the cryptsetup binary as well as the encryption modules. Just installing cryptsetup-initramfs likely already did all that — I'm just covering all bases here. Just for kicks and giggles I even tried adding "cryptdevice=/dev/mmcblk0p3:crypthome" to /boot/firmware/cmdline.txt though, as expected, that made no difference. (And yeah, if you haven't guessed from that, my encrypted partition is a third partition I made on the same Micro-SD card. Naturally I created an appropriate crypttab and edited fstab. I'll go ahead and include them since someone will ask:
/etc/crypttab:
Code:
crypthome/dev/mmcblk0p3noneluks,discardCode:
proc/procprocdefaults0 0PARTUUID=1d4b5444-01/boot/firmwarevfatdefaults0 2PARTUUID=1d4b5444-02/ext4defaults,noatime0 1/dev/mapper/crypthome/homeext4defaults,noatime,discard0 0Now, what currently happens is no password prompt happens, but since /home is auto, it eventually times out. It takes quite a long while. I have enabled the root account (and of course set a password on it) so I can log in as root for the debug console then manually run cryptsetup luksOpen and mount the mapped partition once it's opened. This works 100% and then if I exit the debug console the bootup process continues without error and I have an encrypted /home. There are a few reasons it would be problematic to noauto it, not the least of which being that things like NetworkManager are expecting the user's home folder (so no Internet access until it gets around to it!) Anyway, this proves the necessary modules are in there and I can mount it correctly manually. The only thing lacking, I guess, is the usual script isn't running to actually do the prompt and mounting. I don't know enough about initial ramfs stuff to know how to manually fix that.
(And yes, to be clear, I know that sometimes the password prompt is hidden in a mess of startup text. I'm used to that on my other systems. There is not a hidden prompt. There simply just is no prompt. I've tried.)
I feel like it may be just as simple as telling it to run whatever script cryptsetup-initialramfs is supposed to be adding — unless that's just missing from the aarch64 version of the package? If so, could it be copied over? I believe it's just a script, not a binary (cryptsetup is the binary and that's definitely in there already.)
Is there anything at all I'm missing? Anything else I can try? This is with the current Trixie-based RaspiOS, fully updated and I do have Debian Trixie installed on a partition on my main PC, so can even access the x86-64 version of the exact same thing directly, but I don't know what really to look for. (Again, messing with an initial ramfs isn't really my thing.)
And in case there is any confusion or doubt about this, an encrypted /home but not encrypted / (root) does work in most standard distros on PC. I've done this setup with Debian Bookworm, Trixie, Linux Mint (and I think Xubuntu and/or Lubuntu as well,) Arch, CachyOS (Arch-Based,) Manjaro (also Arch-based,) and I think even Fedora. Aka, on PC it Just Works™. So that means whatever is different is specific to whatever changes are made in the aarch64 package or how it's set up.
---
The guides and posts I can most remember having gone over:
viewtopic.php?t=395799
viewtopic.php?t=363217
https://rr-developer.github.io/LUKS-on-Raspberry-Pi/
https://ianhomer.com/raspberry-pi-encrypted-drive/
And, well, a bunch of others. I did a lot of searching around. But these were the most helpful and direct I guess. It doesn't help that most predate a lot of changes made some two or three years ago.
Statistics: Posted by Nazo — Fri Feb 20, 2026 11:23 am — Replies 3 — Views 110