The fact that /dev/mapper/cryptrfs does not exist means the encryption process did not complete the second part after the first reboot. It would probably be best to start fresh. A couple of things to note:
The Zymkey must be installed and bound properly before moving on to encryption. The blue LED should be flashing once every three seconds.
Start with a reformatted USB stick for the encryption process. The USB stick should be twice the size of your SD card.
During the encryption process, the LED will stop flashing once every three seconds and will flash constantly.
After the first reboot, login and run “journalctl -fu cfg_SD_crfs”. That will show you progress of the second half of the encryption process. If you see an error there, let us know.
Once the entire process completes, the Zymkey will return to flashing once every three seconds.
I checked the logs…phase 1 complete successfully but in phase 2 I got logs mentioned below -
Dec 06 14:21:12 ubuntu cfg_SD_crfs.sh[1205]: Creating LUKS key…done.
Dec 06 14:22:09 ubuntu cfg_SD_crfs.sh[1205]: Formatting crypto file system on /dev/mmcblk0p2…done.
Dec 06 14:22:09 ubuntu cfg_SD_crfs.sh[1205]: Creating ext4 partition on /dev/mmcblk0p2…
Dec 06 14:22:09 ubuntu cfg_SD_crfs.sh[2577]: mke2fs 1.45.5 (07-Jan-2020)
Dec 06 14:22:24 ubuntu cfg_SD_crfs.sh[1205]: done.
Dec 06 14:22:24 ubuntu cfg_SD_crfs.sh[1205]: Copying files to crypto fs…
Dec 06 14:22:24 ubuntu cfg_SD_crfs.sh[2620]: mkdir: cannot create directory ‘/mnt/cryptrfs’: Read-only file system
Dec 06 14:22:24 ubuntu cfg_SD_crfs.sh[2621]: mount: /mnt/cryptrfs: mount point does not exist.
Dec 06 14:22:24 ubuntu systemd[1]: cfg_SD_crfs.service: Main process exited, code=exited, status=32/n/a
Dec 06 14:22:24 ubuntu systemd[1]: cfg_SD_crfs.service: Failed with result ‘exit-code’.
Dec 06 14:22:24 ubuntu cfg_SD_crfs.sh[2620]: mkdir: cannot create directory ‘/mnt/cryptrfs’: Read-only file system
That “mkdir /mnt/cryptrfs” is trying to create the directory on the USB stick and can’t because the / file system on the USB stick is mounted read-only. For this phase, the system boots up on the USB stick. A guess would be that Ubuntu found errors on your USB stick and booted up read-only.
Do you happen to have a different USB drive you can try? Also, as one of the people noticed earlier in this thread, if you are using a USB 2.0 device, try that device in a USB 2.0 port (black ones) instead of a USB 3.0 port (blue ones).
The LUKS key is protected by the Zymkey in Zymkey hardware only and is not recoverable by design should something go wrong. Copying the header would be of limited use.
It is possible to add an additional key to LUKS encryption at the time of encryption but that would be outside of normal Zymkey operation.
we are having some issues with slow boot time. Specifically the kernel boot time is somewhat slow. 12s compared to 2s normal, any idea why? I read that luks performance in the raspberry pi 4 can be improved by using adiantum instead of aes for encryption, but i would suspect this would not improve boot time?
Raspberry Pi OS Lite 32 bit. I am flexibel on that by the way. i am currently incrementally adding functionality to see when the kernel time increases.
I’m trying to set this up on a RPI CM4 with eMMC so need to follow the additional steps:
Upgrade the bootloader version: Jan. 16 2021
Set the boot order to allow booting off USB: 0xf15
Modify /boot/config.txt and add the line “otg_mode=1” under [all]. This replaces the line, “dtoverlay=dwc2,dr_mode=host” if adde
Only I’m struggling to achieve steps 1 & 2. Does anyone have any guides on how to do this?
I tried doing step 1 via ‘raspi-config’ but then ran into issues doing step 2 the same way but then recieved an error ‘No EEPROM bin file for version 2021-01-10 - aborting’
I’ve set up a raspberry pi with zymkey 4i and encrypted the root fs like explained here.
I now want to clone this setup. I think it would have been better to first set everything up, make backups, then add the encryption and to not keep developing on the encrypted system, right?
Can I just make a decrypted backup, like undoing the encryption and backing everything up to another sd card?
As the zymkey and the sd card are bound together, I cannot just dd the sd card itself to another one.
Can I just dd if=/dev/mapper/cryptrfs of=/dev/sda to some usb stick?
I think I cannot decrypt the sd card again using official methods, as I would have to boot from an USB stick or another device and decrypt the sd card using a key, but the key is stored on the zymkey, I don’t have it. Adding a key is also not possible as I don’t have an existing key…
You are correct in that the Zymkey and SD card are bound together, along with the PI. You cannot dd to another SD-card. The encrypted rootfs will not be unlocked on the new SD card.
When you have your original SD card up and the rootfs is unlocked, you could always just transfer all the files to some other backup location.
The other option is if you still have the USB stick you used as temporary storage it could be used to create another encrypted SD card. The files as they were at the time of your original encryption are left in a tar file so that if you run the process again, you don’t have to copy the whole rootfs again.