The *minimal* changes that must be made to the unencrypted backup images, to negate leftover configurations only appropriate for an encrypted rootfs, are as follows:Greedy me, I want to have my cake, and eat it, and sell it too:
1. I want an encrypted roots for security (since I might have personal info on this desktop pi5). Luckily for me, that's done, via bls's sdm-cryptconfig.
2. I want to continue using image-backup to make incremental backups (because I've always done so, and it works great), even though it doesn't handle an encrypted rootfs out of the box. Though perhaps I've patched it to do so, I hope correctly (see the following diff between RonR's image-backup and my slightly hacked version:3. I want to continue to use Raspberry Pi imager to restore such backups, even though it's completely unaware of my desire to create an encrypted rootfs. And I don't think I want to hack around in there.Code:
172c172< e2label "${LOOP}p2" "$(e2label ${ROOT_DEV_P}2)" &> /dev/null---> e2label "${LOOP}p2" "$(e2label ${ROOT_PART_ORIG})" &> /dev/null221a222,225> ROOT_PART_ORIG=$ROOT_PART> if [ "${ROOT_PART}" = "/dev/mapper/cryptroot" ]; then> ROOT_PART=$(awk '/cryptroot/ {print $2}' /etc/crypttab)> fi229c233< if [[ "${PTTYPE}" != "dos" && "${PTTYPE}" != "gpt" ]]; then---> if [[ "${PTTYPE}" != "dos" && "${PTTYPE}" != "gpt" && "${PTTYPE}" != "crypto_LUKS" ]]; thenThinking out load again: that's the problem on the horizon - these files/programs/configs came off a system where the rootfs was encrypted, yet they'll be restored onto a system where it isn't encrypted. I believe bls installed some extra programs to support encryption, but it shouldn't matter that they are on there as long as they don't get invoked, i.e., as long as I tweak settings so that nobody thinks encryption is active on the restored system. (I'll have to look further at what sdm-cryptconfig had to change to encrypt, in order to undo it.) Then I'll have to go into the backed up or burned images and negate those changes to allow sane booting on the now-unencrypted system. Then I will have to run sdm-cryptconfig AGAIN to re-encrypt. This is very sub-optimal, but I rarely have to restore - as long as a path exists somehow...The image could be burned to a card or drive, but there might be problems booting the result, since various programs and settings would be set up for an encrypted rootfs, while the rootfs as created by imager would be unencrypted..
Code:
# script to unconfigure encryption on an image that had been# encrypted by sdm-cryptconfig and backed up by a hacked image-backup# usage: encryptoff fstab cmdline.txt crypttab# the originals will be saved as .encrFSTAB=$1CMDLINE=$2CRYPTTAB=$3# get the boot partition's PARTUUID from fstab and replace # the 01 with a 02 to make a root partition PARTUUIDPARTUUID_B=`grep boot $FSTAB | cut -f1 -d " "`PARTUUID_P=${PARTUUID_B%01}02# replace the "/dev/mapper/cryptroot" in fstab with the real rootfs PARTUUIDsed -i.encr "s#/dev/mapper/cryptroot#$PARTUUID_P#" $FSTAB # replace the "/dev/mapper/cryptroot" in cmdline.txt with the real rootfs PARTUUID# ALSO remove the "cryptdevice=/dev/sda2:cryptroot" phrase# ALSO remove the "rw" phrasesed -i.encr -e "s#/dev/mapper/cryptroot#$PARTUUID_P#" -e "s# cryptdevice=.*:cryptroot##" -e "s# rw##" $CMDLINE# comment out the cryptroot line in /etc/crypttabsed -i.encr 's/^cryptroot/#cryptroot/' $CRYPTTABCode:
sudo ~/bin/encryptoff /media/pi/rootfs/etc/fstab /media/pi/bootfs/cmdline.txt /media/pi/rootfs/etc/crypttabCode:
cryptsetup: Waiting for encrypted source device UUID=...Statistics: Posted by tinker2much — Thu Feb 01, 2024 6:48 pm