Hello John,
"Jemiolo, John":
> I built a kernel for SLES 11 using the last (jan09) aufs1 bits.
>
> I looked at the patch you provided to me last year for SLES 10, and applied=
:::
Unfortunately, I don't remember the patch you refered. Did I send it you
personally?
> $ more /proc/mounts
> rootfs / rootfs rw 0 0
> /dev/root.old /initrd ext2 rw,errors=continue 0 0
> none /initrd/proc proc rw 0 0
> /dev/shm / tmpfs rw,size=1778688k 0 0
> none /proc proc rw 0 0
> none /sys sysfs rw 0 0
> none /dev tmpfs rw 0 0
> //10.1.1.1/fsdash /initrd/cdrom cifs
> rw,mand,unc=\\10.1.1.1\fsdash,username=administrator,uid=0,gid=0,file_mode=02767,dir_mode=0777,nocase,rsize=16384,wsize=16384
> 0 0
> /dev/loop0 /initrd/loopfs squashfs ro 0 0
> none /union aufs
> rw,si=f99f146f7cc5ea70,xino=/changes/.aufs.xino,br:/changes=rw:
> /initrd/loopfs=ro 0 0
> $
:::
> $ ln -s /proc/mounts /etc/mtab
:::
Your stack trace shows that /etc is aufs, though /proc/mounts says it is
tmpfs (root). That is weird. Aufs is /union only, isn't it?
And at the top of the stack trace, I see
"ln[1414]: NaT consumption 17179869216 [1]"
What is this?
> #### just observed this anomally FAILURE to df prior to the ln if I perform
> a df I get this?
> $ df
> df: cannot read table of mounted file systems: No such file or directory
> #
Try "strace df", and we will find the systemcall returned ENOENT.
Finally I'd strongly recommend aufs2, since it is much better than aufs1
and your kernel seems to be 2.6.27 (which is supported by aufs2).
J. R. Okajima
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
