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 ffff88002dbf6500, vfile (null), state 1}
>
> It means the size of the object 672 bytes on my test system, and
> mathces
> the value from au_test_loopback_overlap().
>
> Please insert "dmesg | fgrep -w lo" (or something) just before
> mounting
> aufs in your script. I'd like to compare the value from
> au_test_loopback_overlap().
Well I don't see anything like that, greping everywhere I could for lo,
I only find the one on "au_test_loopback_overlap", only proving that the
patch was applied somehow:
aufs 3.10.x-20140120
debugging au_test_loopback_overlap [aufs]
loop: AES key scrubbing enabled
loop: loaded (max 8 devices)
squashfs: version 4.0 (2009/01/31) Phillip Lougher
aufs au_test_loopback_overlap:44:exe[249]: lo 424
aufs au_test_loopback_overlap:49:exe[249]: lo {num 0, f 0x200003, fname
#Q#####/live/image/live/filesystem.squashfs, file (null),
vfile ffff880007662000, state -30720}
------------[ cut here ]------------
kernel BUG at fs/aufs/loop.c:50!
invalid opcode: 0000 [#1] SMP
[...]
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"...
Thanks again for all your help, I hope it's not just some stupid mistake
from my part...
François.
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
