On Mon, 24 Sep 2007, Russ Allbery wrote:
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?
I thought about tokens initially - but some of the files are corrrect
and readable, some (files and directories) completely unavailable.
Here is a fresh attempt, to a _32 system:
$ tokens
Tokens held by the Cache Manager:
User's (AFS ID 6976) tokens for [EMAIL PROTECTED] [Expires Sep 26 05:19]
--End of list--
$ id
uid=6976(cobbuild) gid=210(cobdev)
groups=100(users),210(cobdev),666(ssh-user)
=== this is kerberos 4... thought they're working on moving the server
from transarc to openafs ===
$ fs la
Access list for . is
Normal rights:
system:anyuser rl
cowboy rla <<<=== that'd be my primary id
cobbuild rlidwka <<<=== the ID logged onto
$ls -la
...
-rw------- 1 cobbuild cobdev 2778 Jun 27 16:47 .bash_history
?--------- ? ? ? ? ? .bashrc-old
-rw------- 1 cobbuild cobdev 22 May 1 19:06 .dbxhist
?--------- ? ? ? ? ? .envfile
-rw-r--r-- 1 cobbuild cobdev 20 Jul 14 2005 .forward
?--------- ? ? ? ? ? .lesshst
-rwxr-xr-x 1 cobbuild cobdev 302 Feb 14 2007 .logout
?--------- ? ? ? ? ? .netrc
?--------- ? ? ? ? ? .plan
...
If I reboot back to the 2.6.22.5 kernel/afs modules, things work just
fine:
$ls -la
...
-rw------- 1 cobbuild cobdev 2778 2007-06-27 16:47 .bash_history
-rw-r--r-- 1 cobbuild cobdev 3165 2007-02-20 23:04 .bashrc-old
-rw------- 1 cobbuild cobdev 22 2007-05-01 19:06 .dbxhist
-rwxr-xr-- 1 cobbuild cobdev 2103 2007-02-05 17:49 .envfile
-rw-r--r-- 1 cobbuild cobdev 20 2005-07-14 10:42 .forward
-rw------- 1 cobbuild cobdev 77 2007-06-26 23:00 .lesshst
-rwxr-xr-x 1 cobbuild cobdev 302 2007-02-14 17:14 .logout
lrwxr-xr-x 1 cobbuild cobdev 14 2007-07-10 13:21 .netrc ->
private/.netrc
-rwxrwxrwx 1 cobbuild cobdev 1470 2007-09-24 00:40 .plan
...
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.
Yes, I run both - and haven't had any problems for years - until now...
and istr issues on the lists/irc relating to problems due to using _64
headers on _32 systems... I hadn't actually rebuilt a kernel/module in
a while... since 2.6.22.5, so I'm not sure when it exactly started.
Anyway, this is fairly new, and totally repeatable, here, on
_32 and _64 systems:
2.6.22.5 >= kernel <= 2.6.22.7, libc6 2.6.1-5, gcc 4.2.1-5
--
Rick Nelson
I did this 'cause Linux gives me a woody. It doesn't generate revenue.
(Dave '-ddt->` Taylor, announcing DOOM for Linux)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
