[OpenAFS-devel] OpenAFS server 1.3.80 on x86_64 work-around

[Ulrich Schwickerath]

For the archives: I finally managed to track down this problem to my ptserver 
executable. As a work-around I  replaced it by the corresponding 32bit 
version and after that managed to fs setacl /afs/mynewcell system:anyuser rl 
(which crashed or got stuck before). Now I can access my new cell, both from 
the new database server itself as well as from a remote client.  I have 
verified this behaviour (and the workaround) on another node, starting from 
scratch again, with the same result. 
Thank's a lot for all who answered!
Ulrich
 
On Friday 01 April 2005 22:47, Ulrich Schwickerath wrote:
> Hi,
> I'm trying to setup a new AFS server using openafs 1.3.80 on a dual Opteron
> node running Scientific Linux 3.03/3.04 (recompiled RedHat REL). The kernel
> version is
> 2.4.21-27.0.2.EL.XFSsmp
> (including a patch for the XFS file system). I'm already running another
> Server (in a different cell) which runs on a dual Xeon box with Redhat
> Linux, and which works just fine.
> What happens is the following:
> 1/ running the client only on the Opteron system, I can connect to my
> already existing cell without problems (setting CellServDB and ThisCell
> appropriatly) 2/ I can start all server processes on the Opteron for the
> new cell. Everything looks normal: bos tells that all processes are running
> (and they are). Authentication works fine, I created an admin account for
> which I can get a valid  token with which I can run bos in authenticated
> mode, just as it should be.
> 3/ if I update /usr/vice/etc/CellServDB and ThisCell for my new Cell on the
> opteron system, and try to start the client, it tells me that all daemons
> have been started, and gets stuck immediately afterwards. The module gets
> loaded, but the forked afsd processes go into state Zombie and block,
> cannot be killed any more, and if I try to remove the module, the machine
> panics. The effect is the same if I run the client on a different machine
> than the server, so I assume the problem must be somewhere at the server
> site.
>
> I checked the lists but did not see a report of something like that
> recently. Did anybody succeed to run a (developement) server on x86_64 ?
> Any idea what is wrong ?
>
> Thank's a lot in advance,
> Ulrich

-- 
__________________________________________
Dr. Ulrich Schwickerath
Forschungszentrum Karlsruhe
GRID-Computing and e-Science
Institut for Scientific Computing (IWR)
P.O. Box 36 40
76021 Karlsruhe, Germany

Tel: +49(7247)82-8607
Fax: +49(7247)82-4972 

e-mail: ulrich.schwickerath@iwr.fzk.de
PGP DH/DSS Key: ID 0xCEB9826F
Fingerprint: 5537 8473 CD26 507E 8EE2  BAAF 98E2 FD16 CEB9 826F
__________________________________________