Dear Junjiro,
I'm using aufs2-standalone for diverse openSUSE diskless setups, but the
latest release freezes on boot. For some reason related to the diskless
setup, where I use a project called kiwi, it's much easier to use the
standalone version, than intergrating it into the kernel itself, as that
would need a full rpm kernel rebuild for any aufs change.
Hence I'm only prepared to bisect the standalone version, where the
offending commit is:
commit f3965b097efec80b18721e1a8cbb4b366985535e
Sure, no wonder, it's this mondays commit in full... :-(
The reason for trying the current release is an uglier issue with openSUSE
11.2, that is related to aufs and apparmor (again), as it does not happen
with a native install.
As already noted, my diskless openSUSE 11.1 setups have apparmor completely
removed from the kernel (2.6.27), as aufs2 won't apply otherwise. Some
apparmor related adjustments are available for aufs1 only, and an attempt
to forward port them ended in nasty kernel crashes on boot..
The kernel 2.6.31 from 11.2 behaves better in this respect, at least on the
first sight. aufs2 base patch applies fine, and the standalone patch only
needs a minor adjustment to get applied (already exported symbol).
Running 11.2 diskless with the simplest possible aufs setup (one nfs rw,
one nfs ro, xino on tmpfs) mostly works fine, but for mysterious reasons,
apparmor blocks loading the shared libs of some programs.
ziggy:~# rcapparmor start
Mounting securityfs on /sys/kernel/security done
Loading AppArmor profiles done
ziggy:~# ldd /usr/sbin/ntpd
linux-gate.so.1 => (0xffffe000)
libm.so.6 => not found
libcrypto.so.0.9.8 => not found
libcap.so.2 => not found
libc.so.6 => not found
ziggy:~# rcapparmor stop
Unloading AppArmor profiles done
ziggy:~# ldd /usr/sbin/ntpd
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/libm.so.6 (0xb76d3000)
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb7561000)
libcap.so.2 => /lib/libcap.so.2 (0xb755b000)
libc.so.6 => /lib/libc.so.6 (0xb73fb000)
/lib/ld-linux.so.2 (0xb7712000)
libdl.so.2 => /lib/libdl.so.2 (0xb73f5000)
libz.so.1 => /lib/libz.so.1 (0xb73e1000)
Even stranger, all affected processes have their own profile
in /etc/apparmor.d: /bin/ping, /sbin/klogd, and /usr/sbin/ntpd.
It looks like apparmor gets to the underlying pathes (below aufs) somehow,
and consequently blocks access to essential files, as it sees them
relocated (note name= entries below from /var/log/audit/audit.log:
type=APPARMOR_DENIED msg=audit(1272987702.188:11): operation="open" pid=3269
parent=3268 profile="/usr/sbin/ntpd" requested_mask="r::" denied_mask="r::"
fsuid=0 ouid=0 name="/read-only/etc/ld.so.cache"
type=APPARMOR_DENIED msg=audit(1272987702.188:12): operation="open" pid=3269
parent=3268 profile="/usr/sbin/ntpd" requested_mask="r::" denied_mask="r::"
fsuid=0 ouid=0 name="/read-only/lib/libm-2.10.1.so"
The question is, how is apparmor able to reveal the original path, as aufs
is executed earlier in the boot process, and the mounts should be covered
by the aufs / mount, shouldn't they?
rootfs / rootfs rw 0 0
udev /dev tmpfs rw,relatime,mode=755 0 0
server:/work/dlbase/hosts/11.2/ziggy /read-write nfs rw,relatime,vers=3,...
server:/work/dlbase/11.2-vdr-kde3 /read-only nfs ro,relatime,vers=3,...
tmpfs /xino tmpfs rw,relatime 0 0
aufs / aufs rw,relatime,si=340df0c2 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
securityfs /sys/kernel/security securityfs rw,relatime 0 0
Thanks,
Pete
------------------------------------------------------------------------------
