[OpenAFS] Kernel crashing running client on Red Hat 9

[Sean Atkinson]

Hi,

I'm having a few problems trying OpenAFS on Red Hat 9, and wondered if
anybody could offer any advice please?

Because the openafs-kernel-1.2.10-rh9.0.1 RPM doesn't include modules
for the latest kernel update (2.4.20-20.9) I've tried but failed to
build an appropriate module (as discussed in a previous post).  However
I've noticed that libafs-2.4.20-19.9-athlon.o is used instead, although
warnings are issued as the module is loaded.  To try and play safe, I'm
running previous kernel releases (8 and 19.9) to support the pre-built
modules.

Having experienced complications following the quick start guide on
openafs.org to setup a server, I began investigating the client using
the default public servers available.  Because several reports of lost
connections to volume and file servers slow startup, I edited
/usr/vice/etc/CellServDB to remove the relevant entries.

After several iterations to complete the list of troublesome servers I
removed the openafs.org cell (reported lost contact with file server
130.237.93.141 = onyx.su.se) and witnessed kernel oops nastiness
requiring a reboot to recover.  I'd seen similar behaviour on my failed
server setup, but assumed it was some server malformed configuration. 
However it turns out that just removing the openafs.org entries crashes
the kernel when only a client is configured, regardless of the server. 
Presumably this is related to leaving openafs.org in ThisCell, but
shouldn't there be a cleaner failure and warning?

Removing 128.2.121.218, listed in CellServDB as virtue.openafs.org,
prevented warnings about the lost volume and file servers.  To prevent
crashing I left 128.2.13.199, listed as new-virtue.openafs.org, and the
afs service starts much faster.  Also I can now list the remaining good
servers with "ls /afs" in under a minute.

Finally, it appears openafs.org DNS entries need updating - "virtue"
resolves to 128.2.13.199, and there's nothing for "new-virtue".

Thanks in advance for any thoughts.

Cheers,

Sean.

-- 
Sean Atkinson <sean@netproject.com>
Netproject