Follow-up: this does not seem to be exactly the same issue. I've just
tried the test case found in bug #137765 and it does not OOPS. However,
bonnie++ doesn't seem to work correctly. I'm not sure if that's intended
or not so I'll leave the interpretation to you.

Unionfs layout:
[EMAIL PROTECTED]:/unionfs$ mount
10.0.10.1:/opt/ltsp/i386 on /mnt type nfs (rw,addr=10.0.10.1)
tmpfs on /mnt2 type tmpfs (rw)
/home/laga/unionfs on /unionfs type unionfs (rw,dirs=/mnt2/=rw:/mnt=nfsro)

With 10.0.10.1 actually being localhost. Here's bonnie's output:


[EMAIL PROTECTED]:/unionfs/home/laga$ bonnie++
Writing with putc()...Can't putc() - disk full?

However, the disk is not full:

[EMAIL PROTECTED]:/unionfs/home/laga$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             7,5G  5,1G  2,1G  71% /
varrun                197M  216K  197M   1% /var/run
varlock               197M     0  197M   0% /var/lock
udev                  197M   44K  197M   1% /dev
devshm                197M     0  197M   0% /dev/shm
lrm                   197M   34M  163M  18% 
/lib/modules/2.6.22-14-generic/volatile
10.0.10.1:/opt/ltsp/i386
                      7,5G  5,1G  2,1G  71% /mnt
tmpfs                 197M  2,8M  194M   2% /mnt2
/home/laga/unionfs    197M  2,8M  194M   2% /unionfs


I have tried to reproduce the OOPS I posted above with a union layout similar 
to how my diskless clients use unionfs:
/home/laga/unionfs on /unionfs type unionfs (rw,dirs=/mnt2/=rw:/mnt=nfsro)
10.0.10.1:/opt/ltsp/i386/ on /test/nfs type nfs (rw,addr=10.0.10.1)
/opt/ltsp/images/i386.img on /test/squashfs type squashfs (ro,loop=/dev/loop0)
unionfs on /test/union type unionfs (rw,dirs=/test/nfs/=rw:/test/squashfs/=ro)

I've just completed a full run of bonnie on /test/union/ and it hasn't
crashed. Also, sudo find /test/union/ works without a problem. It's
noteworthy that the squashfs contains the same files as the nfs mount
(more or less), maybe it wasn't a smart move to do that :)

To make up for my silliness, I created another union with a different
nfs share on top of the squashfs. This was the same nfs share which
caused the OOPS when booting my diskless client (which now contains
everything written by the client during booting). Immediately when
running find . /test/union/, the kernel OOPSes again. I'm attaching the
log.

I'd like to create a proper test case, but I'm running out of time for
tonight unfortunately. I hope the backtrace will provide enough insight.
If not, let me know and I'll come up with a sane way to reproduce the
problem.




** Attachment added: "unionfs-oops2.log"
   http://launchpadlibrarian.net/11466381/unionfs-oops2.log

-- 
kernel oops during boot on a nfs root diskless system, SRU TEST CASE
https://bugs.launchpad.net/bugs/103044
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to