Please check this section if you have a problem before asking on the mailing lists.
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 DEB, 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). You will also need perl if you modify the file NIC or use a different RELOCADDR value in the Makefile than the default, and m4 if you modify this file userman.xsgml.
Your gas is too old, upgrade to 2.9.5.
They are harmless, you can ignore these. They are due to changes in the assembler syntax between gas versions. We could get rid of the warnings if we could easily detect which patches are installed in the version of gas you are using (it's not just a matter of detecting the gas version) but we'd rather just wait for the old gas versions to disappear since they are just warnings.
These are distributed from the Etherboot web site.
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. However you might wish to check out rom-o-matic.net, which is a site that makes ROM images for you on demand from specifications given to a web form and returns the image as the result of the form.
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. Another possible reason is you are not using a 1.44 MB floppy. The boot sector boot1a.s may not work on other floppy sizes. If you find this is the case, then try substituting floppyload.S for boot1a.s as the value of DISKLOADER in the Makefile. This boot sector 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 or a firewall 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 installed and 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. Check the log files on the TFTP server to see what the actual filename it tried to open was, sometimes directory prefixes are prepended to the name due to the program options specified.
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. For example, if you are using a LanWorks boot ROM, the information you need is here.
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 manual.
Please note that these estimates are approximate:
Did you compile the network adaptor driver into the kernel? Is the network adaptor at an address that is probed by the driver? If not, perhaps you need to provide some kernel parameters to help it find the hardware.
Did you build the kernel with the root on NFS option? You cannot use a stock kernel from a distribution. Another reason might be you are running a recent kernel (2.2.18 and higher in the 2.2 series, not known from what release number in the 2.4 series) where IP Autoconfiguration is not enabled by default. You need to add ip=dhcp or ip=bootp to the kernel parameters (this requires mknbi-1.1 and above). Or you can use the append= option in mknbi-1.0 to add this option.
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?
A common mistake in Linux NFS servers is to put extra spaces in /etc/exports. Please see the NFS FAQ for frequently answered questions about Linux NFS services.
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 LTSP.
There is no one true way, but several approaches. Network booting is a tool and a very flexible one. Here are just a few suggestions:
If you have an approach which you think the world should know about, please send the URL of a web page that describes it to me.
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.
This is to be expected! This is exactly how an X-terminal works. You are indeed logged onto the server and the client just provides display (screen) and input device (keyboard and mouse) services to the application. This is one of the beauties of the X Windowing system model, it's network transparent.
The client can be configured to allow you to run programs locally. What you have to do is either start the application from the init scripts run during bootup, as would be the case for the printer and sound daemons mentioned later; or to start a shell interpreter on the client, either through an interactive login to the client or a remote execution of a command from the server to the client. Common methods are rsh (insecure) and ssh (better).
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 web site (and modified versions of it at LTSP) that funnels data from a TCP/IP connection to the printer port. You can instruct lpd or CUPS 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.
Another solution is EsounD
You may wish to check the LTSP site and mailing lists for other proposed solutions.
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 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.
The new mknbi utility supports creating tagged images from FreeDOS kernels now. See the man page for details. 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.
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 with mknbi.
The --harddisk option of mknbi is intended for this. It causes your boot drive to be C:, so you can use A: for the real floppy. See the man page for more details
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, you might find a supplier listed on the Commercial Links page. Another possibility is to seek the help of someone working in a university or industrial lab who has an EPROM programmer. If you are handy with hardware, you could buy a kit or build your own. There are links to kit suppliers in the Commercial Links part of the home page.
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. It is also reputed to live here. Or do a Web search for it. No success has been reported for AMI BIOSes. Dirk von Suchodoletz maintains a list of successes and failures here.
Here is some text contributed by Dirk von Suchodoletz. He hopes to put it on a web site someday:
6.4 Using your mainboard's BIOS to integrate etherboot-code Newer mainboards that have an AWARD-BIOS can use etherboot without separate EPROMS and therefore without the necessity of having a EPROM-programmer[?]. (Heinrich Rebehn wishes to add: Flashing the BIOS is always a (small) risk. Flashing with unsupported, hacked BIOS image is *dangerous* and may render your PC unbootable. If you don't have access to a PROM burner you should stay away from experimenting.) In order to do this, you need 2 software tools: awdflash.exe, which should be included in your mainboard package, and cbrom.exe, which is an OEM-tool that allows modifications of the BIOS. awdflash.exe reads and writes the flashrom content, whereas cbrom.exe is used to analyse the content of the AWARD BIOS image. cbrom.exe can also add code to the BIOS image or remove components. This way you can easily integrate etherboot into your mainboards without even opening the PC's case. After the BIOS image has been saved (e.g. as bios.bin), or in case the current version of the BIOS has been copied from the board manufacturer's website, 'cbrom bios.bin /d' shows how much space is left on the image for your code. As the flashrom holds the compressed BIOS, cbrom will also compress the code when adding it to the BIOS. Therefore, 8 to 20 kbyte of free memory is needed, depending on the network adapter's driver. In case not enough memory is left, unneeded BIOS components can be removed from the BIOS image to regain space: the manufacturer's logo or the Symbios/NCR SCSI-code are note needed for diskless systems. 'cbrom bios.bin /[pci|ncr|logo|isa] release' will remove those unnecessary components. The command line "cbrom bios.bin /[pci|isa] bootimg.rom [D000:0]" adds the compiled etherboot code to the bios. bootimg.rom is the code we would use to burn onto EEPROMs in other cases. Depending on your network card, either the pci or isa options have to be used. With isa cards you have to tell cbrom to which RAM location the code will be extracted at boot time. Attention: Compile the etherboot with the -DASK_BOOT or -DEMERGENCYDISKBOOT option to be able to access a disk. The code added by cbrom will be executed before the computer seeks for a boot disk or floppy. 6.5 Booting with a DOS executable (COM) file If the computer has to be used with more than one operating systems, for example using the computer as an X-Terminal in addition to the already installed NT on the harddrive, etherboot has to be used with the compile-time option -DASK_BOOT. In case hardware-conflicts between Windows NT and the installed EPROM exist, creating DOS Executables (e.g. using 'make rtl8139.com') can provide a useful remedy. Those DOS Executables are comparable in their functionality to .rom images and can be used as substitutes. In case an existing DOS-bootsector, stored in BOOTSECT.DOS, cannot be used, creating one has to be done by formatting and installing a harddrive using DOS before installing NT (see Win-NT Multiboot-HOWTO). In addition the DOS system files are needed (IO.SYS, MSDOS.SYS, or KERNEL.SYS when using Freedos) and have to be copied into the directory of the NT loader. If using Autoexec.bat to start the .COM file is desired, either the particular COMMAND.COM has to be provided or the etherboot file needs to be renamed as COMMAND.COM. This file will then be started instead of the DOS-Shell which is useful for avoiding unwanted user interaction. Afterwards a line has to be added to BOOT.INI as if DOS was to be booted: [boot loader] timeout=20 default=C:\bootsect.dos #add this line if dhcp/tftp should be default action [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows NT Workstation, Version 4.0" [VGA-Modus]" /basevideo /sos C:\bootsect.dos="DHCP/TFTP (Linux diskless via etherboot)" #our boot option
And here are some comments by Rapp Informatik Systeme GmbH about cbrom.exe versions:
Some more remarks for cbrom.. There are several version numbers of cbrom.exe p.e. 1.x and 2.x. and there is a cbrom called cbrom6.exe. First cbrom.exe with Version 1.x (newest 1.32) is for Award Bios Version 4.5x and cbrom6.exe is for Award Bios Version 6.xx. So because it seems a lot people become confused and use cbrom 1.x for the new 6.x Bios Award merged this together to a cbrom.exe with Version number 2.x ( newest know 2.04) witch now runs on Award 4.5x and 6.xx Bioses. Now how to find cbrom.exe. Different 1.x Versions of cbrom.exe could be found on the net, cbrom6.exe seems to be gone. It seems that Award/Phoenix do all that cbrom is deleted from servers of board manufactures. So cbrom.exe Vers 2.04 is not available on the net. If somebody need this please try to send a demand question to the list - I hope somebody will mail it to you.
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 or China it's almost certainly a NE2000 clone. For some information, try here. If it's a PCI card, then either the BIOS or the Linux PCI Utilities should be able to tell you the manufacturer and device IDs, which you can then look up to convert to names.
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 developer manual. You will have the reward of understanding hardware intimately and seeing your work benefit users worldwide.
If you are a commercial entity, you might consider assigning staff or hiring a volunteer to write the driver. You get the benefit of the rest of the Etherboot code infrastructure and users worldwide get to appreciate your contribution. Bear in mind the GPL license conditions, of course. NIC manufacturers note, this may be one way to attract users to your hardware products. NIC users note, petition your NIC manufacturer to support Etherboot.
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 48kB 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 driver source; see previous FAQ about volunteering. And I have the latest Linux source anyway, doesn't everyone?
Please see the section on getting help earlier in this document.