Build error: ‘struct bio’ has no member named ‘bi_hw_front_size’

I just retried the build with loop.c-2.6.patched from loop-aes v3.2e. Now, for "modprobe loop" I get "Invalid module format" (dmesg shows "loop: exports duplicate symbol loop_unregister_transfer (owned by kernel)".
I guess this happens as the jaunty kernel has "CONFIG_BLK_DEV_LOOP=y" whereas the loop-aes README clearly states "Before you attempt to build loop.o driver (loop.ko on 2.6 kernels), you *must* configure, compile and install new kernel so that CONFIG_MODULES=y and CONFIG_BLK_DEV_LOOP=n."
Did the build process via module-assistant ever work under Ubuntu?

Yes, module-assistant loop-aes used to work in Intrepid. The change from CONFIG_BLK_DEV_LOOP=m to CONFIG_BLK_DEV_LOOP=y is new in the Jaunty kernel. Not sure why.

https://lists.ubuntu.com/archives/kernel-team/2008-December/003880.html

I've just had the same pair of problems, which I worked around as follows:

* Build a custom kernel with "CONFIG_BLK_DEV_LOOP=m" as the only change (following the instructions at https://help.ubuntu.com/community/Kernel/Compile more or less).

* Install the custom linux-image and linux-headers packages generated above.

* Install the loop-aes-source 3.2f-1 package from Debian testing (squeeze) or unstable (sid)

* Build and install the loop-aes modules using module-assistant as normal.

After a reboot, I now have working loop-aes in Jaunty :-)

I'm not looking forward building a new custom kernel each time there's a security upgrade though...

May someone inform the ubuntu kernel team to re-set "CONFIG_BLK_DEV_LOOP=m" in the kernel-configuration file?
Who is responsible for this mess? I know no sane reason to put loop inside the kernel-image.

i totally agree with peter_22, i'm running with an encrypted root filesystem and is already a problem that i have to re-run m-a to rebuild the loop-aes module every kernel update, and now with CONFIG_BLK_DEV_LOOP=y i will have to recompile the whole kernel, it's not so human... i'm stuck at 8.10 right now, please do something

As of today the problem still exists.
On fresh install of ubuntu 9.04 with network upgrade, 'module-assistant auto-install loop-aes ' fails with the same build error.

linux-headers-2.6.28-11-generic

with CONFIG_BLK_DEV_LOOP=y does not even make sense to compile loop-aes with module assistant: if the loop module is compiled inside the kernel we can't replace it with an external one...
So the description of the loop-aes-source package is just wrong:

http://packages.ubuntu.com/jaunty/loop-aes-source
"This package contains source code of the loop-AES loadable kernel modules for Linux 2.0 - 2.6. It can be used with module-assistant, make-kpkg or stand-alone to build loop-AES module packages. "

because instead we must recompile the whole kernel every upgrade...

also take a look here http://archives.free.net.ph/message/20090524.121638.72482e0d.en.html

Looks like the problem is in the kernel configuration rather than in loop-aes-source. Modifying accordingly now.

ok, i think i see the real problem now, after the post to the mailing list, this bug report and a month of unanswered questions on ircnode i finally had this conversation on #ubuntu-kernel (see attachment).
Their point is that since the loop-aes module is not in the upstream, is not a problem (and jari ruusu, the creator, seems to refuse to put it in upstream because he thinks they are "inepts" :D).
And the reason for the kernel configuration change seems to be a little less boot time.
On #ubuntu-devel i also got this explanation:

Keybuk: because we often have no facility to auto-load the loop module when required
Keybuk: and it's not exactly something you'd ever *not* want loaded
Keybuk: that module doesn't contain a driver
Keybuk: so it's not as if we'll ever need to backport a newer version
Keybuk: or blacklist it for hardware issues
Keybuk: it's just a kernel feature
Keybuk: and it makes little sense to have kernel features *not* =y

All reasonable, but now our (the users) problem is that we can't neither recompile the kernel every update, nor try to persuade some people to do anything, you should just get back to CONFIG_BLK_DEV_LOOP=m and let us replace the module as we like, as in a "modular kernel"... (even if this slows the boot by a millisecond)

According to last comment from notch-1, links and irc log, i must mark this task as won't fix in the meantime (until loop-aes get's upstreamed).

However i'm reopening loop-aes-source in order to look a path to compile this module without a full recompilation.

hmmm, it seems that a pretty similar bug was solved upstream in latest loop-aes-source available in karmic at this time. So if the reporters can test the package

loop-aes-source | 3.2f-1 | karmic/universe | all

and this solves the problem, a backport can be requested.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521348
http://packages.debian.org/changelogs/pool/main/l/loop-aes/loop-aes_3.2f-1/changelog

the compilation test went ok, but as stated previously (i should have read closer) the module won't load because of duplicate symbols.

as per comment #10 and 10 seconds boot goal for karmic that change would need a big sponsor to get done.

I've reopened the Linux task in bug #372781

sorry for the noise

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

I get a different build error in karmic, but it's essentially the same problem. An old version of the module was packaged with the new kernel. The lucid repo has a version that compiles at least. Please upgrade the version of this module to at least 3.2g.

I'd also like to suggest that someone put some sort of note/warning in the module source that indicates to get it to work a kernel re-compile is required.

Hi,

I'm running Lucid with 2.6.32-24-generic kernel.

I have run into the same issue. I can create loop.ko but it does not work:

# modprobe loop
FATAL: Error inserting loop (/lib/modules/2.6.32-24-generic/updates/loop.ko): Invalid module format

Does anybody see the same on Lucid? Is there some other solution other than recompile the kernel?

So far I have used aespipe:
aespipe -d -e aes256 -K keyfile.gpg <data.img >data.plain
to remove the encryption.

I have used aes-loop for 8 years and I was very happy with it. Now it seems I need to use another solution. What are the alternatives?

Thanks
Jirka

hello Jirka,
you are not supposed to make the loop.ko by hand, it is a kernel object and is part of the kernel build.
so please remove the one you created.

Hello Jirka,

I gave up rebuilding the kernel without the loop module and started using dm-crypt.

"cryptsetup -c aes-xts-plain -s 512" is similar featurewise to loop-aes.
--
Ákos

I am sorry to say but is is just one small single instance of many, that is the big let down with
ubuntu, it always has been and always be.

Debian as in debian lenny for example is ROCK SOLID as with all debian release's

Ubuntu is fine for the beginner but SHIT for anything more

alex
ps In this money does not talk, and bullshit certainly walks