# gentoo-sources 4.10.10 and crypto loop device

## drbrezner

hi!

i upgraded my kernel to gentoo-sources-4.10.10 from -4.9.5 and now i'm unable to mount my crypto loop device. the command 

```
loop-aes-losetup -e aes-256 /dev/loop0 /dev/md1
```

still works, i.e. leads to the prompt for password and creates the loop-device. but a subsequent mount attempt 

```
mount /dev/loop0 /home
```

fails in hanging and leading to an error message saying sth like the device is not ok.

when i boot with my old gentoo-sources-4.9.5-kernel, everything works just fine. 

i already updated to the latest util-linux and loop-aes-losetup versions but that didn't fix it. 

what's new in kernel-4.10.x concerning loop/crypto/softwareraid what i didn't recognize so far?

any ideas?

thanks a lot in advance!

----------

## drbrezner

Maybe to provide some useful information, here's the output from e2fsck (after i interrupt, first it hangs):

```
root ~ # /sbin/fsck.ext2 -C0 -y /dev/loop0

e2fsck 1.43.3 (04-Sep-2016)

^C[  555.080231] Buffer I/O error on dev loop0, logical block 0, async page read

[  555.080252] Buffer I/O error on dev loop0, logical block 1, async page read

[  555.080264] Buffer I/O error on dev loop0, logical block 2, async page read

[  555.080276] Buffer I/O error on dev loop0, logical block 3, async page read

[  557.232231] Buffer I/O error on dev loop0, logical block 0, async page read

[  557.232236] Buffer I/O error on dev loop0, logical block 1, async page read

[  557.232238] Buffer I/O error on dev loop0, logical block 2, async page read

[  557.232239] Buffer I/O error on dev loop0, logical block 3, async page read

^C/sbin/fsck.ext2: Der Versuch, einen Block vom Dateisystem zu lesen, endete in kurzem Lesen beim Versuch, /dev/loop0 zu öffnen

Könnte es eine Partion der Länge Null sein?
```

which says in german "...that the attempt to read a block from the file system ended in a short reading attempt while trying to open /dev/loop0. could it be a partition of size zero?"

The output of a mount attempt is as follows (again, first hangs, then after interruption):

```

root ~ # mount /dev/loop0 /home

^C[  723.661626] Buffer I/O error on dev loop0, logical block 976758720, async page read

[  723.661900] Buffer I/O error on dev loop0, logical block 976758721, async page read

[  723.662171] Buffer I/O error on dev loop0, logical block 976758722, async page read

[  723.662485] Buffer I/O error on dev loop0, logical block 976758723, async page read
```

What do i need to change so that it also works with the new kernel gentoo-sources-4.10.x? with gentoo-sources-4.9.x and all versions below the commands work just fine.

Thanks again in advance!

----------

## drbrezner

Same problem with gentoo-sources-4.11.* -- does anyone have a clue how to solve this problem?

----------

## loeb-it

The in kernel crypto loop seems really to be broken. I have tried gentoo-sources-4.9.16 and gentoo-sources-4.12.12. I also have not found out (yet) what is causing this issue. 

Well if it is just for accessing your data you can always disable the loopback device support in your kernel configuration. After rebuilding the kernel emerge sys-fs/loop-aes (you might have to add "sys-fs/loop-aes ~amd64" or similar to your package.keywords to do so). Then ensure that the module gets loaded (i.e. adding it to "/etc/modules-load.d/...") and use your cryptoloop images as usual.

----------

## salahx

The crytoloop driver is deprecated (and likely obsolete) anyway. Fortunately, Linux supports mounting existing cryptoloop volume via the device manager. Doing it directly via the device mapper, however, is far too painful. Fortunately we don't have to, the cryptsetup utility will handle it ( its part of sys-fs/cryptsetup )

To mount it:

```

cryptsetup open /dev/md1 --type loopaes home --key-file home-key.gpg

```

In reality, it'll probably give you an error an suggest an alternate syntax

```

gpg --decrypt home-key.gpg | cryptsetup open /dev/md1 --type loopaes home --key-file=-

```

Unfortunately, this will probably fail too, because gpg can't invoke the agent when you're runnning as root and the X seession isn't owned by root.

So, for the win:

```

sudo -v

gpg --decrypt home-key.gpg | sudo cryptsetup open /dev/md1 --type loopaes home --key-file=-

```

This requires the user who owns the X session have access to the keyfile, and access to sudo.

----------

## Hu

Historically, gpg had no problems running from a root shell in a non-root Xorg server.  You might have a problem if non-root environment variables leaked through and confused gpg-agent into thinking it would have GUI access.  The fix for that is to invoke the root shell as a login shell, so that such variables do not leak in.

----------

## drbrezner

The hint to use cryptsetup was the key to the solution. I made a bash script which is called by a systemd service. Since I dont't use a key file but a passphrase I added the prompt for the password:

```

#!/bin/bash

while [[ ! `/bin/mount | /bin/grep "/dev/mapper/home"` ]]; do

        # home not mounted

        # check if mapper exists and close mapper

        while [ -e "/dev/mapper/home" ]; do

                /sbin/cryptsetup close home

        done

        # read passphrase

        read -s -p "Enter passphrase: " passphrase  

        # create mapper

        echo $passphrase | /sbin/cryptsetup open /dev/md1 --type loopaes home --key-file=-

        # cleanup passphrase

        unset passphrase

        # file system check

        /sbin/fsck.ext2 -C0 -y /dev/mapper/home

        # mount

        /bin/mount /dev/mapper/home /home

done

```

Works perfectly on gentoo-sources-4.13.12.

Thanks a lot!

----------

