DietPi-Drive_Manager | Add dm-crypt/LUKS support

[notDavid]

Hi,

after formatting an USB partition with dm-crypt/LUKS encryption mode you cannot move the /mnt/dietpi_userdata folder to it. Of course the drive would need to be opened/decrypted/mounted first after every boot, before any services that rely on /mnt/dietpi_userdata can be started.

Would it be possible to add this as an option?

It would be a good start to simply have the ability to manually start services with dietpi-services start after mounting the disk (as long as ssh works.)

[Joulinar]

Hi,

there is a related Forum post to this.

https://dietpi.com/phpbb/viewtopic.php?t=7275

I guess it was you as well?

The main problem is not to manuell start the services once your encrypted disk was mounted. It's more coming from the fact, that DietPi already have issues to boot correctly if /mnt/dietpi_userdata was moved to an encrypted device. I tested it yesterday evening and it took me more than 30 minutes to get an SSH promt after reboot. Even after I was able to login, quite a lot of issues.

[notDavid]

I guess it was you as well?

Ah yes sorry, i wasn't sure whether a feature request better belongs here or in the forums...

Thank you for looking into it, if it's possible to somehow work around it i will be happy to try it. If not, perhaps one day it can be added as a feature, i think it would be a useful addition 👍

[MichaIng]

@notDavid Many thanks for your report. Generally requests here on GitHub are prefectly fine.

We'll have to dig into it, whether such encrypted mount can be accessed as every other file system by software or if there are limitations which would break other software R/W. Another important need is that the file system supports UNIX permissions, hence chown/chmod must work normal.

[Joulinar]

@MichaIng I was playing with it yesterday night and I was able to mount/access the encrypted USB stick as normal drive. As well I was able to transfer /mnt/dietpi_userdata/ using dietpi-software. However, during boot my systems was facing a lot of timeouts (30 minutes boot until SSH was working) because system was trying to access to encrypted device. Feel free to contact me if you need some further inside how I did it 😉

[MichaIng]

@Joulinar Thanks for testing :+1:. What must be assured is that the decrypted mount must be done at boot automatically before any end user service starts. Either there is some systemd unit available or fstab entry (which leads to auto-generated systemd unit), and this could then be added to dietpi-postboot.service After= line. Actually I was hoping that an fstab entry would be part of local-fs.target, hence the encrypted mount is done at very early boot stage automatically.

[notDavid]

@MichaIng

What must be assured is that the decrypted mount must be done at boot automatically

If it would be done automatically then there is no point in encrypting the data. It's important that the decryption is done manually, by the user. So the decryption key is not stored anywhere.

[MichaIng]

@notDavid Yeah you're right. Only point would then be to not have unencrypted data on an offline drive, hence more something for a desktop work station: As long as it's running, you need the data decrypted, when you finished your work, you shut it down, and the drive is encrypted... Hmm but data is decrypted on boot, not directly accessible for users without login but for services already...

Okay so its true that automated decrypted mount breaks the idea/reason for decryption in very most cases. Since dietpi_userdata must be decrypted for services to access, this does not fit your use case then.

Generally, if data must be only available for you, hence your login user, but no background services, then I would mount the encrypted file system into your users home directory, or as a sub directory in /mnt/dietpi_userdata. This as well fits the FHS intention.

[Joulinar]

@notDavid and that's the point where it become tricky as during boot there is no point where you can enter a password.

[MichaIng]

@Joulinar Jep, no chance without having the key stored somewhere, breaks concept in most cases. So buttom line: You cannot reasonably encrypt a filesystem/directory that needs to be accessed by system services. Since dietpi_userdata is used by system services (when doing related dietpi-software installs), it cannot be placed into an encrypted drive/fs. The other way round you can mount an encrypted drive/fs/dir as subdirectory into dietpi_userdata to store sensitive data to decrypt manually only.

So taking all together, I think it would be more reasonably to add the feature to DietPi-Drive_Manager to create an encrypted directory/mount inside either users home or dietpi_userdata as subdir, or encrypt a drive as a whole, which must then not be used for dietpi_userdata or swapfile, or of course root+boot mount.

[notDavid]

@MichaIng

You cannot reasonably encrypt a filesystem/directory that needs to be accessed by system services

What i currently do in Ubuntu is simply systemctl disable all the services that depend on the encrypted usb data, and when i (re)boot the system, i first manually decrypt/mount the USB drive, followed by systemctl start all the services.

Would this not be possible in Dietpi? To have a config setting to not automatically start the additionally installed software/services at boot which rely on dietpi_userdata, so you can manually start them after decrypt/mount with something like dietpi-services start ?

Maybe I could even do that manually without any changes in Dietpi by disabling a few services. However the biggest problem is that booting is currently not working properly because of the timeouts like @Joulinar mentioned:

[MichaIng]

@notDavid You could exclude all services from DietPi-Services control: dietpi-services There is not yet a feature to skip service start all together, would be actually nice 🤔.

But your error log logs have nothing to do with services trying to access the dir. This is long before DietPi-PostBoot starts them. I think this is due to an fstab entry or systemd unit trying to mount the drive automatically which fails due to missing key input (?). Probably dietpi-drive_manager added the drive to fstab automatically. The problem is that this setup is not an own file system with special mount options, but an ordinary e.g. ext4 mount (after being decrypted), if I understood the instructions correctly. So when it has been mounted, dietpi-drive_manager detects it as regular mounted drive and adds an fstab entry automatically.

---

They use /dev/mapper/cryptroot as device path, but /dev/mapper/ is a generic path for mapped devices, AFAIK, and cryptroot is just an example name which can be freely chosen. So we could exclude /dev/mapper/* devices from being added to fstab automatically, instead preserve those entries (leaving them untouched, if added manually), like we do for encrypted file system types. This theoretically might break a few other use cases, but practically nobody uses (manual setup) /dev/mapper/ without handling the mount and in case fstab entry manually as well...

@notDavid Just to be sure, could you paste, after mounting the encrypted drive:

df -T
blkid
lsblk

• Erase/mask any private strings, of course, especially if anything related to encryption key/hash is contained somewhere 😉.

[notDavid]

@MichaIng You are correct indeed, thanks! I had removed the fstab entry but didn't realize it would reappear when opening dietpi-drive_manager. Everything seems to work fine when i remove the fstab entry again.

After cryptsetup luksOpen /dev/sdb1 usb02 and mount /dev/mapper/usb02 /mnt/usb02 :

$ $ df -T | awk '{print $1" "$2" "$7}' | column -t -s " "
Filesystem         Type      Mounted on
/dev/root          ext4      /
devtmpfs           devtmpfs  /dev
tmpfs              tmpfs     /dev/shm
tmpfs              tmpfs     /run
tmpfs              tmpfs     /run/lock
tmpfs              tmpfs     /sys/fs/cgroup
tmpfs              tmpfs     /tmp
tmpfs              tmpfs     /DietPi
tmpfs              tmpfs     /var/log
/dev/mmcblk0p1     vfat      /boot
/dev/sda1          ext4      /mnt/usb
/dev/mapper/usb02  ext4      /mnt/usb02

$ blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="F661-303B" TYPE="vfat" PARTUUID="cb7b86f7-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="8d008fde-f12a-47f7-8519-197ea707d3d4" TYPE="ext4" PARTUUID="cb7b86f7-02"
/dev/sda1: UUID="f341e3d1-2c3c-48e3-997e-4adddd85600b" TYPE="ext4" PARTUUID="8f4ee5b1-7013-4908-9807-9c941d87c2e1"
/dev/sdb1: UUID="018e7437-0373-4374-a473-0d2d821e4061" TYPE="crypto_LUKS" PARTUUID="b641c4df-88f0-473b-90de-2195d093ff1f"
/dev/mapper/usb02: LABEL="USB02" UUID="b889e08c-c083-4f86-a594-514f27898fc3" TYPE="ext4"
/dev/mmcblk0: PTUUID="cb7b86f7" PTTYPE="dos"

$ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda           8:0    0  4.6T  0 disk  
└─sda1        8:1    0  4.6T  0 part  /mnt/usb
sdb           8:16   0  4.6T  0 disk  
└─sdb1        8:17   0  4.6T  0 part  
  └─usb02   254:0    0  4.6T  0 crypt /mnt/usb02
mmcblk0     179:0    0 29.7G  0 disk  
├─mmcblk0p1 179:1    0  256M  0 part  /boot
└─mmcblk0p2 179:2    0 29.5G  0 part  /

[MichaIng]

/dev/sdb1: UUID="018e7437-0373-4374-a473-0d2d821e4061" TYPE="crypto_LUKS" PARTUUID="b641c4df-88f0-473b-90de-2195d093ff1f"
/dev/mapper/usb02: LABEL="USB02" UUID="b889e08c-c083-4f86-a594-514f27898fc3" TYPE="ext4"
...
sdb           8:16   0  4.6T  0 disk  
└─sdb1        8:17   0  4.6T  0 part  
  └─usb02   254:0    0  4.6T  0 crypt /mnt/usb02

Okay, this is nested, makes it somehow complicated to implement into dietpi-drive_manager 🤔:

• /dev/sdb1 is the underlying regular partition, with a special file system type "crypto_LUKS", which can differ as well: https://manpages.debian.org/buster/cryptsetup-bin/cryptsetup.8.en.html#BASIC_COMMANDS I guess it could even be mounted directly, but would be not decrypted then.
  • Implementation would be to check for all those available file system types and exclude them all together from being added to fstab. Instead preserve entries of that type, if somehow added manually by user.
• /dev/mapper/usb02 is the decrypted mapped device, which has a regular file system. Interesting is the block device type crypt which is another change to identify it, besides /dev/mapper/ pattern, which is also used for LVM logical volumes.
  • Implementation would be to check for /dev/mapper/ pattern and crypt device type, and do the same as for known crypt fs types.
• As well, to just show that we "handle" these block device types, we should add them to the dietpi-drive_manager menu but make them inaccessible with a reasonable hint. We could sort them in categories "Mapped devices" and "Encrypted devices". This should handle most related/similar cases.

[notDavid]

Note that what i had done in the example above was: cryptsetup -y -v luksFormat /dev/sdb1 to encrypt the partition.

It's also possible to do cryptsetup -y -v luksFormat /dev/sdb to encrypt the entire drive (without creating any partition first)

In that case you will get (this is in Vmware):

root@DietPi:~# df -T
Filesystem        Type     1K-blocks    Used Available Use% Mounted on
udev              devtmpfs    487484       0    487484   0% /dev
tmpfs             tmpfs        98600    4332     94268   5% /run
/dev/sda1         ext4       8189368 2857160   4896496  37% /
tmpfs             tmpfs       493000       8    492992   1% /dev/shm
tmpfs             tmpfs         5120       0      5120   0% /run/lock
tmpfs             tmpfs       493000       0    493000   0% /sys/fs/cgroup
tmpfs             tmpfs      1048576       4   1048572   1% /tmp
tmpfs             tmpfs        51200    1300     49900   3% /var/log
tmpfs             tmpfs        10240    1396      8844  14% /DietPi
/dev/mapper/usb01 ext4      20494928   45080  19385708   1% /mnt/usb01

root@DietPi:~# blkid
/dev/sda1: UUID="eb4d32e7-0087-4ba8-88ec-5317d39e703a" TYPE="ext4" PARTUUID="8934815e-01"
/dev/sdb: UUID="967ebea5-864c-49e9-a12a-6886a0301a56" TYPE="crypto_LUKS"
/dev/mapper/usb01: UUID="fa251e41-980b-498b-a3ae-c764db22d64b" TYPE="ext4"

root@DietPi:~# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda       8:0    0    8G  0 disk  
└─sda1    8:1    0    8G  0 part  /
sdb       8:16   0   20G  0 disk  
└─usb01 254:0    0   20G  0 crypt /mnt/usb01
sr0      11:0    1 1024M  0 rom   

Note the difference with the nesting in lsblk.

[MichaIng]

@notDavid Jep, this is not an issue, since dietpi-drive_manager handles drives with and without partition table just the same. The identifiers are the same, TYPE="crypto_LUKS" + /dev/mapper/* + * 254:0 0 20G 0 crypt /mnt/*

[JudicialDomicide]

@notDavid - I'm experiencing the same issues and have not a clue how to resolve. Lost SSH access headless. Needed to take apart my case to access the microhdmi port and then I am still non the wiser.

Mysetup is as follows:

Rootfs is on a hardware aes-256 encrypted usb device. (This has been working fine for two weeks) I went to add a SSD

sudo cryptsetup luksFormat --type=luks2 --sector-size=4096 -c xchacha12,aes-adiantum-plain64 -s 256 -h sha512 --use-urandom /dev/sdb

sudo cryptsetup luksOpen /dev/sdb

sudo mkfs.ext4 -L ssd_data /dev/mapper/ssd_data

sudo mount /dev/mapper/ssd_data /mnt

I did not appear to have any issues whilst dealing manually with decrypting until i did the following:

Setting up a keyfile to be used for LUKS on the hardware encrypted rootfs USB device

sudo dd if=/dev/urandom of=/root/keyfile bs=1024 count=4

sudo chmod 0400 /root/keyfile

sudo cryptsetup luksAddKey /dev/sdb /root/keyfile

cryptsetup open /dev/sdb ssd_data -d /root/keyfile sudo mount /dev/mapper/sdb /mnt

This works manually but the minute i add:

cryptsetup open /dev/sdb ssd_data -d /root/keyfile sudo mount /dev/mapper/sdb /mnt

to /etc/rc.local

I start to have all kinds of timeout and weird issues and its hit and miss if I can get in on SSH unless being directly on the device.

Also I notice that there is no option in DietPi Drive Manager to transfer dietpi_userdata to the /dev/mapper/sdb mounted volume that dietpi drive manager sees.

[MichaIng]

Also I notice that there is no option in DietPi Drive Manager to transfer dietpi_userdata to the /dev/mapper/sdb mounted volume that dietpi drive manager sees.

The drive manager detects it as network drive, as the final decrypted file system is not listed in /sys/block/, I guess? In such case the option is not shown. And currently it is best so as well for encrypted drives as we neither have a mechanism to automatically decrypt the file system at boot before launching services, nor is this reasonable, as of discussion above. Furthermore does dietpi-drive_manager currently adds a faulty entry.

I.e. as using encrypted drives is a very use case specific thing, I think we cannot reasonably add full dietpi userdata support for it, but this would need to be done manually then based on which software/services are used and how/when the encrypted drive needs to be accessed. But we should detect and gracefully handle such fstab entries, as mentioned above. I'll not find time for this release anymore but for next release at least a simple workaround should be implemented to not break but preserve manually added device mapper fstab entries when dietpi-drive_manager used started.

[MichaIng]

Supporting request: #4365 I renamed this issue to be more generic. General support for dm-crypt/LUKS filesystem detection and creation is the first step, before we can think about allowing to move userdata or other think there.

[ghost]

Is it possible to have a separate boot partion that handles the login first without affecting the OS? That way it'll all be isolated and un-affect the main DietPi OS development.

Although manually entering a password to decrypt an encrypted drive/partition/fs, etc. is the assumed use (for full security), there are some uses where automatic decryption is required on the device the encryted drive/partion/fs was installed on. The intention is to allow auto-decryption on the installed device, but prevent accessing the content when mounted on another device without the password. Dietpi already has a root/dietpi username password, and for some admins that is enough to secure dietpi OS access, but fails to secure the drive contents from access when physically mounted on another system. For automated/remote systems, reboots cannot be stopped with decryption password requests, but contents should still be locked only to the device - in case someone attempts to access the drive on another device.

[MichaIng]

a separate boot partion that handles the login first

A "login" like on local console or via SSH to a shell is not possible without the root partition. But I guess you mean a mask to enter a password for decryption? That is what theoretically an initramfs could do. But don't ask me for details yet 😉. If the /boot partition (which contains the initramfs as well) is on a separate drive, then it could also allow auto-decryption, e.g. by having the password/key stored somewhere there, while preserving the aspect that stealing the root drive only won't allow access. But still, having a decryption password stored on the boot partition still breaks main security aspects. In theory there is something like TPM or a key stored on a USB stick and such, but making use of it requires someone to digging more into all of this things, how to implement into an initramfs or so.

[rondadon]

I am also trying to encrypt the whole DietpiSystem. But how to put in the Passphrase/Password when booting up without a remote KVM?!

I searched for solutions and I found this Project named "wireguard-initramfs". Here also a short discussion about it on Reddit.

It implements wireguard and dropbear into initramfs. So it would be possible to connect via ssh to the "initramfs" bootup stage and unlock the encrypted Filesystem.

This could be a neat solution to our Problem. So not only dietpi-userdata could be encrypted but the whole DietPi System.

This, properly implemented, would be a killer feature! :)

[MichaIng]

Sounds good indeed. A little downside with WireGuard is that it's not yet 100% supported on all SBCs. Also I'm not sure what WireGuard is actually used for in this context? An SSH server alone should be sufficient. What I'm not yet sure about is how to do proper network setup within the initramfs.

[JudicialDomicide]

I have been using a custom solution for almost full encryption successfully for some time now. My process is this.

1. Flash minimal dietpi on sd card
2. Obtain hardware encrypted usb stick (I use datashur pro usb 3)
3. Use gparted to create a main partition and also two 1MB partitions which will be used as keys at end of hardware USB key.
4. Create a dev/urandom dump to one of the 1MB partitions and then DD that over to the other resilient 1MB on same volume.
5. Now make an entire dd of the hardware encrypted usb stick to another usb stick.
6. Using dd carefully clone the data volume of sd card onto the prepared hardware usb stick.
7. Edit fstab carefully to ensure uuid for the /boot remain on sd card only. The other partition on the sd card can be successfully formatted.
8. Boot dietpi sd card for first time it will boot and then have a flashing blinking cursor
9. Insert hardware usb pen it will boot dietpi for first time and then expand he volume and fill to the rest of the free space before your two 1MB keys at end of volume.
10. Then I use only one of them 1MB keys to automatically mount a Luke encrypted 4TB ssd using rc.local using Luks Adientum which is natively supported on debian / dietpi

I hope this helps someone. Probably not the best way to do it but it works for my use case and has for about a year now.

Sent from ProtonMail for iOS

On Sun, Jul 25, 2021 at 11:33, rondadon @.***> wrote:

I am also trying to encrypt the whole DietpiSystem. But how to put in the Passphrase/Password when booting up without a remote KVM?!

I searched for solutions and I found this Project named "wireguard-initramfs".

It implements wireguard and dropbear into initramfs. So it would be possible to connect via ssh to the "initramfs" bootup stage and unlock the encrypted Filesystem.

This could be a neat solution to our Problem. So not only dietpi-userdata could be encrypted but the whole DietPi System.

This, properly implemented, would be a killer feature! :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[JudicialDomicide]

Actually there is a mistake in the below steps.

I actually DD the microsd before first install to the hardware encrypted usb. Then using gparted I remove the boot partition on the hardware encrypted stick. Then I create two new 1MB partitions and move them to end of volume. Then I apply and save changes You should have then one partition at start some unallocated space in middle and two 1MB partitions at end.

This setup also has the additional advantage that should I need to I can remotely ssh into the box and issue a restart or shutdown and knowing that the device located at different location now can not be accessed at all without someone first unlocking the hardware encrypted usb.

Really hope it helps.

JD

On Sun, Jul 25, 2021 at 11:49, Judicial Domicide @.***> wrote:

I have been using a custom solution for almost full encryption successfully for some time now. My process is this.

1. Flash minimal dietpi on sd card
2. Obtain hardware encrypted usb stick (I use datashur pro usb 3)
3. Use gparted to create a main partition and also two 1MB partitions which will be used as keys at end of hardware USB key.
4. Create a dev/urandom dump to one of the 1MB partitions and then DD that over to the other resilient 1MB on same volume.
5. Now make an entire dd of the hardware encrypted usb stick to another usb stick.
6. Using dd carefully clone the data volume of sd card onto the prepared hardware usb stick.
7. Edit fstab carefully to ensure uuid for the /boot remain on sd card only. The other partition on the sd card can be successfully formatted.
8. Boot dietpi sd card for first time it will boot and then have a flashing blinking cursor
9. Insert hardware usb pen it will boot dietpi for first time and then expand he volume and fill to the rest of the free space before your two 1MB keys at end of volume.
10. Then I use only one of them 1MB keys to automatically mount a Luke encrypted 4TB ssd using rc.local using Luks Adientum which is natively supported on debian / dietpi

I hope this helps someone. Probably not the best way to do it but it works for my use case and has for about a year now.

Sent from ProtonMail for iOS

On Sun, Jul 25, 2021 at 11:33, rondadon @.***> wrote:

I am also trying to encrypt the whole DietpiSystem. But how to put in the Passphrase/Password when booting up without a remote KVM?!

I searched for solutions and I found this Project named "wireguard-initramfs".

It implements wireguard and dropbear into initramfs. So it would be possible to connect via ssh to the "initramfs" bootup stage and unlock the encrypted Filesystem.

This could be a neat solution to our Problem. So not only dietpi-userdata could be encrypted but the whole DietPi System.

This, properly implemented, would be a killer feature! :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[rondadon]

Sounds good indeed. A little downside with WireGuard is that it's not yet 100% supported on all SBCs. Also I'm not sure what WireGuard is actually used for in this context? An SSH server alone should be sufficient. What I'm not yet sure about is how to do proper network setup within the initramfs.

I think it is ment to use with reomte VPS/RS or simliar servers and secure the exposed SSH Port.

There is also a tool/framework called clevis which is a framework for automated decryption policies. So you can setup a policy which needs to be satisfied in order that the system unlocks the encrypted partitions and boots from them.

I have not much time now to dive into it but would maybe be also of use when implementing a solution for encrypting the whole Dietpi System.

@JudicialDomicide Thank you for your explanation. Need to look into it. :)

Have a nice day!

[MichaIng]

I think it is ment to use with reomte VPS/RS or simliar servers and secure the exposed SSH Port.

Well, on the other hand then you have the VPN port open. As long as you secure SSH with forced key authentication (all servers support strong ECDSA key pairs), fail2ban and e.g. listen on a non-standard port instead of 22, that should be pretty rock solid. We're running our servers since years like that, and I'm brave to say, looking at the logs, it's unbreakable 😄. But yes, depending on the sensibility of that VPS, or when there are other non-public network services running, a second protection layer does not hurt 🙂.

There is also a tool/framework called clevis

Nice, thanks for sharing. We're gonna implement some feature by times to clone/install the DietPi system to another one, e.g. to allow installing it on first boot from a USB stick onto an internal drive or eMMC module, or to migrate a system from one drive to another, e.g. a bigger SD card. A little similar to what you can do on RPi and some Odroids currently with the root partition, but including the boot partition (if present) and the bootloader (if present). Given that is done, and has been successfully used and hardened a while, I think it is a good basis to allow further preparation and setup on the target drive, like encryption and partitioning in general.

[xanoni]

I'm not sure I understand the problem ... I currently have full disk encryption on a stable RaspberryPi OS 32-bit installation (using LUKS).

What exactly makes it more difficult to replicate the same setup in DietPi (64-bit)?

Was thinking about adding a DietPi box to my portfolio, but no LUKS would break the deal, unfortunately.

FYI, I followed this guide: https://github.com/keks24/raspberry-pi-luks

[Joulinar]

well this will not work on headless systems I guess, as you need to enter a password during boot. As well manipulating the image seems not really handy as you need to do following

1) 2 separate installations needed 1) install system first 2) extend the partition 3) update kernel and packages 4) copy the entire SD card back into a backup image (which should be big now - 16GB in my case) 5) manipulate the backup image 6) flash the backup image back to SD card 7) boot the system where it is needed to enter password during boot (local or remote)

[xanoni]

well this will not work on headless systems I guess, as you need to enter a password during boot. As well manipulating the image seems not really handy as you need to

I currently do this on headless systems, the idea is that you have small Dropbear SSHD in the initramfs that you can connect to to enter the unlock password.

[Joulinar]

I see. Currently I'm following the guide. But still this is done on a fully configured/updated image with a size of 16GB in my case. If I'm not mistaken, for the remote unlook, you would need to generate ssh keys. Something quite user specific and I'm not sure how this should work with a default image. As this would mean passphrase as well as keys are same for all user.

Which brings me to the point that this is something user would need to do individually. Maybe I'm thinking wrong direction

EDIT Finally got my DietPi (RPi3B+) up and running with crypto_LUKS on rootFS. This include remote unlook via dropbear-initramfs

root@DietPi3:~# lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
NAME          FSTYPE      LABEL  SIZE RO TYPE  MOUNTPOINT PARTUUID                             UUID
mmcblk0                         14.9G  0 disk
├─mmcblk0p1   vfat        boot   256M  0 part  /boot      e8af6eb2-01                          DC3E-E470
└─mmcblk0p2   crypto_LUKS       14.6G  0 part             e8af6eb2-02                          4ce0ef25-3021-4af6-b977-e587314551a1
  └─cryptroot ext4              14.6G  0 crypt /                                               30c06ff6-0965-47af-853f-0d85b580553d
root@DietPi3:~#

[xanoni]

Finally got my DietPi (RPi3B+) up and running with crypto_LUKS on rootFS. This include remote unlook via dropbear-initramfs

Nice. Did you have to divert from the guide anywhere due to DietPi specific things? I'd also give it a try then.

[Joulinar]

nope, basically I followed the whole guide on a 32bit DietPi version. I used as well DietPi for the temp system to be able to work on the backup image. All done on the same RPi3B+ by swapping SD cards 😃

[xanoni]

Nice. Process should be the same for 64-bit, or do you see any differences?

[Joulinar]

it is working nearly same way on 64bit. Smaller adjustments are needed to reflect 64bit architecture.

1. on section Entering chroot, you would need to copy qemu-aarch64-static instead of qemu-arm-static cp "/usr/bin/qemu-aarch64-static" "/mnt/usr/bin/"
2. to start chroot, you need to use qemu-aarch64-static as well chroot "/mnt/" qemu-aarch64-static "/bin/bash"
3. last thing was to adjust the following script /etc/kernel/preinst.d/01-rpi-initramfs-tools -> replace all /usr/bin/ into /bin/, otherwise you will fail to create new initramfs.cpio.gz during kernel installation. Simply the location of tools like sed, mkdir, ln or mv is different

A general hint applicable for both, 32bit as well as 64bit. On section Entering chroot I mounted 1 folder in addition to avoid error messages while entering chroot. But this is DietPi specific and not needed on plain Raspberry OS.

mount --rbind "/run/" "/mnt/run/"
mount --make-rslave "/mnt/run/"

That's how screen looks on reboot. On top you see Dropbear waiting to connect/encrypt RootFS. Once done, system is booting DietPi.

root@DietPi4:~# uname -a
Linux DietPi4 5.10.52-v8+ #1441 SMP PREEMPT Tue Aug 3 18:14:03 BST 2021 aarch64 GNU/Linux
root@DietPi4:~#
root@DietPi4:~# lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
NAME          FSTYPE      LABEL  SIZE RO TYPE  MOUNTPOINT PARTUUID                             UUID
mmcblk0                         14.9G  0 disk
├─mmcblk0p1   vfat        boot   256M  0 part  /boot      8f4dbd00-01                          4ADC-240F
└─mmcblk0p2   crypto_LUKS       14.6G  0 part             8f4dbd00-02                          74789214-a16f-4153-9a9a-0beca3a6d0d9
  └─cryptroot ext4              14.6G  0 crypt /                                               a381e76a-30ca-4b81-8248-da0cb01ed7cd
root@DietPi4:~#

[keks24]

Hello,

the author of raspberry-pi-luks here.

It is nice to see, that my guide is going around. :)

On section Entering chroot I mounted 1 folder in addition to avoid error messages while entering chroot

Noted and adapted. :)

-Keks

[Joulinar]

Hi @keks24

It is a little bit DietPi specific to mount /run as we have some scripts located there. It was not a blocker at the end, just some cosmetic error messages on our login banner.

At the end DietPi is a Raspberry OS (on RPi SBC) with reduced amount of packages, highly optimized and some magic automation scripts on top. Therefore the giude is fitting nearly 100%

[keks24]

I see. I will revert that commit then.

[xanoni]

it is working nearly same way on 64bit. Smaller adjustments are needed to reflect 64bit architecture.

Unfortunately, I spotted this reply a bit too late, but I came to the same conclusions. However, I faced a few extra challenges.

I'm documenting them here: https://github.com/keks24/raspberry-pi-luks/issues/12

[Joulinar]

I did not had any issues. I simply followed the guide as is, just with the very small adjustment I documented above. Of course kernel version is different on live system as on the guide because RPi devs released a new version in meantime. But this is very well explained on the guide how to find the right version.

[xanoni]

I did not had any issues. I simply followed the guide as is, just with the very small adjustment I documented above. Of course kernel version is different on live system as on the guide because RPi devs released a new version in meantime. But this is very well explained on the guide how to find the right version.

Can you explain what you mean and how to fix it? I replaced all the 5.10.17 with 5.10.52 (see my referenced ticket) if that's what you're saying, but that was not enough, unfortunately.

(Note that I'm "bootstrapping", i.e., the "second machine" mentioned in the guide is the Pi itself ... this probably introduces some armhf-specific challenges... also, I'm doing this 100% headless as I don't own an external screen, so I had to diverge from the guide here and there.)

[Joulinar]

I have done it on a headless system complete remote. I used a single RPi and plugged the SD card of the system to be encrypted into a USB>SD card connector. I created the raspberrypi_sd_card_backup.img file as described on the guide. For me there was no need to use any bootstrapping. The system to be encrypted as well as the system I used to run all the step are using the same typ of OS (64bit)

Kernel version on RPi OS 64bit is actually 5.10.52-v8+

[xanoni]

Kernel version on RPi OS 64bit is actually 5.10.52-v8+

Yup. That's what I have. I think I'll figure it out soon, was just too tired to finish it. Will update my ticket then.

EDIT: So to clarify my setup, I have a 32-bit Pi and I'm telling it to turn itself into a 64-bit full-disk-encrypted Pi :)

[Joulinar]

you are trying to convert a 32bit OS installation into a 64bit OS? That's not gonna work

[xanoni]

you are trying to convert a 32bit OS installation into a 64bit OS? That's not gonna work

No. We have a communication challenge.

[xanoni]

Working now, just needed a minor nudge (updated it in the other ticket). Next I'll see if I can replicate it with DietPi.

The biggest problem was really that the 32-bit Pi didn't properly create the aarch64 binfmt and even after that was solved, update-initramfs when run in qemu-aarch64-static failed to gzip the initramfs. So I worked around that by compressing the image with a different tool (LZMA / bzip2).

[MichaIng]

Hmm, to be true I also don't understand the aim of https://github.com/keks24/raspberry-pi-luks/issues/12 😄. I mean "transforming" 32-bit to 64-bit consequently means to replace every 32-bit compiled binary and library into a 64-bit one, so basically re-installing each and every package from the 64-bit repository, which does not make sense.

Or is /mnt/croot the mount point of a regular fresh 64-bit image, you want to apply disk encryption to? But then why do you use a 32-bit host image in the first place, with all the QEMU hassle included, instead of doing that natively from a 64-bit host system?

[xanoni]

Or is /mnt/croot the mount point of a regular fresh 64-bit image, you want to apply disk encryption to? But then why do you use a 32-bit host image in the first place, with all the QEMU hassle included, instead of doing that natively from a 64-bit host system?

Yes exactly. Why? Because I didn't expect there to be any weird issues and because it seemed like the most convenient way to merge some of the files from the old system into the new one while also keeping the services on the old system online. I edited https://github.com/keks24/raspberry-pi-luks/issues/12 to add some context, given it confused more than one smart person.

Of course it was not strictly needed, but I have rarely used qemu in the past and was not aware that it would brick basic software like gzip / pigz.

Different question, now that I have a basic RaspiOS 64-bit install, is there a better way to switch to DietPi than reinstalling from scratch? In simplified language (a disclaimer to preempt communication challenges :P), can I just copy over your "scripts" without a full reinstall?

(I expect the answer to be "No", but in that case you should seriously consider whether it's doable at all to add a migration path ... several people whom I mentioned DietPi to liked the idea, but didn't want to go through the pain of a full reinstall.)

[MichaIng]

Yes exactly.

Then as Joulinar already pointed out: This is not gonna work 😉. You'll end up at best with a mixed system half 32-bit and half 64-bit, running with a 64-bit kernel, but e.g. when installing some libraries from the 64-bit repo, they can't be used with the 32-bit binaries and the other way round, creating lots of issues. Also I think you didn't change the sources list to 64-bit? So basically it will then only be a 64-bit kernel running 32-bit userland. Don't do that, either use a full 64-bit image, encrypted from a 64-bit host, or both 32-bit, everything else will cause only strange errors later on, and more confusion 😉.

Different question, now that I have a basic RaspiOS 64-bit install, is there a better way to switch to DietPi than reinstalling from scratch?

https://dietpi.com/docs/hardware/#make-your-own-distribution TL;DR

bash -c "$(curl -sSfL https://raw.githubusercontent.com/MichaIng/DietPi/master/PREP_SYSTEM_FOR_DIETPI.sh)"

EDIT: Ah, it will purge most packages and hence reset the system mostly, so any installed software/configs won't be present anymore. Currently we have no way to migrate a system while keeping previous things installed. As you can see from the length of the script, it is not simply done by copying over the scripts, but a bunch of setup steps (aside of the cleaning steps) are involved as well. Not sure if there is a reasonable way to allow a migration without the reset/cleanup steps, without risking too much conflicts of the installed/present software/configs with DietPi scripts and install options.

[xanoni]

This is not gonna work 😉.

I think we're still not talking about the same thing, hehe, because it did work. Of course I didn't copy all files from the 32-bit machine, I was very selective in what I copied over. I didn't copy any 32-bit libraries / executables.

Ah, it will purge most packages and hence reset the system mostly, so any installed software/configs won't be present anymore.

Hmm that's probably OK, I've only merged in a small percentage of configuration so far.

[Joulinar]

Running DietPi PREP script will purge the required cryptsetup package/configuration. I guess it would be needed to recheck all steps done inside chroot. Better to install DietPi first, activate encryption afterwards and transfer configuration as last step. Otherwise DietPi PREP could remove software title you may need. Aim of DietPi PREP is to create an empty minimal diet system and not to convert existing installations.