[SOLVED] Encrypted swap with cryptfs gives "invalid argument

[tdb]

Whenever I try to create encrypted swap using cryptfs, it fails with "invalid argument" errors.

I just finished setting up my new server with evms and raid 1 root. I used genkernel to create an evms2 kernel and initramfs. I set aisde two 512m partitions per HD for swap space. Everything boots fine, and the raid root is loaded. But when the init scripts begin to process the encrypted swap in cryptfs, it fails with an "invalid argument" error. I tried using cryptsetup to manually create the encrypted swap, but get the same error. I have tried pulling the two swap partitions out of evms management and telling cryptfs to mount them directly as /dev/hda2 and /dev/hdc2. Didn't work. I tried putting both swap partitions into an evms raid0 and telling cryptfs to mount it as /dev/evms/swap. That didn't work. I have tried every combination of the two, accessing the device/s using /dev/evms/hda2 and /dev/evms/hdc2; /dev/mapper/hda2 and /dev/mapper/hdc2; /dev/mapper/swap, and several other ways. Nothing has worked. I tried changing the order of volume managers in /etc/conf.d/rc, didn't work. I tried adding both hda2 and hdc2 to the sysfs exclude section of evms.conf, that didn't work. I can access the swap space directly using any of the above devices with no problems. But whenever cryptfs tries to get at it, I get the "inalid argument" error. Best I can tell that error means something else has control of that device.

[chrisruwe]

http://www.sdc.org/~leila/usb-dongle/readme.html - does this help?

----

And yes, I know...it comes from the latin "usus fructus" and means the right do use/enjoy/have/etc the "fruits" of some commodity. It is one among four basic rights
usus - right to use
abusus - right to change or even destroy
usus fructus - right to use the "fruits"
usus venditus - right to sell

[tdb]

I looked at that. It looks kind of dated, since the new baselayout uses dm-crypt. That's also what I'm using now. I think it is a fight between evms and dm-crypt over who gets to control the partitions. I've tried telling evms to relinquish control of /dev/hd[a|c}2 in evms.config, but it still won't work. The "invalid option" error I think is indicative of something else grabbing control of the partitions. I think it might have to do with the bd-claim patch issue.

As for the tagline, good eye. Are you in a civilian jurisdiction?

[tdb]

So I tested a new kernel with the bd-claim patch, and that didn't work. I now have no idea what is causing this problem. I wish cryptsetup gave more verbose error messages.

[tdb]

Fixed it. It turns out that switching from cryptsetup-luks to plain old cryptsetup fixed the problem. I don't know what the problem was, but manually adding the encrypted swap and adding it with the cryptfs setup both work now. I will file a bug report.

[edit]
Further research shows that genkernel needs certain luks-specific flags when using cryptsetup-luks. this is discussed on the cryptsetup-luks official wiki. This is something I overlooked when using genkernel.

[edit]
Looks like it is a build error with cryptsetup-luks itself: https://bugs.gentoo.org/show_bug.cgi?id=128925 .

[tdb]

Ok, to close this thread out entirely. I tried pulling the bd-claim patch out of the kernel, and got the error again.

To summarize: there were two problems causing my error message.

First, evms and dm-crypt were fighting over control of /dev/hda2 and /dev/hdc2 . I think evms was grabbing control of all the available partitions at bootup, preventing dm-crypt from accessing them directly. This was solved by adding the bd-claim patch to the kernel. The
patch is kind of hard to come by, so here it is:

Code: Select all

--- diff/fs/block_dev.c 2005-02-28 08:36:45.603361144 -0600
+++ source/fs/block_dev.c       2005-02-28 09:30:13.347709880 -0600
@@ -445,34 +445,12 @@
 
 int bd_claim(struct block_device *bdev, void *holder)
 {
-       int res;
+       int res = -EBUSY;
        spin_lock(&bdev_lock);
-
-       /* first decide result */
-       if (bdev->bd_holder == holder)
-               res = 0;         /* already a holder */
-       else if (bdev->bd_holder != NULL)
-               res = -EBUSY;    /* held by someone else */
-       else if (bdev->bd_contains == bdev)
-               res = 0;         /* is a whole device which isn't held */
-
-       else if (bdev->bd_contains->bd_holder == bd_claim)
-               res = 0;         /* is a partition of a device that is being partitioned */
-       else if (bdev->bd_contains->bd_holder != NULL)
-               res = -EBUSY;    /* is a partition of a held device */
-       else
-               res = 0;         /* is a partition of an un-held device */






-
-       /* now impose change */
-       if (res==0) {
-               /* note that for a whole device bd_holders
-                * will be incremented twice, and bd_holder will
-                * be set to bd_claim before being set to holder
-                */
-               bdev->bd_contains->bd_holders ++;
-               bdev->bd_contains->bd_holder = bd_claim;
-               bdev->bd_holders++;
+       if (!bdev->bd_holder || bdev->bd_holder == holder) {
                bdev->bd_holder = holder;
+               bdev->bd_holders++;
+               res = 0;
        }
        spin_unlock(&bdev_lock);
        return res;
@@ -483,8 +461,6 @@
 void bd_release(struct block_device *bdev)
 {
        spin_lock(&bdev_lock);
-       if (!--bdev->bd_contains->bd_holders)
-               bdev->bd_contains->bd_holder = NULL;
        if (!--bdev->bd_holders)
                bdev->bd_holder = NULL;
        spin_unlock(&bdev_lock);

To apply it, copy and paste the patch to a text file in your /usr/src/linux directory called bd-claim.patch. Then, type:

Code: Select all

patch -p1 < bd-claim.patch

Recompile your kernel.

The second problem was that my version of cryptsetup-luks was not compiling properly. It would give the exact same error that the bd-claim issue was giving. This issue is now resolved. See: https://bugs.gentoo.org/show_bug.cgi?id=128925 .


All works great now.