On Mon, Mar 06, 2000 at 07:09:46AM -0500, Laszlo Vecsey wrote:
> I've tried running venus with '-rvmt 3' as was suggested on this list for
> a diskless coda client machine, but it causes venus to die with an error
> I've pasted below. This is with glibc and a Linux 2.2.14 kernel, coda
> 5.3.5.
> 
> I'm actually posting this from a diskless coda client, its working fine to
> a small /ram disk constructed with venus-setup at boot time, and -init to
> venus.
> 
> The next thing I'm working on is chroot'ing into the /coda partition, but
> I've run into a problem. 'mknod' files don't appear on it, and so I'm at a
> loss as to what to do with the devices in /dev. I thought of mounting
> another ram drive as /dev, but in order to do that I need access to a
> /dev/ram device first! Chicken egg problem, again.

Also cfs/repair etc. will stop working as they talk to venus through a
special control file in /coda. Is your cache stored in that ram-disk as
well? Why not avoid the chroot and create some symlinks like:

/usr -> /coda/usr
/home -> /coda/home

Ok, it looks ugly as hell, but /dev can then stay on the initial
ramdisk, or even get fully initialized from a script once /coda is
mounted.

Sadly, we currently have no representation for devices in the clients
and servers. At least the kernel code should already be prepared to
handle them.

> I'd like to eliminate NFS as much as possible.. for the running system.

If you use initrd to pack the initial ramdisk image with the kernel, you
shouldn't need NFS.

Jan