Self-hosted FOSS cloud step 1.1: A (NAS) server with Debian (and full disk encryption)

This is the step 01 of this article:

Debian install, with full disk encryption

Install from the debian installer

I choose Debian, and while I will not go through the whole install (there are numerous how-to’s accessible), I will narrate my issue linked to “full disk encryption”. In this particular case, I simply used the installer to do all the work for me (when the partitioning tool kicks in, select the “guided – use entire disk and set up encrypted LVM”).

There are some debates on whether “LUKS over LVM” is better than “LVM over LUKS”, I decided to go with the latter, since it facilitate the “decrypting” process (only one passphrase for all your LVM logical volumes).

The results of a “sudo fdisk -l” with only the relevant information :

Device     Boot  Start       End   Sectors  Size Id Type
/dev/sda1  *      2048    499711    497664  243M 83 Linux
/dev/sda2       501758 156301311 155799554 74,3G  5 Extended
/dev/sda5       501760 156301311 155799552 74,3G 83 Linux

Disk /dev/mapper/sda5_crypt: 74,3 GiB, 79767273472 bytes, 155795456 sectors
Disk /dev/mapper/debianas--vg-root: 9,3 GiB, 9999220736 bytes, 19529728 sectors
Disk /dev/mapper/debianas--vg-swap_1: 2,7 GiB, 2839543808 bytes, 5545984 sectors
Disk /dev/mapper/debianas--vg-home: 62,3 GiB, 66924314624 bytes, 130711552 sectors

So in final we have:

  • A device (/dev/sda)
    • An un-encrypted physical boot partition (/dev/sda1)
    • An extended physical partition (/dev/sda2), containing
    • A logical physical partition, encrypted (/dev/sda5)

During the boot process, when the passphrase is given, the LUKS container is decrypted. This is when LVM kicks in. The volume is mounted as a LVM “physical volume” (pv) (/dev/mapper/sda5_crypt). This physical volume contains a volume group (vg) (debianas-vg), and several logical volumes (lv):

  • /dev/mapper/debianas–vg-root
  • /dev/mapper/debianas–vg-swap_1
  • /dev/mapper/debianas–vg-home

What I whish I had known before though is that during the boot process, when you have to type your password, the keyboard layout might not be the same as when you installed your system.

So let’s say you installed your system with a FR azerty layout, you may end up typing your passphrase on a US qwerty layout. Changing this layout requires to add a parameter in /etc/initramfs-tools/initramfs.conf which of course is only accessible once your system has booted…

I had a special symbol in my passphrase, and could not get through the “passphrase” phase even after looking at the required combinaison on a qwerty keyboard…

I could have tried to change the keyboard layout in the initramfs config file, but that required firing up a live CD, chrooting and so on.

In the end I re-installed the system using a different password that I can retrieve on most keyboards without too much of a headache (even if this may lower the security).

Adding other (encrypted) disks

Create a key file

sudo dd if=/dev/urandom of=/etc/keys/sdb1.luks bs=4k count=1

Use cryptsetup to create the encrypted volume

sudo cryptsetup luksFormat /dev/sdb1

It will ask for a passphrase. I would advise to use a “real” passphrase, even if afterwards we’ll be using a key file (so that in the event you loose one of them, you may still access your volumes). Of course, uses a strong one.

Once finished, attribute the key file to the volume:

sudo cryptsetup luksAddKey /dev/sdb1 /etc/keys/sdb1.luks

You can open the volume

udo cryptsetup luksOpen /dev/sdb1 sdb1_crypt


If you want to use LVM with your volume, you can then:

Create the PV

sudo pvcreate /dev/mapper/sdb1_crypt

Create the VG

vgcreate 1Tera01-vg /dev/mapper/sdb1_crypt

Create the LV

sudo lvcreate -l 100%FREE -n data01 /dev/1Tera01-vg

Create a file system

sudo mkfs.ext4 /dev/1Tera01-vg/data01

Create a mounting point

sudo mkdir /mnt/data01

Mount the file system

sudo mount /dev/1Tera01-vg/data01 /mnt/data01


Automatise the mounting process

You can identify the rights disks by UUID with:

~$ sudo blkid
/dev/mapper/sda5_crypt: UUID="CV4mwk-QYWt-UfLq-zMzN-TVYD-uqvH-6Fnglw" TYPE="LVM2_member"
/dev/mapper/debianas--vg-root: UUID="7872de5d-e2f6-4144-a108-3e1269b816fd" TYPE="ext4"
/dev/sda1: UUID="a37efce5-702b-4df7-8238-6f9f7c28c0a1" TYPE="ext2" PARTUUID="7df34db4-01"
/dev/sda5: UUID="68968090-9ee4-475e-874a-5226f5ef3997" TYPE="crypto_LUKS" PARTUUID="7df34db4-05"
/dev/sdb1: UUID="c01be27a-91ed-4b3b-b13a-bd70102a8989" TYPE="crypto_LUKS" PARTUUID="0005bc20-01"
/dev/sdc1: LABEL="WDGreen1To" UUID="67f42084-c46d-49b0-9635-2e7796726531" TYPE="ext4" PARTUUID="0c006e98-e980-4314-baa5-62f3037bb1bc"
/dev/sde1: LABEL="WDBlue500Go" UUID="96324882-452f-4c1e-a361-fef72c9a91e9" TYPE="ext4" PARTUUID="00056907-01"
/dev/sdd1: LABEL="Samsung500Go" UUID="b0d159a0-b862-4b4a-8d4b-68be9f61e9cd" TYPE="ext4" PARTUUID="000b2662-01"
/dev/mapper/debianas--vg-swap_1: UUID="902f2a00-d25e-4e5a-b40b-f0f64ab0d3a8" TYPE="swap"
/dev/mapper/debianas--vg-home: UUID="a8cfd166-a104-460f-ab46-d8c2ef0fcc54" TYPE="ext4"
/dev/mapper/sdb1_crypt: UUID="kU4q5Q-HTGZ-lo6Z-ia5D-15Qd-NfeZ-yL0Ecc" TYPE="LVM2_member"
/dev/mapper/1Tera01--vg-data01: UUID="9f99efbb-b967-4fc1-83a0-7277f8922360" TYPE="ext4"

In /etc/crypttab

sdb1_crypt UUID=c01be27a-91ed-4b3b-b13a-bd70102a8989 /etc/keys/sdb1.luks luks

This tells cryptsetup to create the cryptographic volume sdb1_crypt from the base device /dev/sdb1 (identified by its UUID, see above), using the key file created above (and stored in /etc/keys), and letting it know that it’s dealing with a LUKS volume.

In /etc/fstab

/dev/mapper/1Tera01--vg-data01 /mnt/data01 ext4 defaults


You can then proceed to some “post-intall” settings:

Synology DSM alternative step 01: Server post-install




Leave a Reply

%d bloggers like this: