Building the loop module in prevents using loop-aes with the default kernel

Hi,

See also the discussion at loop-aes-source: https://bugs.launchpad.net/bugs/342902

2.6.28-12.43 and 2.6.28-13.44 have been released since this bug has been opened,
so please enable loop as module again!

Akos

i'm marking this bug as dupe from bug #342902. As the irc logs, mailing list shows at this moment the config change proposed is not an option.

however as stated at that bug the latest karmic update for loop-aes-source seems to solve the issue. (in fact i've tested compilation and it went OK with Karmic kernel, waiting for a Jaunty test, and we can ask for a backport)

ohh, well the compilation went ok, but as the normal loop is inside the kernel there's no way that the loop_aes module can be loaded.

digging around a bit, it seems to be a problem with almost all major distributions. Seems that gentoo is the only one that this is possible now.

However, as the bug #322902 comment 10 reflects, i don't believe this change can be made. (remember the 10 seconds promise at UDS)

https://bugs.edge.launchpad.net/ubuntu/+source/loop-aes-source/+bug/342902/comments/10

i'm unlinking the bug, and let at it's previous state. sorry for the noise.

Grepping through kernel configurations of Debian:

linux-image-2.6.26-2-486_2.6.26-15lenny3_i386.deb
  CONFIG_BLK_DEV_LOOP=m

linux-image-2.6.26-2-486_2.6.26-15_i386.deb
  CONFIG_BLK_DEV_LOOP=m

linux-image-2.6.30-1-486_2.6.30-1_i386.deb
  CONFIG_BLK_DEV_LOOP=m

Same for RHEL4 and RHEL5.

The only one that I found, which made the same choice of not building loop
as a module is Fedora 11: kernel-2.6.29.4-167.fc11.i586.rpm
  CONFIG_BLK_DEV_LOOP=y

So I think Gentoo is not the only one making this possible.

This bug hit me especially hard today when I upgraded to 9.04 because I am running a loop-aes encrypted root partition. Right now I am running 9.04 but booting on an old 2.6.27 kernel because I haven't quite got my custom kernel to decrypt my root partition yet.

Would it make any sense for those of us affected to collectively create on a package website that we can add to our sources.list that contains a properly compiled kernel, or maybe even one with loop-aes complied into it? That way we all don't have to build our own kernels. Or would downloading binary linux kernels with encryption from an anonymous group of people on the internet totally defeat the purpose of having security?

I will also be seriously looking into alternative distributions to move to.

Hi Russel,

FYI I keep maintaining a patched build of the kernel for modular loop device at http://ubuntu.cern.ch
and also a binary build of the loop-aes module for each new ABI version. You would have to judge
yourself if you trust the binary. Otherwise please let me know if you are rather interested in the
patches for the source!

Cheers,
     Ákos

Beside of the kernel configuration issue (very unpleasant), there is still the compilation error (the original bug), even in karmic! In order to get loop-aes to work i need to manually download v3.2h from sourceforge...
I understand that you refuse to fix the kernel configuration thing (or even discuss it...), but this leaded to forgot the original problem: the module compilation error, that still persist.
So please upgrade loop-aes-source to 3.2h (right now is 3.2f on karmic and 3.2c on jaunty, both affected by the bug), this way after the kernel recompilation i can at least use the repository version... make one of the steps clean, at least, please :D

sorry, the last comment fits better in https://bugs.launchpad.net/ubuntu/+source/loop-aes-source/+bug/342902, remove it with this one if you can.

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]