(Illustration by Gaich Muramatsu)
.. Date: Mon, 29 Jun 1998 00:58:22 -0400 (EDT) From: Elliot Lee <sopwith_at_cuc.edu> .. To: linux-coda_at_TELEMANN.coda.cs.cmu.edu cc: sanm_at_corelcomputer.com Subject: Re: Coda Network Computer In-Reply-To: <199806290152.VAA06841_at_chef.redhat.com> .. On Sun, 28 Jun 1998 djb_at_redhat.com wrote: > > 4) The next step is tackle booting. The target here is to have a > > system that can get to the point of starting to run > > /coda/linuxroot/sbin/init as process ID 1. Achieving this will be > > a major milestone, even if the init process immediately gets > > confused! > > Maybe I'm missing something, but doesn't the Linux initrd facility > handle this? Couldn't you put your startup stuff in an initrd image > and create your startup script as /linuxrc in the initrd? I thought > that this kind of thing was the point of the initrd, but I've never > played with it enough to see if it can do what you need above... Is there a size limit on how much can be put into initrd image? venus is fairly big (6 megs unstripped here, probably at least a meg stripped, and that's dynamically linked to libstdc++ and all), and unless you use the "do BOOTP in the kernel" feature of 2.1.x, you'd need all the networking tools too. For a completely diskless client, perhaps going the route of mounting root via NFS, and then using that to bootstrap things up into action. The only problem is, I don't know if coda will work on a diskless client with no place to put /usr/coda/venus.cache on :) .. Elliot, Peter, Michael, (the mysterious) sanm_at_corelcomputer.com and Fellow Codaphiles, We are constructing a multicomputer which will use the Linux<->Coda kernel interface as its (network) filesystem interface. Many of the good features of Coda, mainly those features which are needed to support disconnected operation and robust internal authentication, will not be required by our system area network. For this reason we are using neither venus not vice but are rewriting our own cache manager and file server. Nevertheless, the Linux<->Coda kernel interface is (almost) exactly what we need so we are keen to see it thrive. Though progress was slow at first -- we stumbled about for a while before we found Coda -- on Friday evening last we booted our first Coda-root-filesystem-based computer using a similar approach to that described in Michael and Peter's mail to the list of earlier today. However, rather than use the /dev loopback mount method we have patched the Linux kernel Coda fs code to support fifos, char- and block-special devices. The first of these patches has been incorporated into the current Coda source, the second Peter says will be included later this week. We load an initrd from the network (via the EtherBoot 4.0 package, currently on a diskette but often stored on a boot ROM). It (re)initialises the network interface, runs mkfs on the local cache filesystem partition, sets up a swap partition, starts the local (Venus-like) cache manager (which immediately connects to a remote file server), mounts the Coda(-like) filesystem on a subdirectory of the initrd and then chdir()s and chroot()s into it, exec()ing /sbin/init as it goes. (RAM disks have a default maximum size of 4MB but this can be increased via an explicit parameter.) The remote filesystem is pretty much a standard Linux root filesystem (actually a Slackware distribution). For now our file server supports just one client and the system is fragile and not particularly fast, but we have passed an interesting milestone. In view of the recent mail on this list, now is probably as good a time as any to put our heads up. Cheers, Bruce Janson, Basser Department of Email: bruce_at_cs.usyd.edu.au Computer Science, Madsen Building (F09), Phone: +61-2-9351-3423/4 University of Sydney, N.S.W., 2006, AUSTRALIA Fax: +61-2-9351-3838Received on 1998-06-29 02:40:27