Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I just experimented some simplifications for Debian 12 based RPi OS #11

Open
LeGuipo opened this issue Dec 17, 2023 · 6 comments
Open

Comments

@LeGuipo
Copy link

LeGuipo commented Dec 17, 2023

Hi all,

Almost two years ago, I followed the procedure to the letter (except the infamous "-keysize" parameter) to successfully encrypt my root partition for my Debian 11 based Raspberry Pi OS installation.

Now that I’ve gained more experience with Linux stuff, I decided to be a little more adventurous during my upgrade to Debian 12 based RPi OS. Note that I’ve selected the standard, not lite, not full, official Raspberry Pi image.

So in the hope to help to streamline the procedure, there are my observations :

  1. Only cryptsetup package is needed to be installed, busybox and initramfs-tools are present by default.
  2. RPi OS seems to implement initramfs auto update already with proper parameters upon kernel updates. So it is not necessary to create the /etc/kernel/postinst.d/initramfs-rebuild script.
  3. /etc/initramfs-tools/hooks/luks_hooks on the other hand, has to be created. BTW I installed the optional cryptsetup-initramfs package, that seems to include cryptsetup and also probably fdisk binaries to the initramfs. However, resize2fs is naturally not included.
  4. /etc/initramfs-tools/modules is completely empty by default and need to be populated as described.
  5. Now the creation of initramfs can be done with the simple command sudo update-initramfs -u. It will include all the needed binaries and modules, and create the images with the appropriate filenames and all other components conforming with the distribution’s configuration. Notably, each installed kernel version will keep a dedicated image, and for the comfort of non-qwerty keyboard users like me, the proper keymap will be set for use during initramfs operations and passphrase input during boot.
  6. The file /boot/firmware/config.txt can be left untouched as it already includes the lineauto_initramfs=1
  7. The rest of the procedure is OK except the final initramfs rebuild that has to be dealt again with the command sudo update-initramfs -u.

Voilà :)

mfinelli added a commit to mfinelli/arch-install that referenced this issue Feb 13, 2024
@whyme12
Copy link

whyme12 commented Feb 27, 2024

At least in Raspberry Pi OS lite "cryptsetup-initramfs" is missing now and needs to be installed.

And KEYMAP=y needs to be set in /etc/initramfs-tools/initramfs.conf

@embed123linux
Copy link

embed123linux commented May 13, 2024

Hello @LeGuipo @whyme12 I am currently trying this on raspberry pi 4 (OS: Bookworm 32-bit; Release date: March 15th 2024). However, I cannot boot into intramfs shell as described in the manual. My /boot/firmware/cmdline.txt is

console=serial0,115200 console=tty1 root=/dev/mapper/sdcard rootfstype=ext4 fsck.repair=yes rootwait plymouth.ignore-serial-consoles cryptdevice=/dev/mmcblk0p2:sdcard

And /etc/fstab entry:

proc            /proc           proc    defaults          0       0
PARTUUID=265668ac-01  /boot/firmware  vfat    defaults          0       2
/dev/mapper/sdcard    /           ext4    defaults,noatime  0       1

The boot is stuck at:

.
.
[    5.032932] vc4-drm gpu: [drm] Cannot find any crtc or sizes
[    5.041245] vc4-drm gpu: [drm] Cannot find any crtc or sizes
[    5.048063] vc4-drm gpu: [drm] Cannot find any crtc or sizes
[    5.082477] NET: Registered PF_ALG protocol family
[    5.226722] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: [email protected]

Do you know what is the issue here?

Thanks in advance

@LeGuipo
Copy link
Author

LeGuipo commented May 13, 2024

I don’t see the cause of your issue. It’s like no instruction to mount any partition does exist. Your fstab seems to be good. What about /etc/crypttab ? Do you use Rapsberry Pi OS or pure Debian ?
Also it takes time for the initramfs to switch to console mode but it should at least show it’s trying to find the root partition.

This is my /boot/firmware/cmdline.txt:
console=serial0,115200 console=tty1 root=/dev/mapper/sdcard rootfstype=ext4 fsck.repair=yes rootwait cfg80211.ieee80211_regdom=FR cryptdevice=/dev/mmcblk0p2:sdcard

May it be possible that plymouth is the culprit ?

@embed123linux
Copy link

Hi @LeGuipo thanks for the update. I removed console=tty1 parameter and added break=premount option to cmdline.txt
Then the initramfs shell is loaded.
I could also decrypt manually using luksOpen. Then I updated the initramfs using (removed break=premount parameter in cmdline.txt)
sudo update-initramfs -u

Did a reboot expecting to get a passphrase prompt.
However, the initramfs shell is loaded again and I have to decrypt manually.

/etc/crypttab:

# <target name>	<source device>		<key file>	<options>
sdcard /dev/mmcblk0p2 none luks

Any idea why this is happening?

@LeGuipo
Copy link
Author

LeGuipo commented May 14, 2024

Since your crypttab seems fine, I don’t understand why your initramfs refuses to start to unlock sdcard automatically. I still suspect plymouth, because it’s clearly instructed to ignore-serial-consoles (why this option ?), and it is not supposed to be preinstalled with Raspi OS.
At this point there might be a missed step, or your operating system is maybe too modified to be compatible with the procedure. The best I can do is to suggest you to redo it on a clean installation for better luck.

@embed123linux
Copy link

Yes, plymouth was the issue. I removed ignore-serial-consoles option and it works fine now. I don't know either why this is added by default. Raspi OS is the latest official Bookworm release.

From my understanding, the encryption master key is encrypted again using a key derived from the passphrase. This is part of header and is essential to open the volume by recomputing the master key. Hence this is stored with the actual data itself (in filesystem). But is there any way to store the key that is used to encrypt the master key and also header file in a secure element or USB HSM device? Then while decrypting fetch the header file from secure element or USB HSM device.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants