tags 88906 moreinfo thanks Hi Mark,
I'm going through the old Debian bug reports on the OpenAFS package. You filed the below bug report a little over four years ago, against a much older version of the package with a much older kernel: | Installed via task-boxedp-server, single host afs server, client on | same machine; created a user volume, used rsync to shovel a bunch of | files over -- and then noticed I couldn't stat /afs: | $ \ls /afs/ | ls: /afs/: Not a directory | and df still showed | AFS 9000000 0 9000000 0% /afs | | on shutdown, it turned out that K18openafs-client failed to unmount /afs | before the server shutdown, and afterwards the later run of some | script also failed but with "couldn't contact server". | | Nothing obvious appeared in dmesg, the console, or /var/log/openafs/*, | unless the line | Thu Mar 8 11:16:54 2001: Server directory access is not okay | has anything to do with it (not sure if that happenned during the | install or later, but include it for completeness.) | | Rebooted and the problem hasn't recurred; <hartmans> suggested it was | a first-time-install problem that had been seen before. I could | probably test that on this machine (under 2.2.18) at some point if it | would help. There is now a much newer version of OpenAFS in Debian testing (and a newer version, for that matter, in Debian stable), and there have been a multitude of bug fixes since then. Are you still having this problem with current versions of OpenAFS? Please let me know if so; otherwise, my inclination is to close this bug given the vintage of OpenAFS against which it was reported. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
