The problem seems to stem from the fact that the Mageia 5 version of cryptmount is not built with support for the LUKS key-manager.

Here's my Mageia 4 box:

[ardonik@dumptruck ~]$ cat /etc/release ; cryptmount -k ; cryptmount --version
Mageia release 4 (Official) for i586
builtin, password, libgcrypt, openssl-compat, luks, raw
cryptmount-4.4.1

Here's my Mageia 5 box:

ardonik@zar:~[18]$ cat /etc/release ; cryptmount -k ; cryptmount --version
Mageia release 5 (Official) for i586
builtin, password, libgcrypt, openssl-compat, raw
cryptmount-5.0

I can't see anything in the cryptmount changelogs indicating why the new version was built this way.

Thanks for the report. Assigning to our maintainer for cryptmount.

Assignee: bugsquad => guillomovitch
Severity: minor => normal

Created attachment 7114 [details]
Add luks support to cryptmount-5.0

CC: (none) => luismago

Well, I think this bug is caused by a build depencency issue.

Looking at the configure script output, it looks like luks support needs both libgcrypt-devel *AND* libcryptsetup-devel installed when building the package.

However, currently there is no "BuildRequires: libcryptsetup-devel" in spec file.

So I installed libcryptsetup-devel (as well as the other BuildRequires dependencies), then rebuild the binary rpm from the source rpm, and now luks support is ok:

$ cryptmount -k
builtin, password, libgcrypt, openssl-compat, luks, raw

I made a test with a luks encrypted file and everything worked as expected.

I just submitted a fixed release in updates_testing for mageia 5.

QA team, here is a suggested advisory:
The cryptmount package shipped in mageia 5 was missing LUKS format support, due to a missing build dependency. cryptmount 5.0-4.1.mga5, available in updates_testing, fixes this issue.

Status: NEW => ASSIGNED
Assignee: guillomovitch => qa-bugs

MGA5-32 on AcerD620 Xfce.
Installed first old cryptmount.
Problem following testprocedure above:
at CLI as root
dd if=/dev/zero of=/tmp/disk.img bs=1MiB count=10
10+0 records read
10+0 records written
10485760 bytes (10 MB) copied, 0,0411205 s, 255 MB/s
[root@mach6 ~]# /sbin/losetup --verbose --find --show /tmp/disk.img
/dev/loop0
[root@mach6 ~]# cryptsetup luksFormat /dev/loop0 # Or whatever was printed previously

WARNING!
========
This will overwrite data op /dev/loop0 .

Are you sure? (Type uppercase yes): Y
[root@mach6 ~]# cryptsetup -v luksOpen /dev/loop0 bug-test
Apparaat /dev/loop0 is not a valid LUKS-device.
Task fails with code 22: Device /dev/loop0 is not a valid LUKS-device.

The wording might not be a 100% correct, since I am running in Dutch, so I had to translate the words

CC: (none) => herman.viaene

Trying M5 x64 real hardware.

Installed PRE-update: cryptmount-5.0-4.mga5
Following the excellent steps described in Description/Comment 0, I fell into the same hole as Herman, Comment 6:

 # dd if=/dev/zero of=/tmp/disk.img bs=1MiB count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0232013 s, 452 MB/s
 # /sbin/losetup --verbose --find --show /tmp/disk.img
/dev/loop0
 # cryptsetup luksFormat /dev/loop0
WARNING!
========
This will overwrite data on /dev/loop0 irrevocably.
Are you sure? (Type uppercase yes): Y
[it says *upper case* Y, but the outcome was the same with 'y'].
 # cryptsetup -v luksOpen /dev/loop0 bug-test
Device /dev/loop0 is not a valid LUKS device.
Command failed with code 22: Device /dev/loop0 is not a valid LUKS device.

What next? Setting feedback marker.

CC: (none) => lewyssmith
Whiteboard: advisory => advisory feedback

When it prompts "Type uppercase yes", try to enter YES, and see if it works. A little bit unintuitive, but it's an oddity of cryptsetup.

Testing M5 x64 real h/w.

(In reply to LuismaGo from comment #8)
> When it prompts "Type uppercase yes", try to enter YES, and see if it works.
> A little bit unintuitive, but it's an oddity of cryptsetup.
Thanks for this pointer. Silly us: do exactly what it says, and Bingo!
Before trying the update, I note here what happens next, because your excellent instructions do miss some things. I repeat all the steps, with their output, for future reference.

PRE-update: cryptmount-5.0-4.mga5
1.
 # dd if=/dev/zero of=/tmp/disk.img bs=1MiB count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0230292 s, 455 MB/s
 # /sbin/losetup --verbose --find --show /tmp/disk.img
/dev/loop0
 # cryptsetup luksFormat /dev/loop0
WARNING!
========
This will overwrite data on /dev/loop0 irrevocably.
Are you sure? (Type uppercase yes): YES
Enter passphrase: 
[This flumoxed me at first: I thought it was wanting a pre-defined passphrase. I then realised that it is asking to *define* one. I used bare <Enter>].
Verify passphrase:
2.
 # cryptsetup -v luksOpen /dev/loop0 bug-test
Enter passphrase for /tmp/disk.img: 
Key slot 0 unlocked.
Command successful.
 # /sbin/mkfs -t ext4 -m 0 -j /dev/mapper/bug-test
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 8192 1k blocks and 2048 inodes
Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done
3.
 # mkdir /tmp/cryptfolder
4.
 # vi /etc/cryptmount/cmtab
[As described in Step 4].
5.
 # cryptmount bug-test
Cannot find key-manager to match target "bug-test"
[The bug! Well done].
6.
 # mount -t ext4 /dev/mapper/bug-test /tmp/cryptfolder -o defaults,user,acl
 # ls /tmp/cryptfolder
lost+found/

Now to try the update with this acquired wisdom.

Whiteboard: advisory feedback => advisory

Testing x64 (continued)

Need advice about how to clear out everything created above. I umount'd [cryptmount -u did not work] and deleted /tmp/cryptfolder/ and /tmp/disk.img; and re-booted to re-start from scratch. (If you re-start within the same session, /dev/loop0 increments).

POST-update: cryptmount-5.0-4.1.mga5
Re-running steps 1-4 was identical to previously.
Step 5 was different, *not* showing the given PoC, but not successful either:
 # cryptmount bug-test
Enter password for target "bug-test": 
device-mapper: create ioctl on bug-test failed: Device or resource busy
device-mapper task failed
Device-mapper target-creation failed for "bug-test"

 # ls -l /tmp
drwxr-xr-x 2 root   root         40 Hyd  27 21:03 cryptfolder/     [empty]
-rw-r--r-- 1 root   root   10485760 Hyd  27 21:02 disk.img

I hope this is the result of something left over from the pre-update test cycle, but need feedback about the outcome and how to circumvent the error. @LuismaGo

(In reply to Lewis Smith from comment #10)

> POST-update: cryptmount-5.0-4.1.mga5
> Re-running steps 1-4 was identical to previously.
> Step 5 was different, *not* showing the given PoC, but not successful either:
>  # cryptmount bug-test
> Enter password for target "bug-test": 
> device-mapper: create ioctl on bug-test failed: Device or resource busy
> device-mapper task failed
> Device-mapper target-creation failed for "bug-test"
> [...]
> I hope this is the result of something left over from the pre-update test
> cycle, but need feedback about the outcome and how to circumvent the error.

I followed the steps above and have been able to reproduce the same error.

Along the process this is what happens:
# /sbin/losetup --verbose --find --show /tmp/disk.img
This associates the disk image to a loopback device

# cryptsetup -v luksOpen /dev/loop0 bug-test
A device named /dev/mapper/bug-test is created.

We can now mount and umount this device as root, using the mount command.

But cryptmount needs to work from scratch. That's to say, no /dev/mapper device created neither loopback device associated to the disk image.

So, once the filesystem is formatted, some cleaning is needed for cryptmount to work. This can be done manually:
1. cryptsetup luksClose bug-test
2. losetup --detach /dev/loop0

Or else let cryptmount itself to do the "hard work":
1. cryptmount --release bug-test

Whichever method is ok, and makes the mounting/umounting possible:
# cryptmount bug-test
Enter password for target "bug-test": 
e2fsck 1.42.12 (29-Aug-2014)
/dev/mapper/bug-test: clean, 11/2048 files, 1330/8192 blocks

# cryptmount -u bug-test
# 

And as an unprivileged user:
$ cryptmount bug-test
Enter password for target "bug-test": 
e2fsck 1.42.12 (29-Aug-2014)
/dev/mapper/bug-test: clean, 11/2048 files, 1330/8192 blocks

$ ls /tmp/cryptfolder
lost+found/

$ cryptmount -u bug-test
$

Created attachment 7176 [details]
Test example using cryptmount-setup

The testing procedure is incorrect. Using cryptmount-setup, the programs
are working properly.

Sorry, ignore comment 12. That wasn't using luks.

With the update. As root ...
[root@x3 ~]# dd if=/dev/zero of=/tmp/disk.img bs=1MiB count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00481259 s, 2.2 GB/s
[root@x3 ~]# cryptsetup luksFormat /tmp/disk.img

WARNING!
========
This will overwrite data on /tmp/disk.img irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase: 
Verify passphrase: 
[root@x3 ~]# cryptsetup -v luksOpen /tmp/disk.img bug-test
Enter passphrase for /tmp/disk.img: 
Key slot 0 unlocked.
Command successful.
[root@x3 ~]# mkfs -t ext4 -m 0 -j /dev/mapper/bug-test
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 8192 1k blocks and 2048 inodes

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done

[root@x3 ~]# cryptsetup luksClose bug-test
[root@x3 ~]# chown dave:dave /tmp/disk.img

As user ...
[dave@x3 ~]$ mkdir /tmp/cryptfolder
[dave@x3 ~]$ cryptmount bug-test
Enter password for target "bug-test": 
e2fsck 1.42.12 (29-Aug-2014)
/dev/mapper/bug-test: clean, 11/2048 files, 1330/8192 blocks

Keywords: (none) => validated_update
Whiteboard: advisory feedback => advisory MGA5-64-OK
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2015-0164.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

I just want to say that you guys are awesome.  Thank you for fixing this.