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.
I've installed the new release too, and i'm having this problem, i did the very same steps to reproduce this bug.
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.
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.
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)
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.
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.
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
*** Bug 1048298 has been marked as a duplicate of this bug. ***
*** Bug 1045840 has been marked as a duplicate of this bug. ***
I'm having this problem as well in Fedora 20 with kernel 3.12.8-300.fc20.x86_64
Also in Fedora 19: 3.12.8-200.fc19.x86_64
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*.
*********** 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.
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.
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.
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 ++++++++++++++++++++++++++++++++++++++++++++++++
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.
(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
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 :(
*********** 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.
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.
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 :)