From running venus in conjunction with 'codacon', I've been able to  
learn that the problem seems to be lying on the fact that venus is  
trying to contact an host that doesn't exist anymore. This is  
suspicious, because it seems to be a residue from a previous  
installation. However, I've wiped everything I could think of in the  
client and start with a clean slate but still it tries to connect to  
that old address. Where can this be hidden?

Cheers,

P.

On Jan 16, 2007, at 2:25 PM, Paulo Andre wrote:

> Hi,
>
> I've been trying to get a coda server and client to happily talk to  
> each other but unfortunately it's been proving difficult.  
> Everything seems to be installed OK on both machines, and I can  
> 'clog' just fine from the client into the server. But then when I  
> try to read /coda it just hangs for about a minute and bombs out with:
>
> prla_at_citidesk1:/var/lib/coda/cache$ ls /coda
> ls: /coda/193.137.121.129: No such device
>
> With 193.137.121.129 being the coda server. A quick glance at /var/ 
> log/messages on the client tells me that:
>
> Jan 16 14:20:54 alinex-7TX2Oz kernel: coda_read_super: device index: 0
> Jan 16 14:20:54 alinex-7TX2Oz kernel: coda_read_super: rootfid is  
> (00000001.ff000001.
> 00000001.00000001)
> Jan 16 14:20:54 alinex-7TX2Oz kernel: coda_read_super: rootinode is  
> 1049600 dev coda
> Jan 16 14:23:08 alinex-7TX2Oz kernel: coda_upcall: Venus dead on  
> (op,un) (10.10) flag
> s 10
> Jan 16 14:23:08 alinex-7TX2Oz kernel: No pseudo device in upcall  
> comms at e0b8d420
>
> From googling around and digging on this list, I've learnt that  
> this happens because venus dies and the kernel module can no longer  
> talk to it, but I'm clueless as to why exactly it happens.
>
> Am I doing something awfully wrong here? I'll be happy to provide  
> whatever logs and additional info you may want to see.
>
> Thanks in advance,
>
> Paulo