Mr. Junjiro R. Okajima,
thanks for your immediate answer. Yesterday I followed your
suggestions but some things haven't changed.
1. Kernel messages
[ 99.884200] aufs 2.1-standalone.tree-3.0-rcN-20110711
The reason for the above message is my update from Debian GNU/Linux
testing "Squeeze" to testing "Wheeze" in September 2011. At that
time the Linux kernel with the version 3.0 was introduced. Maybe the
Debian maintainer wanted give us user the new kernel with a run able
AUFS kernel module. In the near future I will update the current
testing "Wheezy". The update will update the kernel and the AUFS
kernel module. The current AUFS module makes no problems. I think,
I am not in hurry.
[ 99.984955] aufs test_add:262:mount[2493]: uid/gid/perm
/tmp/jailcache.ro.usrlocal 0/50/02775, 0/0/0755
[ 100.071844] aufs test_add:262:mount[2499]: uid/gid/perm
/tmp/jailcache.ro.home 1000/1000/0755, 0/0/0755
The reasons for above message are how I created the directories of
the read only branches. Both directories are created form the user
root but the bound directories /usr/local and /home have other user
ids, group ids and partly permissions. The following lines shows
how I build the AUFS union for usrlocalonaufs:
$> sudo mkdir -p /tmp/jailcache.rw.usrlocal \
/tmp/jailcache.ro.usrlocal
$> sudo mount -o bind /usr/local /tmp/jailcache.ro.usrlocal
$> sudo mount -t aufs -o \
br:/tmp/jailcache.rw.usrlocal:/tmp/jailcache.ro.usrlocal \
usrlocalonaufs /tmp/jail/usr/local
The solution is the change of the uid, guid and perm of the
directories /tmp/jailcache.rw.usrlocal and
/tmp/jailcache.ro.usrlocal, if I see it the right way.
As you suggested I installed the never used aufs-util. After the
installation the following kernel message appears again in the kernel
logs. Again, the kernel message appeared during the GNOME Desktop
session log in:
[ 129.434722] aufs au_opts_parse:1039:mount[3397]: unknown option
errors=remount-ro
[ 129.441762] aufs au_opts_parse:1039:mount[3398]: unknown option
commit=0
[ 129.452269] aufs au_opts_parse:1039:mount[3400]: unknown option
commit=0
[ 129.468503] aufs au_opts_parse:1039:mount[3402]: unknown option
commit=0
[ 129.473906] aufs au_opts_parse:1039:mount[3403]: unknown option
commit=0
[ 129.477398] aufs au_opts_parse:1039:mount[3404]: unknown option
commit=0
Now after I had installed the aufs-util, it seems I had passed a
wrong mount option to AUFS. Please, could you take a look on the
above shown mount command. The command is an example how I mounted
the AUFS branches. Maybe you find a wrong mount option in the command
line.
As you have guessed, the next message is disappeared after the aufs-
util installation:
[ 3942.141298] WARNING: at
/build/buildd-linux-2.6_3.0.0-3-amd64-9ClimQ/
linux-2.6-3.0.0/debian/build/source_amd64_none\
/fs/aufs/
plink.c:450 au_plink_put+0x39/0x6b [aufs]()
[ 3942.141531] Hardware name: M720-US3
[ 3942.141588] pseudo-link is not flushed
2. Chroot environment removal and forgotten daemons
Another problem I have is the removal of the on AUFS based chroot
environment. A removal of the chroot environment is only successful
if no process like a daemon has access to one of the under AUFS
mounted file systems. The problem is the user can't know which
daemons or background processes he triggers if he executes a command
in the chroot environment.
Your suggestion was the script aubusy. Sure aubusy is our friend to
detect a busy AUFS branch but I have had some problems with the
script. Maybe I stumbled about an old version of aubusy. The script
I used is from the Debian binary package aufs-tools with the version
number 20110410-1.
Running aubusy from the above mentioned Debian binary package gave
the following output:
$> sudo aubusy /tmp/jail/usr/local /tmp/jailcache.rw.usrlocal
/usr/bin/aubusy: 62: /usr/bin/aubusy: mntopts: parameter not set
19: Invalid argument
xargs: auibusy: exited with status 255; aborting
I was a little bit puzzled but after some time I found the reason for
the abort. It was the regular expression of the sed command in row 52
that lives in aubusy. The following line shows the unchanged line:
52: si=$(echo $mntopts | sed -e 's/^.*,si=\([^,]*\),.*$/\1/')
The comma, point and star in front of the dollar sign are the trouble
maker. After the deletion aubusy runs as expected. The following
line shows the changed line:
52: si=$(echo $mntopts | sed -e 's/^.*,si=\([^,]*\)$/\1/')
I guess that a new Debian binary package of aufs-tools does include a
newer, a adapted version of aubusy.
3. NFS in an on AUFS based chroot environment
Maybe I didn't present the problem I have, not clear enough. With the
script bldchraufs I create a chroot environment of the whole system.
The created chroot environment based on AUFS. In that environment
I start the nfs server daemon and export the directory /srv/nfs. The
following rows shows how I do the above mentioned things. First I
enter the chroot environment after that I run the following commands:
$> sudo invoke.rc nfs-kernel-server start
This starts a local nfs server daemon in chroot environment based on
AUFS. Doing this I get the following message:
Exporting directories for NFS kernel daemon...exportfs:
/etc/exports [1]:
Neither 'subtree_check' or 'no_subtree_check' specified for export
"127.0.0.1:/srv/nfs".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x
exportfs: scandir /etc/exports.d: No such file or directory
exportfs: /srv/nfs does not support NFS export
.
Starting NFS kernel daemon: nfsd mountd.
The following rewritten message from the above message could be a
hint why exportfs can't export the directory /srv/nfs:
exportfs: /srv/nfs does not support NFS export
The directory /srv/nfs lives on the partition /dev/sda12. In the
chroot environment the partition with the directory /srv is bound on
/tmp/jailcache.ro.srv. The directory /tmp/jailcache.ro.srv is the
read only branch of the AUFS union /tmp/jail/srv. Maybe this kind
of a branch can't be handled by exportfs.
The contents of the file /etc/exports looks like this:
/srv/nfs 127.0.0.1(rw,insecure,all_squash,anonuid=1000,anongid=1000)
Do not look at the options behind the local ip address. These were
used by the user space nfsd. I will changed them if I could use the
kernel space nfsd in the chroot environment.
During the run of the command exportfs -a the following message
appears:
$> sudo exportfs -a
exportfs: /etc/exports [1]: Neither 'subtree_check' or
'no_subtree_check'
specified for export "127.0.0.1:/srv/nfs".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x
exportfs: scandir /etc/exports.d: No such file or directory
exporting 127.0.0.1:/srv/nfs
exportfs: /srv/nfs does not support NFS export
In the above case I use nfs exports in an AUFS environment but I do
not export an union or a branch. Is this kind of AUFS usage
supported?
Again, I would be very glad, if you could find some time to answer my
questions. Thanks a lot in advanced.
Regards,
Robert Wotzlaw
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
