Re: Floppy and tftp - was Woody Freeze
On Mon, Apr 09, 2001 at 11:58:02AM +0200, Ola Lundqvist wrote:
> On Mon, Apr 09, 2001 at 03:07:04PM +0530, Ganesan Rajagopal wrote:
> > > I'm working on a project to run debian (servers and clients) diskless.
> >
> > > Im actually sitting with a totally diskless computer running debian
> > > started with PXE, GRUB, Linux-2.4.2 and nfs-root. I intend to make
> > > diskless-server and diskless-client packages to simplify this.
> >
> > > Is there anyone else out there that are interested in this?
> >
> > I am very interested in this. Do you have a web page describing this?
>
> To bad I have not. But I'll share some of my experience here.
>
> There are actually some packages in debian that makes diskless
> booting easier. See netboot and diskless. I have personally not
> used them but all reports about how to do it would be great.
>
> Here is some scetches about how it is set up.
>
>
> Server:
> =======
> dhcpd (with some BOOTP things to load the kernel with right ip).
> tftpd (pointing to /rboot directory)
> grub (located in /rboot so that the client can find it, yes it should
> be in an other directory. :) This is a special grub bin to
> support network booting via PXE.
> chroot images (in /images, a complete client installation).
> nfs-server (exporting /images)
> kernel (located in /images/foo/kernel)
>
I'm not using grub. I load directly the kernels via tftp. Why use a boot manager in a diskless client :-?
Is it required for booting via PXE?
>
> Client: (well the image in /images/foo)
> =======
> kernel (see above)
> devfs (speeds things up)
I have this in mind, but over a 100Mbs Network is difficult to notice any delay in accesing devices
> ramfs (to localize the host, /tmp /var/tmp /var/run etc.)
I do that via nfs. What are the benefits of doing this in ramfs?
> mount (mounts /usr /root /bin /lib etc to support nfs v3)
> mkdirscript (that creates some dirs in /var/log so logging to
> memory works)
>
>
> So what I want to create is a couple of debian pacakges that:
> 1. Sets up the server (almost automaticly) to allow diskless
> clients.
> 2. Creates client images on the server (if you do not want to run
> the same image as the server)
> 3. Depend, recommend or suggest bootp, nfs-server and tftp and
> configure them as far as possible.
> 4. Run a second kernel on the server to make it possible to
> administrate the clients from the server, like apt-get install...
> without problem). This is a later task... :)
> 5. On the client images, configure them to be a diskless client,
> like add some lines to /etc/fstab, use devfs and create dirs
> in /var/log on boot.
>
>
> So this is how the computer boots:
> 1. The boot ROM in the network card is activated and loaded.
> I use a Intel PXE capable card but others may work too.
> 2. The client asks (via dhcp) for an ip address and some
> information about which server to boot from.
> 3. It retrieves the boot-loader (GRUB) via tftp from the server.
> 4. GRUB then loads the kernel (and maybe modules too if needed) as
> you have specified in the special grub-boot script.
> Here you have to give some specific boot options to boot
> over nfs. To let more than one host boot over nfs you also have
> to give some bootp options to the dhcpd server config...
> 5. The kernel (and maybe modules) is loaded and mounts
> server:/images/foo as its root /.
>
> * Normal startup but some special things:
> 6. Devfsd is loaded which makes the computer a bit faster because
> it does not have to ask the nfs-server for the devices all
> the time.
> 7. Some directories are mounted with ramfs.
> /tmp
> /var/tmp
> /var/run
> /var/log
> /var/state
> /var/account
> /var/lock
> 8. Some directories are remounted to enable nfs v3. It seems
> like (my kernel at least) does not support nfs v3 for the
> root.
> /usr
> /lib
> /opt
> /etc
> /root
> /bin
> /sbin
> /home -> to some other place maybe.
The problem i see here is that when you have a lot of clients, you want them all to mount the same /bin /sbin ... etcetera. A solution is to make the client mount some little root with /etc and /sbin directories (and probably others) that are *client specific*.
for example in a path like /var/lib/diskless/192.168.0.1/ wich can be done by passing /var/lib/diskless/%s with dhcp to the kernel. And then remount all correctly. With all the client sharing common direcotories and maybe having others in ramfs ( what if you don't have a lot of ram in the clients? ) or via nfs separately.
> 9. Swapd is started to allow swapping over nfs. But there are
> some problems with this and it probably have to do with
> that the filesystem is not local. I do not know... Anyone
> have experience with this?
>
> Well now the host behaves (almost) as any other debian host.
>
> To update the image I log in to the server and
> chroot to the image root.
>
> ssh foo
> sudo bash
> chroot /images/bar
>
> and then
> apt-get update
> apt-get upgrade
>
> or similar.
I have been thinking about this. And I believe that installing standard debian packages in the clients that way flustrates all that i have explained.
>
> Atually I would like to boot another kernel at the server for
> updating the image but I have not found any good solution. The
> user-space-linux project looks nice but it uses a file as
> the filesystem...
I don't understand very well what you mean. What has to do the kernel image in the server with the one the clients load?
>
> Hope this helps. :)
>
> But now I have a question.
>
> What names should these packages have?
> Should it be task packages?
>
> Regards,
>
> // Ola
>
> --
> --------------------- Ola Lundqvist ---------------------------
> / opal@debian.org Björnkärrsgatan 5 A.11 \
> | opal@lysator.liu.se 584 36 LINKÖPING |
> | +46 (0)13-17 69 83 +46 (0)70-332 1551 |
> | http://www.opal.dhs.org UIN/icq: 4912500 |
> \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
> ---------------------------------------------------------------
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
Pedro Larroy Tovar. PiotR | http://omega.resa.es/personales/piotr/
piotr@omega.resa.es
Reply to: