It is embarrassing but I have to admit that I had not gotten the moment of the error right. Sorry for having you look in the wrong direction.
The error will trigger even earlier, and I seem to have found the exact prerequisites for it. I could provoke the error with: mount -t nfs -o rw,nolock 192.168.0.1:/export/hti13 /aufs/private mount -t nfs -o ro,nolock 192.168.0.1:/export/ /aufs/server mount -t aufs -o noxino,dirs=/aufs/private=rw:/aufs/server=ro none /root mount -t nfs -o rw,nolock 192.168.0.1:/usr /root/usr ls /root or ls /aufs/server As a result /root/usr is empty afterwards, it is not necessary to move-mount anything or switch out of initramfs. This will happen with any mountpoint used on the server, thus /home, /sys, /proc would also be lost. It does not happen if I mount anything on a mountpoint only available in /aufs/private (or /aufs/clients in my 3-tier setup). As a kludge I changed /aufs/clients and inserted whiteouts for those directories: /export/clients/usr/.wh..wh..opq /export/clients/home/.wh..wh..opq /export/clients/proc/.wh..wh..opq /export/clients/sys/.wh..wh..opq /export/clients/dev/.wh..wh..opq /export/clients/var/.wh..wh..opq (and the shared data directories as well) With this setup, the error seems to be gone. My aufs-mounts do not like it if the server has anything mounted on a directory which is exported via nfs to be used in a union. The mounted content is hidden on the client anyways, it seems my client mounts get hidden just the same. Pleases accept my apologies for having lead you astray with my former misconceptions, I should have tried harder before bothering the list. Thank you for helping me getting a better understanding of the error. Nevertheless It still seems to be some kind of error at work here, if it is inside aufs source or inside my kernel or aufs-module I do not know. Eibo Thieme PS: Even if you won't need the source code of run-init anymore, here is a link: http://anonscm.debian.org/gitweb/?p=kernel/klibc.git;a=tree;f=usr/kinit/run-init;h=c427c07125514946e08890f760d4941573bfc172;hb=HEAD Am 02.03.2013 08:12, schrieb sf...@users.sourceforge.net: > Eibo Thieme: >> Putting a >> >> /bin/sh >> >> in the first rc script enabled me to test for the error with everything >> disabled, it is there and it it is triggered just the same. > > Ok. > It looks like /etc/fstab is unrelated. And we should focus what the last > line of initramfs executes. > > exec /bin/run-init ${TARGET} /sbin/init > "$@"<${TARGET}/dev/console>${TARGET}/dev/console > > If you can try "strace -f -o ${TARGET}/somewhere/log /bin/run-init ..." > And where can I get the source code of run-init? > > >> I will try to have a closer look at the mechanics of switching over from >> initramfs, maybe I can get it to trigger even there. One other option of >> debugging is the question, why does ls /aufs/server trigger the error >> and ls /aufs/client not. Both directories as mounted in the same way, >> client will be ro+wh in the aufs mount, server ro only, will have a look >> there as well, probably over the weekend. > > Currently I don't know why two "ls"-es affect the problem. Are they > really related? > And, of course, I will never hush you. :-) > > > J. R. Okajima ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
