Contributions are invited for this section. Mail them to me.
You need gcc, gas and objcopy, as well as any accompanying libraries and include files. Generally speaking on a package based system using RPM or PKG, you will need the C compiler package, the include file package, the C library package, the assembler package and the binutils package (this may include the assembler). In addition, if you intend to modify the assembler files you will need an up-to-date as86 and ld86, not the ones that come standard with Linux, but from the ELKS project; or you will need nasm, and you need perl as the Makefile uses it for sanity checks. You will also need perl if you modify the file NIC and m4 if you modify this file README.xsgml.
Your gas is too old, upgrade to 2.91 at least.
Support for extended directives changed in syntax between gas 2.91 and gas 2.95. Enable -DGAS295 in Config to allow for the new syntax.
These are utilities contained in the (subset of the) Netboot 0.8.1 package that is included with Etherboot. You need to cd into this directory and run ./configure to create the Makefiles and then do make to create mknbi-linux and mknbi-dos in their respective directories. You may need to use --prefix=... directive if you wish to install in a non-default location. Or you can do the install by hand.
Etherboot is constantly updated, and binary images would get out of date soon. Binaries can lose any external indication of what release they were from. Old binaries might float around and create problems for users who are not aware that bugs have been fixed in newer versions. Also there are some user configurable options you might want to change. For this reason, Etherboot is provided in source form for you to build.
The floppy you use should be an error-free, preferably a recently formatted floppy. Do not trust new floppies; they have been known to lose their manufacturer formatting in storage. You don't need to put a filesystem of any sort on it, FAT or ext2 or otherwise. Another possible cause is that there are alignment differences between the drive used to write the floppy and that used on the target machine. As far as I know the floppy boot should work on all floppy sizes (1.44M, 720k, and even 1.2M and 360k if you can still find these), but beware of differences between drives, e.g. writing a 360k floppy in a 1.2M drive creates narrow tracks which may not overwrite previous contents.
Do you have a BOOTP or DHCP server running on the same Ethernet segment? On many operating systems the server is not enabled by default. Review the instructions in the Troubleshooting section. Another thing to note is that the BOOTP (or DHCP in fixed address mode) server will not reply if it does not know the network adapter's Ethernet address. Since the address may be hard to determine if it is not printed on the card or you do not have the adapter's setup program, you can copy it from Etherboot's startup message. Remember to restart the server if you have edited the config file and the server does not automatically reread when it discovers an updated config file.
Another thing to check is that the BOOTP or DHCP server is allowed to receive the query. You may have some protection mechanism such as tcpwrappers in front of it. As the booting computer does not have an IP address, the request will come from 0.0.0.0 so your rules must allow through packets from this address.
If the BOOTP or DHCP server is on another Ethernet segment, things get more complicated. You need to run a BOOTP or DHCP relay. You will probably also need to set the gateway field in the reply so that TFTP will work across the gateway. You should read a good explanation of how these work, in say, W. Richard Steven's book TCP/IP Illustrated.
Do you have a TFTP server running and is it allowed to serve the client in question? For example the tcpwrapper rules may not allow TFTPD to respond to the IP address the booting computer is at. You should look at the log files on the server for any clues.
Access violation is a blanket reply for many different problems but essentially the TFTP server cannot give Etherboot the file requested. Did you put the file where TFTPD expects to find it, e.g. on a directory that is on its path? Did you make the file world readable? Case of the filename is important too.
Is the file a tagged image? You cannot use a ordinary kernel image, you must process it with mknbi-linux first.
Tagged image format is specific to Etherboot and Netboot. It will not work with proprietary boot ROMs. You have to find out from the supplier what boot procedures you should use.
First of all, tagged image format actually precedes many of the proprietary formats in use today. So we were there first. Secondly there is no acknowledged standard for the boot image format, although there are some contenders now. Perhaps some day there will be an open, widely-accepted format. Until then you have to aware that there are different ones out there.
See an earlier section in this README document.
Please note that these estimates are approximate:
Did you build the kernel with the root on NFS option? You cannot use a stock kernel from a distribution.
Do you have a NFS server running and is it allowed to serve this client? NFS is actually several services. On Linux at least you need: nfsd (either kernel or userland version), rpc.mountd and portmapper. Check if the tcpwrappers config file is allowing portmapper to receive the request. Look at the log files for clues. Did we already mention that log files are your friends?
Please review the Troubleshooting section for what is required on this root filesystem. The situation is complicated by the fact that there are many possible ways of setting this up, including using a root filesystem that is on ramdisk. If you wish to avoid many of the troubles, try using a packaged solution such as www.ltsp.org or my shell scripts for creating a root filesystem by copying files from an existing distribution.
Remember that the config files used by the X server should pertain to the client's video adapter and display hardware. If you used a LTSP package, please review the configuration directions. If you used the copy files from server solution, then you need to customise the X server configuration. Another thing that may cause the server to abort is lack of a mouse device.
Either you don't have an XDM server running on the server machine or it is not allowed to serve this client. In the latter case check XDM's Xaccess file, because for security reasons, the ability for clients to connect is usually disabled.
Do you have an X font server (XFS) running on the server machine, is it allowed to serve this client, and has the client been told to use the font server? The last point is usually configured in the XF86Config file, or by a xset command to modify the font path after logging in.
Also note that RedHat (and possibly other distributions) has made XFS by default serve only the local machine using a Unix socket. You need to modify the startup script to tell XFS to use a TCP/IP socket.
It depends on the configuration. There are two major cases: where the client is an X-terminal, and not much more; and where the client is configured to run applications locally.
An X server will fit in 16MB of memory, and 32MB is quite adequate. Performance depends on the CPU, video card and your expectations. An old Pentium 200 with a PCI video card does very well, but if you are not fussy, a high-end 486 with a VLB video card can be satisfying too.
If you want to run apps locally, well how long is a piece of string? Netscape will need say another 16MB. It all depends. Whatever you do, it's worth trimming down on the services you run on the client. Don't run more virtual consoles than you need and don't run unneeded daemons.
As for the server, in the X-terminal case this has all the applications running on it, so it should be adequate for the multiuser aspect. A high-end Pentium, with 64 MB of memory to start with, and between 8 and 16MB for each extra client is a good starting point. It will also depend on your mix of client access, statistically perhaps not everybody will be running at the same time. Remember that you don't have to have one big server for all your clients, you can and you should distribute the load across servers.
There is a server program called p910nd at the Etherboot site (and improved versions of it at LTSP) that funnels data from a TCP/IP connection to the printer port. You can instruct lpd or CUPS (www.cups.org) on the server to send jobs across the network to p910nd.
There is a package called virtualfs that proxies the sound devices across the network. It can also proxy the floppy drive.
Besides virtualfs mentioned above, recent distributions of mtools have a floppyd. This only works with the mtools utilities though.
For now, there is just a short document in the doc/text directory. Better versions of this document depend on contributions from the FreeBSD community, I am unable to test FreeBSD because I don't run it.
For now there is just a contributed utility called mkfreedosnbi and a few instructions. I (Ken) am guity of this one. I got it to work and left it as is. FreeDOS is a moving target and the layout of the kernel image or other things may have changed so you would need to be well acquainted with FreeDOS. Please send any corrections to me.
mknbi-dos has some validity checks in the code, but it doesn't know about all the DOS variants. Try using the -f option to bypass these checks (and take your chances).
There is some difference between the DR-DOS 7.03 and 7.02 bootblock that causes it not to boot. But a 7.02 bootblock works just as well with the DR-DOS 7.03 kernel, so you can substitute that. There are instructions to extract the bootblock in the AT netbooting document.
Use the /testmem:off option to prevent HIMEM from scribbling over the ramdisk which is the floppy A:.
Use the rmrd.com program supplied in Netboot 0.8.1.
I pass on this one, as I do not have (by choice) any Windows systems running on my computers. Perhaps others can contribute to this section. However I gather that it is only possible on Windows95A, as other versions don't have the necessary support for diskless booting.
Depending on where you live, there are several suppliers listed in the Ethernet home page. Another possibility is to get the help of someone working in a university or industrial lab who has an EPROM programmer.
Some high end adapters, for example the 3Com and Intel ones, accept an EEPROM in the socket. This can be programmed in-situ using utility programs, some of which or information about are under the contrib directory in the Etherboot distribution.
Finally some recent motherboard have flash BIOSes which contain space where an extension BIOS such as Etherboot can be inserted. The Phoenix Award BIOSes can be modified using a program called cbrom.exe possibly here (or do a Web search for it). No success has been reported for AMI BIOSes.
These jumperless cards need a card-specific utility program to enable the ROM. Normally the manufacturer supplies it on a diskette or CDROM. You lost the diskette? If you know the manufacturer, you might be able to get the program from their website. You have a mystery card? Well the first thing to do is to identify the card. If it is an ISA card and made in Taiwan it's almost certainly a NE2000 clone. For some information, try here.
The problem is that laptops these days use PCMCIA network adapter cards. These in turn connect to the PCMCIA controller when docked. To be able to communicate with the PCMCIA card, Etherboot would first have to talk to the PCMCIA controller. Until somebody writes the code to do this... Booting from disk is different because the kernel will load the PCMCIA controller code from disk first. You could always put a Linux kernel on the boot floppy.
If I were independently wealthy and had nothing else to do in life, sure! But unfortunately I have a day job and Etherboot is a hobby. A couple of the drivers were written for pay and the others were written by volunteers. Perhaps you might like to volunteer? If you have a good grasp of C, and understand basic hardware concepts, it is quite doable, and not nearly as difficult as writing a Linux device driver. See the section on Writing an Etherboot Driver. You will have the reward of understanding hardware intimately and seeing your work benefit users worldwide.
No, the structure of Linux and Etherboot drivers are quite different. There are several reasons: Linux drivers are more complicated and written to give good performance, whereas Etherboot drivers are written to be simple. Linux drivers are interrupt driven, whereas Etherboot drivers are polling. Linux drivers have an elaborate support structure, whereas Etherboot drivers are fairly self-standing. Finally Etherboot drivers have a difficult constraint on the amount of memory available to it, about 32kB near the top of 640kB.
But... you can use Linux drivers as a source of reverse-engineering information. Several of the drivers in Etherboot were adapted from Linux drivers. But don't send me the file; see previous FAQ about volunteering. And I have the latest Linux source anyway, doesn't everyone?
Please join the Netboot and/or LTSP mailing lists. The former is listed on the Etherboot home page, and the latter is listed at LTSP. Netboot is for general netbooting issues, while LTSP is focused more on the LTSP packages. However there is a fair amount of overlap between the lists and several key people are on both lists. Posting to a list is preferable to mailing me because: you get the benefit of a lot of experts seeing your question (no, I don't know everything, if only because there are many configurations I have never used); if your question is answered, a lot of people see the answer and this helps them too; and finally you may not get an immediate reply from me because I may be not reading my email or on holiday or just plain grumpy :-).
Note that the Netboot mailing list is spam protected, so you have to join to be allowed to post. Also if your ISP has been slack security-wise and had a machine of theirs get onto one of the Open Relay Blacklists, then you will not be allowed to post either. The only things I can suggest are to change your ISP to a more responsible one, or to get a Web based mailbox.