I have been using about the same setup to boot 16 Redhat machines over the network for six months now. Figuring out how to do this on my own took me a long time, and I wish I had had this forum at that time. My compliments to swiss mage.

Anyway to answer a few questions. PXE is what has the limit, the PXE standard limits the size of disk image that can be downloaded to I think 512k. (Some cards do support 640k however.) So if you are using GRUB, make sure that your GRUB image is less then that. (If you follow the instructions in this forum this will not be a problem.)

After GRUB is booted, you can download a boot image of any size. I liked to use regular floppy boot disks, and just do a dd of the disk to build an image for the tftp server. (Easy to test, and build) Then I used syslinux memdisk to build a RAM disk and copy the boot image into the RAM disk and boot from there. I never had a problem with the size of the image, and did try up to 2.2MB images without any problems, so I am not sure about that.
My grub.lst looked like the following

In getting Linux to work via a NFS server, you need to make sure that you compile the kernel with built in NFS-root support, and also build the network driver into the kernel, and remove all Network settings from other places. (i.e. initializing the network card during startup scripts gave me kernel panics since it was already initialized in the kernel.) I also liked to build a RAM drive into my kernel for my use, but I don't know if this is strictly required.

After that configuring my NFS server hosts.allow, and iptables scripts was all that I needed to do to get it to boot.

As a side note, in answer to a few posts, I have my tftp, dhcp, and nfs server on different machines (And even on different subnets), and it works just fine. It is by no means a requirement to have them all on the same machine. I also tried swaping via NFS, but it was so slow it was not even worth it. (I bet swapping to floppy would be faster, and from reading on the Internet most people have similar experience.) Just buy some more RAM, it's cheap and lots easier to setup too.

I sucess to boot normaly the node client only one time .
And because I didn't plug a keyboard I reset (hardware reset) the client .

And still now I have the following error on boot (node client) :

Code:

* Checking root filesystem
fsck.ext2: Is a directory while trying to open /
/:
the superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contaiins an ext2
filesystem (and not swap or ufs or something else) , then the superblock is
corrupt , and you might try running e2fsck with an allternate superblock :
e2fsck -b 8193 <device>

This is an issue with the /etc/fstab. Add an entry for your NFS root filesystem and it should work

fsck.nfs not found

This is not vital and can be let as is ...

Various errors during system services start

I have no solution for this and I cannot find what gives this errors. But I already have one answer : modprobe complaining about strange missing modules. This is a baselayout problem, don't worry about this.

But I have several others errors and some services are started one or three times ... If someone found a solution for this please post !_________________EPFL
http://www.epfl.ch
Swiss Federal Institute of Technology

I have root over nfs working, I boot the kernel off of a cd. My bios supports net booting.

Has anyone done a net boot in combination with a hardware router. My SMC router currently provides ip addresses via DHCP. I think I may regret it if I try to run two DHCP servers, what do people think?

I have tried many ways to install the base system of my diskless client. But the only one that really succeded is the following :

2.1 Reboot the server on a Gentoo LiveCD

As said I've try many ways to install the base system but I always had problems ...

Try to run bootstrap or to emerge a new version of GCC on a chrooted environment ... It could work for you but not for me !_________________EPFL
http://www.epfl.ch
Swiss Federal Institute of Technology

In case anyone was wondering, somebody has already thought about all of these issues and created an easy to install and configure suite of software known as LTSP. It makes server setup very easy and client setup trivial. I take it there's no ebuild for it at this stage, but since LTSP-4, a complete build environment (known as LBE) for the application has been included that would probably make creating an ebuild quite easy for somebody who is skilled and so inclined. I'm not sure how well it would integrate with Gentoo, but it's fantastic software and really worth checking out if you're interested in thin-client linux systems.

In case anyone was wondering, somebody has already thought about all of these issues and created an easy to install and configure suite of software known as LTSP. It makes server setup very easy and client setup trivial. I take it there's no ebuild for it at this stage, but since LTSP-4, a complete build environment (known as LBE) for the application has been included that would probably make creating an ebuild quite easy for somebody who is skilled and so inclined. I'm not sure how well it would integrate with Gentoo, but it's fantastic software and really worth checking out if you're interested in thin-client linux systems.

Lucas

I've been trying to use LTSP recently but it simply isn't working for me. Also, the goal of LTSP isn't quite the same as what the original howto in this thread was going for:

LTSP is radically slanted towards building X terminals. Essentially, you use LTSP to get the client machine up and running, then run every single program on the server (including X).

This document explains how to get a client up and running such that, once running, it is a normal Linux workstation except that the filesystem is mounted via NFS. This is ideal if your client has the necessary processing speed and RAM to get the job done (as in my case)._________________Get Firefox!

The documentation contains the scripts to configure the diskless
and some config files (fstab, grub.lst, dhcpd.conf, etc.).

If you want a translation, do it yourself: the documentation is under
the GPL license.
You can write me (alban.crequy@laposte.net) if you want more infos.

darookee says:
> is there a way to do this without a bootable network card?

Yes. I use either a PXE card or a bootable CDROM. I use isolinux
to boot from a CDROM as a diskless. Ok, the CDROM contains the linux
kernel and isolinux.cfg (isolinux.cfg is to isolinux as grub.lst is to
grub). I use only 2MB of the CDROM. But all the system is on the NFS
server.

kermitjunior says:
> How does this differ from LTSP? Any advantages or disadvantages?

AFAIK, all programs on LTSP run on the server. With these diskless, all
programs run on the diskless.

ctford0 says:
> Why use tftp and not something like ssh?

Because the program inside the chip of the PXE card want tftp. Why not FTP?
Because FTP is too complex (more than TFTP) for the chip.

GurliGebis says:
> Well, Isn't there a way to be able to have swap on this system?

If you have a hard disk on your diskless, you can. I have tested it
and it works. In my tests, the hard disk was used only to swap.

ctford0 says:
> Ok, say I decide to setup 6 diskless clients. What directories can
> be shared between them all?

Well, I guess it depends of the distrib. I have only tested the mandrake.
Hope it is the same for gentoo.

> /usr
> /bin
> /sbin
> /opt

yes; no problem.

> /etc ?????

no, you can't. Because of:
/etc/fstab: the root mount point is not the same on 2 diskless.
/etc/modules: the modules to be loaded are not the same on 2 diskless.
/etc/cups.conf: this file contains the IP of the diskless...
/etc/sysconfig/network: (only on mandrake but I assume there is another
config file for gentoo) the file contains the static IP of the diskless.
No, it is not possible to use DHCP in this step (because of... hum if
someone want to know, ask me, i'm lazy).
etc.

If you want share /etc/passwd and some other, see below.

> /lib ???

yes, I share it.... but not /lib/dev-state! I don't know if this problem
exists in gentoo but /lib/dev-state can't be shared on mandrake.
So, I share /lib (with a NFS mount point in fstab) and I replace the directory
dev-state to a symbolic link to /dev-state. (symbolic link are resolved
by the diskless, not by the NFS server). So all /lib is shared but not
/lib/dev-state.

> I really dont want to have duplicates of things that I dont need
> to. I know that these I will have to have for each terminal.
>
> /dev

In my tests, I have not shared /dev. I wonder if /dev can be shared if
the diskless use devfs since the devfs mount point hide the files inside
the directory /dev... not tested.

> /tmp

Can't be shared because of some programs which place locks in /tmp.

> /var

Can't be shared because of some programs which place locks in /var.
For example, NFS locks are in /var/lib/nfs in mandrake.

> Any others to add to this list?

On all my diskless, I share /common with a NFS mount point. And
/etc/passwd and some other are in /common.
On the NFS server side, the files passwd of each diskless are shared
with hard links. It's not possible to use symbolic links because of:
1/ symbolic links are resolved by the diskless (hard links are
"resolved" by the NFS server).
2/ The /common mount point is mounted after the system use passwd.
Some init scripts want to read passwd before /etc/fstab is read.

Of course, /home is shared.

Swiss.Mage says:
> If the users, groups, ... are the same on each machine, you could even try sharing /etc and /home ...
> I have to "confess" I have never try to share all of this system dirs ...
> So if you do it, post a message here to provide feedback for the other users (and me too).

In my tests, I don't use NFS: I used normal passwd, group and shadow.
They are shared with hard links on the server and it works !

Swiss.Mage says:
> I think the in.tftpd server must be on the same machine than the
> DHCP server ... but I'm not sure !

If your TFP server is not on the same machine than the DHCP server, the DHCP
server MUST say to the diskless where is the TFTP server. This is done via the
"next-server" option in the file dhcpd.conf. Example:
host eta {
...
next-server 192.168.1.11; # TFTP server's IP
filename "/eta/boot/pxegrub";
}

If the NFS server is on the same machine than the DHCP machine, you can
simplify the file grub.lst:
Put:
"kernel /eta/bzImage ip=dhcp root=/dev/nfs nfsroot=/diskless/eta"
Instead of:
"kernel /eta/bzImage ip=dhcp root=/dev/nfs nfsroot=192.168.1.20:/diskless/eta"

The linux kernel will assume that the NFS server has the same IP than the DHCP
server.

Moreover: if you put this line:
"kernel /eta/bzImage ip=dhcp root=/dev/nfs nfsroot=/diskless/%s"
the linux kernel will replace "%s" with the IP adress of the diskless given
by the DHCP server.

lbarbuto: I got LTSP Running on gentoo with 12 Thin Clients, works great. Dont have PXE on the netcards though, so right now we are using floppys to boot the thin clients untill we get our hand on some real thin clients and not just old junk boxes

If you want some robust terminal, look here: http://www.thincan.com/_________________"Yes, I know Linux runs faster, but they can do that because they have thrown out the weight of the airbag, collision frame and safety belt." —Poul-Henning Kamp

First, the initial setup of this system is just right. But things I would change are the following:

Mount / via NFS, but mount all other folders via NBD, export image files from the server as NBD devices and then mount every other directory as NBD, except /usr/portage;/var, , because then you can share /usr/portage and /var, NBD only allows(safely) one machine to mount an image r/w.

advantages:
1)NBD allows ANY file system to be used, NFS does not. This gives you local journaling wither ext3 or reiserfs etc. Much better
2)SWAP can be mounted via NBD and it works quite well.
3)NFS has its own error correction, which is redundant because TCP/IP has very good error correction, this causes overhead, NBD does not do internat corrention and allows TCP/IP's build in error correction handle this, this allows more efficient data transfers.
4)your system believes that the NBD is a local piece of hardware, you can fdisk to your hearts content on these mounted drive images..
(BTW: NBD = network block device)
5)each directory would be its own file on the server, allowing quick and easy backups. Simply tar up the disk file and your set.
6) NBD is much faster that NFS, and has support for recovering a disconnected disk. If your NFS / fails, you lock and must reboot, if your NBD fails, you can fix the network error and NBD will remount the disk and allow operation to continue.

also, 3com has a NBD-on-floppy product available that can completely mount a remote volume and pass boot on to a windows bootloader so you can boot windows via the network. I have this and it works very well, I only need 1 copy of windows that iI can run anywhere on the network(only 1 instance at a time).