Bug 1019440 - Can't mount encrypted volumes in F22 Workstation due to lack of loop devices
Can't mount encrypted volumes in F22 Workstation due to lack of loop devices
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
22
All Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 1045840 1048298 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-15 13:33 EDT by Fiorenzo De Santis
Modified: 2015-04-25 17:56 EDT (History)
26 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-12-10 09:58:18 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Fiorenzo De Santis 2013-10-15 13:33:15 EDT
Description of problem:

When I try to mount an encrypted file container of TrueCrypt [ I've tried also RealCrypt from RPM Fusion ] for the first time after a reboot, I get the message "Failed to set up a loop device". Then if I try again the operation succeeds and I can mount as many file containers as I want until the next reboot.

Version-Release number of selected component (if applicable):

Actually I don't know which component is involved. Sorry!

How reproducible:

always, but only at the first attempt during a session

Steps to Reproduce:

1. (install and) run TrueCrypt/RealCrypt
2. try to mount a file container after a reboot

Actual results:

You get "Failed to set up a loop device" the first time but it succeeds later.

Expected results:

You should mount a file container at the first attempt, don't you?

Additional info:

I've tried to load the loop kernel module in advance with the command "modprobe loop" but it doesn't help.

I don't have this issue with Fedora 19.

I'm currently testing Fedora 20 branched x86_64 on my laptop [ ASUS U36SD ].

PS

I disabled the 'requiretty' option in '/etc/sudoers' to let TrueCrypt work but this isn't required by RealCrypt which wants root access.
Comment 1 Darthmagus 2013-12-17 16:45:38 EST
I've installed the new release too, and i'm having this problem, i did the very same steps to reproduce this bug.
Comment 2 Colonel Panic 2013-12-25 22:42:36 EST
This is also a bug on Fedora 19, possibly due to the latest kernel release? It's only happened since I updated yesterday, amongst which was a new kernel update.

Anyway, as stated previously the standard fix "modprobe loop" doesn't work on this error. I DID manage to find what appears to be a temporary fix (until reboot presumably). Running the following command before TrueCrypt gets it working for me (source: http://old.slax.org/forum.php?action=view&parentID=86524):

next_loop=$(($(ls -1 /dev/loop* | sed 's/[^0-9]//g' | LC_ALL=C sort -n | tail -1)+1)) ; mknod -m660 /dev/loop${next_loop} b 7 ${next_loop} ; chown root.disk /dev/loop${next_loop} ; unset next_loop ;

Why this step is necessary now, and not previously, I don't know.
Comment 3 Tom Horsley 2013-12-26 09:38:06 EST
Yep, I'm having this problem in fedora 19 as well since new kernel. The simplest fix seems to be to loop mount an iso image then unmount it. After that, all seems to be well with loop devices. Perhaps that has the same effect as the mknod commands above.
Comment 4 Michele Baldessari 2013-12-26 14:36:11 EST
The change was due to BZ https://bugzilla.redhat.com/show_bug.cgi?id=896160

where the kernel config was changed.
Dup for F19 (https://bugzilla.redhat.com/show_bug.cgi?id=1045840)
Comment 5 Joel C Ewing 2013-12-26 14:50:38 EST
Also picked up this problem with kernel updates in f19 in last week.  

Realcrypt is not the only victim.  Right click from "Files" and selecting "Open with Disk Image Mounter" also fails.  Have to use command mode "mount -o loop -t iso9660 <iso-file-path> <mount-point>" to manually loop mount an iso file, then realcrypt and "Open with Disk Image Mounter" from Files both work again.
Comment 6 Tom Horsley 2013-12-26 15:15:14 EST
To get back the old behavior I did this set of things (don't know for sure they are all necessary, but they do work):

1. Create the file /etc/modules-load.d/loop.conf that just contains the word "loop" on a line by itself. This makes sure systemd arranges for the loop module to be loaded.

2. Create the file /etc/modprobe.d/eightloop.conf that contains the line:

options loop max_loop=8

Despite the name, that makes the min number of loop devices by 8 (which was the default kernel setting before they changed it).

3. Run (as root) "dracut --force" to rebuild the initrd with the new module options included.

4. Reboot and see 8 loop devices pre-created in /dev

Now truecrypt works again.
Comment 7 DaN 2013-12-27 17:46:31 EST
I have explained another solution that works for me in this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=896160

Even with latest kernel for Fedora 19, truecrypt works again: 

Here is just the script for the lazy ones:

loop_device=/dev/loop8

if [ -b $loop_device ]; then
        echo "$loop_device already exists! Exiting!"
        exit
else
        sudo mknod -m660 $loop_device b 7 8
        sudo chown root:disk $loop_device
        sudo chmod 666 $loop_device

        truecrypt <container> <mount_point>
fi
Comment 8 customercare 2014-01-03 11:34:09 EST
*** Bug 1048298 has been marked as a duplicate of this bug. ***
Comment 9 Josh Boyer 2014-01-06 08:48:47 EST
*** Bug 1045840 has been marked as a duplicate of this bug. ***
Comment 10 June 2014-01-24 19:20:34 EST
I'm having this problem as well in Fedora 20 with kernel 3.12.8-300.fc20.x86_64
Comment 11 Juan P. Daza P. 2014-01-26 12:13:01 EST
Also in Fedora 19: 3.12.8-200.fc19.x86_64
Comment 12 Fomalhaut 2014-02-09 09:55:00 EST
I have this problem manifested itself on Fedora 19 and 20 cores with 3.12 Reloaded with kernel 3.11 relieved the problem.
But in Fedora 20 with 3.12 problem solved as follows:
 # setenforce 0
 # setenforce 1
In Fedora 19, helped only method proposed Tom Horsley in "Comment 6."

More: in Fedora 20 with 3.12 to have a lot of /dev/loop*, and in Fedora 19 with 3.12 - no devices /dev/loop*.
Comment 13 Justin M. Forbes 2014-02-24 08:54:07 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.13.4-200.fc20.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 14 Tom Horsley 2014-02-25 21:34:02 EST
Since the config for kernel 3.13.4-200 still says this:

CONFIG_BLK_DEV_LOOP_MIN_COUNT=0

I'm sure this bug still exists in the new kernel.
Comment 15 Fomalhaut 2014-02-25 21:42:13 EST
With the kernel 3.13.4-200 problem persisted. Fedora 20 behavior is the same as I described in Comment 12.
The most incomprehensible to me why disable / enable SELinux helps in this case.
Comment 16 customercare 2014-03-03 09:12:42 EST
problem continues under 3.13.5-200.fc20.i686+PAE 

fixed with: 

++++++++++++++++++++++++++++++++++++++++++++++++
echo "options loop max_loop=8" > /etc/modprobe.d/eightloop.conf
echo "loop" > /etc/modules-load.d/loop.conf

reboot
++++++++++++++++++++++++++++++++++++++++++++++++
Comment 17 brpia23 2014-05-14 20:06:50 EDT
I originally installed Truecrypt 7.1a on Fedora19 kernel 3.9.
Upgrading to Kernel 3.12 got message "Failed to setup Loop device".
Reinstalled to kernel 3.11.6-200.fc19.x86_64 #1 SMP.
Truecrypt works fine. Upgrading to any higher kernel gets "Failed to setup Loop device" for Truecrypt. Same response every time, right through the latest kernel update-- 3.13.9-100.fc19.x86_64.
 I will attempt the fixes outlined above.
Comment 18 Steeve McCauley 2014-05-17 10:30:53 EDT
(In reply to customercare from comment #16)
> problem continues under 3.13.5-200.fc20.i686+PAE 
> 
> fixed with: 
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++
> echo "options loop max_loop=8" > /etc/modprobe.d/eightloop.conf
> echo "loop" > /etc/modules-load.d/loop.conf
> 
> reboot
> ++++++++++++++++++++++++++++++++++++++++++++++++

You can avoid the reboot by reloading (or loading in the first place) the loop kernel module.

# rmmod loop
# modprobe loop
# ls -l /dev/loop*
brw-rw----. 1 root disk  7,   0 May 17 10:28 /dev/loop0
brw-rw----. 1 root disk  7,   1 May 17 10:28 /dev/loop1
brw-rw----. 1 root disk  7,   2 May 17 10:28 /dev/loop2
brw-rw----. 1 root disk  7,   3 May 17 10:28 /dev/loop3
brw-rw----. 1 root disk  7,   4 May 17 10:28 /dev/loop4
brw-rw----. 1 root disk  7,   5 May 17 10:28 /dev/loop5
brw-rw----. 1 root disk  7,   6 May 17 10:28 /dev/loop6
brw-rw----. 1 root disk  7,   7 May 17 10:28 /dev/loop7
Comment 19 Balint Szigeti 2014-06-24 03:30:26 EDT
I've tried it and I noticed after I removed the loop module and start Truecrypt then try to mount an encrypted device it was just created 256 loop devices.

I think, it is a pure truecrypt bug :(
Comment 20 Justin M. Forbes 2014-11-13 10:57:43 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.17.2-200.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.
Comment 21 Justin M. Forbes 2014-12-10 09:58:18 EST
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Comment 22 Nick Coghlan 2015-04-25 17:56:35 EDT
I ended up on this BZ after trying to figure out why I couldn't mount my TrueCrypt encrypted file with either cryptsetup or tcplay, and eventually tracking it down to this:

    $ losetup -f
    losetup: cannot find an unused loop device: No such file or directory

It turns out this is due to the already referenced change in bug 896160, where Fedora ships without any loop devices configured by default.

Kay's opening comment on bug 896160 gave me the hint I needed: the supported way to create a new loop device on demand is to run "sudo losetup -f", rather than running the command as a normal user.

As a result, I've changed the closure reason here to NOTABUG, and filed bug 1215370 for the relevant usability issue in the losetup error reporting. Specifically, the problem I see is that if you need a new loop device, it's implicit in running "sudo losetup -f", but if you run "losetup -f" as a non-root user when no loopback devices are available, there's no hint that you should retry the command with root privileges to create a new one.

I also mention in that issue the fact that much of documentation around mounting encrypted files as volumes is now misleading (or at least incomplete). If you look at the man page for tcplay, "losetup <loop device> <encrypted file>" is step one in mounting an encrypted file, and similarly, cryptsetup needs a loop device to pass in. Neither page mentions how to *create* a loop device if you don't already have one, and neither does the man page for losetup itself.

It also turns out much of the associated online guidance (including the comments in this bug) is about reverting to the old "pre-created loop devices" behaviour, rather than giving the relevant instructions on how to create loop devices on demand. This means I'll also be posting the "sudo losetup -f" answer to a couple of relevant Stack Overflow and Server Fault questions :)

Note You need to log in before you can comment on or make changes to this bug.