I have a uConsole computer and a new NVMe adapter for it. I’m not going to walk around with a terabyte of unencrypted data. That wasn’t an option. I found several good HOWTOs for booting a uConsole off an encrypted NVMe drive, yet none of them worked well on their own. Each left out one essential detail or another.
This is my mashup of those instructions. For testing, I wiped my NVMe drive and started over, following these steps exactly, and at the end booted into a working system.
I claim zero credit for any of these. Much of this is copied-and-pasted from the resources I list at the bottom. Those are the people who did the hard work of figuring this out. My goal was to put combine the working bits of each resource into a single document that includes the best of each.
The gist of it
We’re starting with a uConsole booted from its SD card. From inside that running system, we’ll partition the NVMe drive, encrypt most of it, copy the working system onto the new drive, and make the tweaks that the new setup requires to boot successfully.
Install the dependencies, part 1
We’ll use cryptsetup in the “parent” SD card-based OS.
$ sudo apt install cryptsetup
Partition the drive
This is easiest with the desktop’s GParted command. If you’re using the terminal anyway, you can do this from the CLI.
$ sudo parted /dev/nvme0n1
mklabel gpt
yes
mkpart primary fat32 1M 513M
mkpart primary ext4 513M 100%
quit
Encrypt the root volume and make the filesystems
Now we prepare the drive for holding data. We format partition 1 with the FAT32 filesystem that the bootloader wants. Then we use cryptsetup encrypt partition 2.
$ sudo cryptsetup luksFormat -c xchacha20,aes-adiantum-plain64 /dev/nvme0n1p2
$ sudo cryptsetup open /dev/nvme0n1p2 ssd # Creates /dev/mapper/ssd
$ sudo mkfs.vfat /dev/nvme0n1p1
$ sudo mkfs.ext4 /dev/mapper/ssd
$ sudo lsblk -o NAME,UUID,PARTUUID
In the lsblk command’s output, note:
PARTUUIDfor the NVMe/boot/firmwarefilesystemUUIDfor the new/filesystem
Mount and populate the new volumes under /mnt
When these steps are done, we’ll have a clone of our parent system in /mnt. See the -x flag to rsync? That says “stay in this one filesystem and don’t recurse into others”, so that we’re not cloning /proc and /sys, and so on.
$ sudo mount /dev/mapper/ssd /mnt
$ sudo rsync -aAXHvx / /mnt/
$ sudo mount /dev/nvme0n1p1 /mnt/boot/firmware
$ sudo rsync -aAXHvx /boot/firmware/ /mnt/boot/firmware/
Chroot into /mnt
From now on, the rest of these commands will run on the new, encrypted root volume.
$ for dir in sys dev proc ; do sudo mount --rbind /$dir /mnt/$dir && sudo mount --make-rslave /mnt/$dir ; done
$ sudo chroot /mnt
Quick note about editors
Also, I like using vi for quick-and-dirty system file edits. If that’s outside your comfort zone, replace vi with nano from now on. But really, if you’re going to be using Linux much, at least get the vi basics down. You’ll thank me later.
Of course, vi’s main purpose is to bootstrap Emacs, and then you can uninstall vi.
Configure fstab & crypttab
The parent OS has it’s idea of where / and /boot/firmware live. Now we configure the child OS with its new locations.
> vi /etc/fstab
============
# Find the line that mounts /boot/firmware and replace it with:
PARTUUID={{PARTUUID of the new /boot/firmware}} /boot/firmware vfat defaults 0 2
# Find the line that mounts / and replace it with:
/dev/mapper/ssd / ext4 defaults,noatime 0 1
============
> vi /etc/crypttab
============
# Append this line:
ssd UUID={{UUID of the new "raw" /}} none luks,discard
============
Install the dependencies, part 2
We’ll use these tools to make a new initramfs inside the child OS.
> apt install busybox cryptsetup cryptsetup-initramfs initramfs-tools
Edit initramfs.conf and change modules=dep to modules=most
This may not be needed. This was the default on the OS image I used.
> vi /etc/initramfs-tools/initramfs.conf
Add Kernel modules to initramfs
Add these modules to the initramfs so it display the boot-time encrypted volume password prompt, and can unlock the encrypted root volume.
> vi /etc/initramfs-tools/modules
============
# --- Crypto modules (AES-XTS + SHA256, ARM hardware-accelerated) ---
aes_arm64
aes_ce_blk
aes_ce_cipher
sha256_arm64
sha256_ce
dm-crypt
xts
# --- Display modules (needed so the password prompt shows on the uConsole screen) ---
drm
drm_kms_helper
drm_shmem_helper
drm_dma_helper
drm_ttm_helper
drm_display_helper
drm_panel_orientation_quirks
ttm
cec
backlight
ocp8178_bl
panel-cwu50
vc4
v3d
drm-rp1-dsi
============
Create Display Init Script
This is the bit that turns on the screen in text mode so we know when to enter the drive encryption password.
> vi /etc/initramfs-tools/scripts/init-top/display
============
#!/bin/sh
PREREQ=""
prereqs() { echo "$PREREQ"; }
case $1 in prereqs) prereqs; exit 0;; esac
# Load display stack. Order matters.
modprobe drm
modprobe drm_kms_helper
modprobe backlight
modprobe ocp8178_bl # uConsole backlight controller
modprobe panel-cwu50 # uConsole LCD panel driver
modprobe vc4 # Broadcom VideoCore GPU
modprobe v3d # Broadcom V3D 3D engine
sleep 1 # Give the panel time to initialize
modprobe drm-rp1-dsi # RP1 DSI bridge (connects SoC to panel)
modprobe fbcon # Framebuffer console (renders text on screen)
============
> chmod a+x /etc/initramfs-tools/scripts/init-top/display
Create Kernel Postinst Hook
This is suppose to rebuild the initramfs when we upgrade to a new kernel. I haven’t tested it yet.
> vi /etc/kernel/postinst.d/initramfs-rebuild
============
#!/bin/sh -e
version="$1"
# Only rebuild for the currently running kernel
[ "$version" = "$(uname -r)" ] || exit 0
# Back up existing initramfs before overwriting
[ -e /boot/firmware/initramfs_2712 ] && \
cp /boot/firmware/initramfs_luks_nvme.img /boot/firmware/initramfs_luks_nvme.img.bak
update-initramfs -c -k "$version"
mkinitramfs -o /boot/firmware/initramfs_luks_nvme.img "$version"
============
> chmod a+x /etc/kernel/postinst.d/initramfs-rebuild
Build Initramfs
Now we manually do a stripped-down version of the above to create our first initramfs.
> update-initramfs -c -k "$(uname -r)"
> mkinitramfs -o /boot/firmware/initramfs_luks_nvme.img "$(uname -r)"
Configure Boot
This tells the system how to enable the NVMe drive, and how to boot into it.
> vi /boot/firmware/config.txt
============
[pi4]
...
enable_uart=1
dtparam=pciex1=on
[all]
...
auto_initramfs=1
initramfs initramfs_luks_nvme.img followkernel
============
> vi /boot/firmware/cmdline.txt
============
console=serial0,115200 console=tty1 root=/dev/mapper/ssd cryptdevice=UUID={{Same UUID of / as in /etc/fstab}}:ssd rootfstype=ext4 fsck.repair=yes rootwait fbcon=rotate:1 psi=1 quiet loglevel=3 cfg80211.ieee80211_regdom=US
============
In confess, I didn’t do exactly this. I kept some of the original cmdline.txt. Instead of rootwait fbcon=rotate:, I have rootwait splash plymouth.ignore-serial-consoles fbcon=rotate:1. Now I have a splash screen but don’t see the prompt to enter the drive encryption password. I just have to know when to enter it, and then the little computer does the rest. Yes, that’s a little risky: what if something breaks and I can’t see the error message? On the other hand, good luck to a casual thief even knowing where to begin with the thing.
Exit and power off
Leave the chroot and shut down the uConsole.
> exit
$ sudo shutdown -h now
Cross your fingers
Now eject the SD card from uConsole and turn it back on. With any luck, it’ll prompt you for the passphrase to unlock your encrypted NVMe root partition and then boot into a working system!
Now what?
Bump up the swap
I configured my uConsole to have 4x as much swap as RAM. That works out to 32GB, or about 3% of my NVMe. In exchange, I’m unlikely to ever run out of memory again. NVMe swap is decently quick, unlike sticking it on a spinning rust hard drive.
$ cd /etc/rpi
$ sudo mkdir swap.conf.d
$ sudo -e swap.conf.d/
============
[Main]
Mechanism=swapfile
[File]
RamMultiplier=4
MaxSizeMiB=65536
============
