Richard A Nelson <[EMAIL PROTECTED]> writes: > Package: openafs-modules-source > Version: 1.4.4.dfsg1-7 > Severity: grave > Justification: renders package unusable
> I just built a new x86_64 machine to bridge AFS/NFS/CIFS and after > logging in to an AFS id, I found this: > ls -l /u1/cobdev/cobbuild/ > total 21 > ?--------- ? ? ? ? ? /u1/cobdev/cobbuild/bin.tar > ?--------- ? ? ? ? ? /u1/cobdev/cobbuild/cobol > ?--------- ? ? ? ? ? /u1/cobdev/cobbuild/cobolw3 > ?--------- ? ? ? ? ? /u1/cobdev/cobbuild/cobolw4 > ?--------- ? ? ? ? ? /u1/cobdev/cobbuild/cobolw5 > ?--------- ? ? ? ? ? /u1/cobdev/cobbuild/cobolwp > ?--------- ? ? ? ? ? > /u1/cobdev/cobbuild/nohup.out > ?--------- ? ? ? ? ? /u1/cobdev/cobbuild/private > ?--------- ? ? ? ? ? > /u1/cobdev/cobbuild/scheduled > ?--------- ? ? ? ? ? /u1/cobdev/cobbuild/windows > drwxr-xr-x 2 cobbuild cobdev 2048 2007-09-06 14:34 AIX > I thought it might be a 64bit, or new kernel issue, as 2.6.22.5 on my > x86_32 box worked fine... However, using 2.6.22.5 on the _64 box still > showed the error :( So I compiled 2.6.22.7 on the _32 box and see the > exact same failure ! That output looks like you don't have a token. It's the output I'd expect from listing a directory that's listable but not readable. Do you actually have a token? What is the output from the tokens command and what are the ACLs on that directory? > This likely coincides with the kernel-headers sharing 32bit and 64bit > headers for portions - and I'm guessing is 32bit vs 64bit alignment > and/or size issue. This is unlikely given that AFS has worked fine on x86_64 and x86 for years and nothing changed about this in the latest AFS release. I expect it's something else. The x86_64 kernel is rather different from the x86 kernel. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
