REGRESSION: encrypted btrfs root filesystem fails -- but worked before (for sure at commit 84883ef)

[2mc]

This simple installimage.cfg worked perfectly at commit 84883ef

DRIVE1 /dev/sda

SWRAID 0
SWRAIDLEVEL 0

BOOTLOADER grub
HOSTNAME tester

PART swap swap 4G
PART /boot ext2 1G
PART / btrfs all crypt 

IMAGE /root/.oldroot/nfs/images/archlinux-latest-64-minimal.tar.gz

SSHKEYS_URL /root/.ssh/authorized_keys

CRYPTPASSWORD :somecryptpassword

But it now fails because of a wrongly constructed device mapper paths and the wrong attempt to encrypt all partitions.

The latter relates this issue to the since long reported issue of #51 (comment)

The relevant output of debug.txt reads:

[11:19:00] # Encrypt partitions and create /etc/crypttab
[11:19:05] ! this is no valid block device:  /dev/mapper/luks-dev/dev/mapper/luks-sda1
[11:19:05] content from ls /dev/[hmsv]d*: /dev/sda
/dev/sda1
/dev/sda2
/dev/sda3
[11:19:09] ! this is no valid block device:  /dev/mapper/luks-dev/dev/mapper/luks-sda2
[11:19:09] content from ls /dev/[hmsv]d*: /dev/sda
/dev/sda1
/dev/sda2
/dev/sda3
[11:19:13] ! this is no valid block device:  /dev/mapper/luks-dev/dev/mapper/luks-sda3
[11:19:13] content from ls /dev/[hmsv]d*: /dev/sda
/dev/sda1
/dev/sda2
/dev/sda3

Please fix this show stopper soon.

[2mc]

The logical misconception occurs in hunk @@ -2480,7 +2464,7 @@ encrypt_partitions() of commit 08cc8822c996726f86973497d38cc4c058d50b42 n the file functions.sh:

Reverting the single line:

if [ -n "$(echo "$line" | grep "crypted" | grep -P "LVM|btrfs|no")" ]; then

to

if [ -n "$(echo "$line" | grep "crypted" | grep "LVM")" ]; then

does away with the particular issue reported above.

Yet, it doesn't fix the intended overall logic.