> The idea is that one could have a machine that had an ext2 root
> filesystem that contained just enough to start up networking, start
> venus, and then chroot into /coda.  To be precise, all of this should
> be done within a shell script running as init (pid 1); the last step
> would be for this shell script to do
>     exec chroot /coda/linuxroot /sbin/init

needs a modification to init, but should work.
init want's to be pid 0 or something. i will have to look at the code.
i'm running already something like this, but for some init problems, i'm now
starting a shell scripts (which starts xdm), and this is fine for now.

does "mount /dev/hda2 /coda/var" work ? i still every machine still needs it
own directories for : 
 - /tmp and /var/tmp (on my machines the same dir, /tmp is symlink)
 - /var/run		(xxx.pid files)
 - /var/lock		(xxx.pid files)
 - /var/spool		(maybe for speed ?=
 - /dev			(i'm useing a ramdisk for this)

> Ultimately, of course, the idea would be that we could clone root
> directories within /coda, so that the process of setting up a new
> machine would consist simply of loading this small venus-supporting
> root filesystem, rebooting, and letting a hoard walk pull system
> binaries into cache.

should be possible. will try.
why is a hoard necessary (except for speed) ?

>    Our approach was to use a loopback block device with an ext2
>    filesystem image.  To create the image, we did this in a shell that
>    is not chrooted:
> 
>        dd if=/dev/zero of=/tmp/img bs=4k count=1000
4 mb ? i'm useing a minix filesystem with very many inodes : 
153600 bytes for dev.fs : 547 files.

>        losetup /dev/loop0 /tmp/img
>        mke2fs -i 1024 /dev/loop0
>        mount /dev/loop0 /mnt/loop
>        cd /dev
>        find . | cpio -p -m -d --verbose /mnt/loop
maybe better use MAKEDEV to generate the files, so permissions are correct
(e.g. tty file permissions are changed during runtime).

>    What you're aiming for is a shell script that can run as /sbin/init
>    in the "hard disk root" (the one that will become invisible after
>    the real system gets going from /coda/linuxroot with its init).
>    This script will need to get the system going to the point where
>    venus can run, and then starting the init from within
>    /coda/linuxroot.  Essentially, this means:

>    - running   exec chroot /coda/linuxroot/sbin/init
maybe call the script, wait for it to terminate, and shut down everything
after that ?

>    - suid: Coda supports suid files, but this capability hasn't been
>      tested or used for a long time.  Does it work?
> 
>    - named pipes and other non-file filesystem objects: various
>      programs (lpd, syslog, X) use non-file objects that appear in the
>      filesystem, like named pipes, to do IPC.  Coda currently does not
>      support this.

i'n nfsroot machines, you typicaly mount some dirs from a per host thing,
see list above. 
> 
>    - Coda protection model: the Coda protection model is based on acls
>      on directories and tokens for users.  It will require a bit of
>      tinkering to permit root to have the correct access tokens to
>      permit it to do what it will want to do without jeopardizing the
>      security of the installation on the server.
> 
>    - hardlinks crossing directories: Coda does support multiple
>      hardlinks to a file provided all the hardlinks are in a single
>      directory.  It does not support hardlinks that cross
>      directories.  Is this a problem?

only few people use it. but everyone assumes it is working...

>    - locking: probably /var/mail should not be shared across multiple
>      Coda clients right now, because Coda's locking support is at best
>      limitted to locking on one client.

aarrgghh. that's a problem. i hoped to finaly get a common spool for cat
manpages, x fonts, tex fonts, ... but without locking :-(((

> 6) Finally, of course, the real dream is to have many clients share
>    essentially the same root filesystems except, perhaps, for a small
>    number of config files.

the varname stuff in the linux kernel could help here : make "configfile" a
symlink to "configfile.${hostname}", and make sure you have set hostname to
your hostname (the kernel doesn't map this automaticaly :-(()

a bigger ptoblem might be the dirs listed above.
at least with useing nfsroot i had to make them per machine.

and i needed per host : /etc/fstab, /etc/rc*.d (client/server),
/etc/XF86Config (for every machine). hack : grep/cut from a listfile,
call mount directly, with "-n", start the clients with "init=...", and
my X server is a shell script, that also grep/cut reads parameter form a
listfile, generates XF86Config via cpp, and calls the right X server with
"-xf86config /var/log/XF86Config".

> We'd love to hear of any efforts to pursue this program and would be
> very happy to provide feedback.

i still can't work with coda: for coda i need 2.1 kernels, for my backup
program (adsm, an ibm product, sco binary) i  need 2.0 kernels (2.1 doesn't
have ibcs now).

i want to use exactly such a setup asap, because i have two machines that
operate disconected, and i don't want to install/config/... everything
3 times ...

andreas