Hi Ben,
> Why not switch to dm-crypt? It can support all encryption modes used by
> loop-aes, so there is no need to convert any existing volumes.
Currently using older "debian live" scripts (from old-stable) that don't
use dm-crypt.
I will switch whenever I update distribution!
Thanks for the
On Tue, 2014-01-28 at 21:00 +0100, François wrote:
> Hi again,
>
> > I'll post more when I confirm, but I'm pretty sure it has something to
> > do with this issue.
> >
> > BTW: Do you know loop-aes? If so, can it be patched to make 3.10.x work?
> > It used to work with aufs in the 3.0.x kernel.
>
Hi,
Fran ois:
> It works! Thanks for aufs and your support, I couldn't have made it
> without your help.
Congratulations!
But keep in mind that
- in the future when you try to loopback-mount something under aufs
(instead of outside aufs), a message will appear and
aufs3-loopback.patch will b
Junjiro,
> I'll then try patching kernel with loop-aes BEFORE compiling aufs...
> Hopefully it will work, I'll report as soon as I confirm that.
It works! Thanks for aufs and your support, I couldn't have made it
without your help.
François.
Junjiro,
> > Ok thanks, that's what I did in the previous step (not applying
> > aufs3-loopback.patch), but it still BUGs.
>
> Your (previous) problem came from the conflicted loop.h, right?
> If you still have the same BUG msg, then it means you didn't solve the
> conflict. Don't you agree?
Ok,
Fran ois:
> Ok thanks, that's what I did in the previous step (not applying
> aufs3-loopback.patch), but it still BUGs.
Your (previous) problem came from the conflicted loop.h, right?
If you still have the same BUG msg, then it means you didn't solve the
conflict. Don't you agree?
> However I c
Hi,
> Two patches modifies a single file.
> When aufs changes fileA and loop-aes changes fileB, there is no
> conflict. Both of aufs and loop-aes change fileC, there is conflict in
> fileC. In our case, fileC is loop.h, which defines "struct loop".
>
> If aufs3-loopback.patch is unnecessary for y
Fran ois:
> Sorry what do you mean by "conflict in loop.h only"?
Two patches modifies a single file.
When aufs changes fileA and loop-aes changes fileB, there is no
conflict. Both of aufs and loop-aes change fileC, there is conflict in
fileC. In our case, fileC is loop.h, which defines "struct lo
Hi,
> As long as the coflict is in loop.h only, it should not happen.
> I'd strongly suggest you to check the combination of the kernel and the
> module. Put your message into two loop.c files by pr_info() and you can
> confirm it by yourself.
Sorry what do you mean by "conflict in loop.h only"?
Hi,
Fran ois:
> It unfortunately didn't work, without applying aufs3-loopback.patch, and
> using loop-aes as-is, I get the exact same kernel BUG.
As long as the coflict is in loop.h only, it should not happen.
I'd strongly suggest you to check the combination of the kernel and the
module. Put yo
Hi Junjiro,
> > > So I'd suggest you to try
> > > - stop applying aufs3-loopback.patch
> > > - use loop-aes as is
It unfortunately didn't work, without applying aufs3-loopback.patch, and
using loop-aes as-is, I get the exact same kernel BUG.
I guess aufs is not compatible with loop-aes anymore.
Hi again,
> > So I'd suggest you to try
> > - stop applying aufs3-loopback.patch
> > - use loop-aes as is
>
> Actually I was already using loop-aes as-is, and I thought this was the
> problem. The patch was only applied to the "original kernel loop.ko",
> which was later overwritten by the unpatc
> > Do you have another patch for loop-aes support? I can try to adapt the
> > current one if you think there is a chance that it might work.
>
> There is one thing I noticed during the discussion.
> For your case, I suppose aufs3-loopback.patch is unnecessary.
>
> So I'd suggest you to try
> - s
Fran ois:
> I confirm it's actually my issue. I use loop-aes v3.7a downloaded there:
>
> http://loop-aes.sourceforge.net/loop-AES/
>
> But "aufs3-loopback.patch" doesn't apply well on the modified loop.c
> from loop-aes.
Ok, now I can sleep well. :-)
> Do you have another patch for loop-aes sup
Hi again,
> I'll post more when I confirm, but I'm pretty sure it has something to
> do with this issue.
>
> BTW: Do you know loop-aes? If so, can it be patched to make 3.10.x work?
> It used to work with aufs in the 3.0.x kernel.
I confirm it's actually my issue. I use loop-aes v3.7a downloaded
Hi,
> If so, there is a high possibility that you are using unpatched kernel
> (but patched aufs module), I am afraid.
You said that since the first email, and you were right since the
beginning.
My debian live setup use an encryption package called loop-aes, which is
the only module I compile "
Hi,
Fran ois:
> Doesn't seem logical looking at the patch... Where might I have gone
> wrong? I tripple-checked that d.patch was applied on both
> "drivers/block/loop.c" AND "fs/aufs/loop.c"...
Do you mean
- by d.patch, drivers/block/loop.c surely contains pr_info()
- but it doesn't print anythi
Hi Junjiro,
> $ dmesg | fgrep -w lo
> loop_init:1929: lo 672
> loop_set_fd:959: lo 672
> loop_set_fd:959: lo 672
> aufs au_test_loopback_overlap:31:mount[4211]: lo 672
> aufs au_test_loopback_overlap:36:mount[4211]: lo {num 0, f 0x5,
> fname /run/shm/sq.img, file 88002dbf6500, vfile (null), st
Fran ois:
> Appart from your patches, I only apply IMQ and NDPI (also attached), but
> I don't think the issue is related.
Agreed.
> > And may I ask you trying one more debug print patch?
>
> Of course, but you didn't attach the patch!
Here it is.
It will print the size of the object from sever
Fran ois:
> Here is the output. There are some non-printable "filled-squarish"
> characters after "fname" that I replace by "#":
:::
> aufs au_test_loopback_overlap:48:exe[289]: lo {num 0, f 0x23, fname
> ##/live/image/live/filesystem.squashfs, file (null), vfile
> 88
Hi Junjiro,
> Then I want to know the status of "struct loop_device" object.
> Would you apply this patch manually? It will print some info just before
> hitting kernel BUG.
Here is the output. There are some non-printable "filled-squarish"
characters after "fname" that I replace by "#":
aufs 3.
Fran ois:
> However, I switched to 3.10.28 that got out on sunday, so we can be
> quite sure the kernel is the right one. I also applied the b.patch to
> check for msg on boot.
Then I want to know the status of "struct loop_device" object.
Would you apply this patch manually? It will print some i
Hello,
On Sun, 2014-01-26 at 04:31 +0900, sf...@users.sourceforge.net wrote:
> It must be
> BUG_ON(!l->lo_backing_file);
> Hmm, that is really strange.
> Again I am afraid we should confirm that the versions of your kernel and
> aufs module. Could you check it again?
> For example,
> - conf
Fran ois:
> Tried again to be sure and I had forgotten to actually use the newly
> compiled kernel in my test... Sorry!
>
> The dmesg trace now says:
>
> kernel BUG at fs/aufs/loop.c:44!
It must be
BUG_ON(!l->lo_backing_file);
Hmm, that is really strange.
Again I am afraid we should confi
On Sun, 2014-01-26 at 01:30 +0900, sf...@users.sourceforge.net wrote:
> Are you sure that you loaded the correct aufs module?
Tried again to be sure and I had forgotten to actually use the newly
compiled kernel in my test... Sorry!
The dmesg trace now says:
kernel BUG at fs/aufs/loop.c:44!
The
Fran ois:
> Can I make an exception for aufs (with CPPFLAGS pointing to kernel
> sources for example) or is there really a risk of instability?
Does it mean these steps?
- put aufs_type.h for 3.9 (which for for 3.10.x systems) to ./tmp_inc
- specity CPPFLAGS="... -I ./tmp_inc"
- all other header
Fran ois:
> Finally I could do a test with the patch applied. It seems that I hit
> the same BUG as the output looks the exact same as before.
Thanks for testing.
But it doesn't help.
The log doesn't contain the expected debug message.
Are you sure that you loaded the correct aufs module?
To make
Hello again,
In order to test every possibility, I'm trying to compile a more recent
aufs-utils to be sure (still on debian squeeze, old-stable).
It fails with:
"aufs-util for aufs3.0 and later, but aufs is
2-standalone.tree-32-20100125."
The README mentions that I might have an old version of
Hi,
Finally I could do a test with the patch applied. It seems that I hit
the same BUG as the output looks the exact same as before.
I transcribed the entire dmesg trace just in case I missed something
(attached). Hope it helps!
Thanks,
François.
On Fri, 2014-01-24 at 16:24 +0100, François wrot
On Sat, 2014-01-25 at 00:15 +0900, sf...@users.sourceforge.net wrote:
> > Right. Everytime I try something new, I apply all patches and copy the
> > directories to my kernel sources and recompile the entire kernel, just
> > to be sure.
>
> Hmm...
> Then it might be a brand new problem.
> Would yo
Fran ois:
> Right. Everytime I try something new, I apply all patches and copy the
> directories to my kernel sources and recompile the entire kernel, just
> to be sure.
Hmm...
Then it might be a brand new problem.
Would you apply this patch and try reproducing?
This patch doesn't fix any problem,
Fran ois:
> Basically the two only things where I did not follow the README are:
> - Applying the aufs3-loopback.patch, not mentioned in README
> - Not doing the "fs-aufs" module renaming mentioned in README
Appling aufs3-loopback.patch is good.
But if you don't use a loopback-mounted branch, you
Hi again,
Sorry for the bad formatting in the last msg. I just switched to "plain
text", maybe it will be a bit better.
Basically the two only things where I did not follow the README are:
- Applying the aufs3-loopback.patch, not mentioned in README
- Not doing the "fs-aufs" module renaming ment
Hi,
Linux is a custom vanilla 3.10.27 above a debian live (squeeze based), and
following the README.
From aufs3.10.x branch, I apply the following patches:
aufs3-kbuild.patch
aufs3-base.patch
aufs3-mmap.patch
aufs3-loopback.patch (NOT MENTIONED IN THE README)
aufs3-stand
Hello Francois,
Fran ois:
> Having a small issue with aufs branch 3.10.x on linux 3.10.27. Compiles
> OK but when trying to boot "debian live", I see a kernel BUG when trying
> to mount aufs with a squashfs+tmpfs:
:::
> BUG: unable to handle kernel NULL pointer dereference at
35 matches
Mail list logo
