Netboot




		T R O U B L E S H O O T I N G



If you run into any problem during installation or when using this
package, please first read the following text and all other relevant
documentation. Especially you should consult your server's documen-
tation if you run into problems setting up your server. Also refer
to your network card's or driver's user manual or the documentation
for the operating systems of the diskless clients accordingly. However,
if you still can't solve the problem on your own, you can send me an
email to

		netboot@gkminix.han.de

Users able to speak German can send me the mail in german. Otherwise
please write in english. I already received some emails in so poor
english that I haven't been able to even understand the problem. I
can't help you in that case. And please excuse me that I can't answer
questions sent to me by standard mail or telephone calls. I just don't
have the time for dealing with that.
If you decided to send me an email please describe your problem as
exactly as possible. It usually helps to send me relevant portions
of configuration files (I have to pay for my internet access by myself
so please keep quotings as short as possible). Especially with problems
with the bootrom it usually helps to _exactly_ write down the screen
output, not only but including any error messages. Also state as exactly
as possible how you created the problem so that I can try to simulate
it on my own hardware.
In case you got the netboot package as part of some other software dis-
tribution (for example etherboot), please check with the author of that
distribution first to make sure that your code is not modified against
the official netboot version.
Additionally please note that I can't help you with every problem with
your server, as there are so many different systems on the market. The
same is true for problems with network cards. I just don't have the
financial capabilities to buy any card on the market for testing. Per-
sonally I'm using RTL8139, SiS900, 3C905B/C, VT6102 and EtherExpress
cards, so I can probably help you with those.
If you find a problem which looks like a bug in the code I really
appreciate a short notice from you. And if you have a fix for the bug
I would even more appreciate your message.
Besides contacting me directly there also exists a mailing list related
to network booting which you can subscribe to. Write a mail with the
message 'subscribe netboot' in it's body to majordomo@baghira.han.de
(the subject of the mail doesn't matter). The readers of the mailing
list should also be able to help you with any problem you might have
while setting up a diskless client. And besides that I'm also going
to announce any new version of this netboot package to the mailing
list. Please read the README file provided with this package before
subscribing to the mailing list because it contains a couple of useful
tips to observe when using the netboot mailing list processor.




Problem: My operating system OS/XY is not supported by netboot

	I would gladly provide support for every operating system on the
	market, but I don't have the resources for doing this. However,
	if you want a particular operating system to be supported, you
	should get in contact with me. In any case you will have to provide
	me with a valid and licensed copy of that operating system. You are
	also invited to write your own boot loader, and send it to me for
	inclusion into netboot under the terms of the GNU GPL.



Probelm: I downloaded a bootrom code from rom-o-matic, but it just doesn't
         work after downloading the image created with mknbi-xxxx.

	rom-o-matic uses the bootrom code of etherboot, which is different
	from netboot. If you want to use the netboot mknbi tools, you should
	create the bootrom using the makerom tool provided with netboot.
	Otherwise refer to the etherboot project for further details.



Problem: Where can I find a network driver for my NIC?

	Usually the manufacturer provided network drivers work better than
	those provided with netboot (the manufacturer usually has the best
	knowledge of it's products). If your manufacturer doesn't provide
	a driver floppy with the NIC your best bet would be to look at the
	manufacturers web pages (like www.3com.com or www.smc.com). If you
	don't know the name of the company that made your NIC (like with
	most cheap NE2000 compatibles), you can often find a name printed
	on the chipset of your network card. For example, many cheap NE2000
	PCI cards use a Realtek RTL8029 chipset. Then, you can get drivers
	for your network card from the manufacturer of the chipset (which
	is www.realtek.com.tw in this example). Many links to NIC manufac-
	turers and also direct links to driver pages can be found on the
	netboot web server on

		http://www.netboot.info/english/links.html.



Problem: There are so many drivers on the disk provided with my network
         card, but which can I use with netboot?

	Packet drivers can often be found in a directory called "pktdrv", "ftp"
	(because this standard has been developed by a company named FTP Inc.)
	or simply "packet". They usually end with the extensions *.EXE or *.COM.
	With NDIS it's often not as easy because there are different types.
	First, you can only use NDIS drivers which are compatible to version
	2 of the NDIS specification. Those drivers are designed to run under
	DOS or OS/2, but NOT under Windows-95, Windows-98, Windows-NT or any
	later M$ operating system. NDIS drivers for DOS commonly have the
	extension *.dos, while those for OS/2 have *.os2. You can only use
	DOS drivers with netboot. They can often be found in a directory named
	"ndis", "ndis2" or "lanman" on NIC driver disks.



Problem: I have copied all relevant network drivers off the driver disk but
         'makerom' (or 'make bootrom' which is the same) doesn't show them
         in it's driver/network card listing

	In order for 'makerom' to find your drivers you have to copy them into
	the directories specified in the netboot configuration file. Usually,
	this will be /usr/local/share/netboot/netdrvr/pktdrvr for packet driver
	binaries and /usr/local/share/netboot/netdrvr/ndis2 for NDIS drivers.
	Also your network card and your drivers have to be listed in the
	netboot drivers database. This file can usually be found as
	/usr/local/lib/netboot/netboot.drivers. Please see the 'makerom'
	man page about the syntax of this file. If your network driver
	is not listed here, you can either insert an entry by yourself (and
	also remember to send it to me), or use "(0) unknown network card
	with vendor provided driver" when makerom asks you to select a
	network card. You will then have to enter all required parameters
	for your driver by hand.



Problem: I get an error from 'make' saying something like "missing delimiter"

	Some of the Makefiles use constructs which are not available with
	older make programs. Even some more "modern" systems like SCO Open-
	Server 5 have this problem. In that case you will have to get and
	install GNU make on your system (which is the better choice anyway).



Problem: The bootrom doesn't startup at all

	Either you have a floppy in your diskette drive or you have
	a hard disk installed with a partition marked as active, and the
	bootrom has been built so that it lets the BIOS look for active
	partitions first. Both conditions let the system boot from the
	bootable media instead of using the bootrom. Just remove the
	floppy or use fdisk to mark all partitions as unbootable (e.g.
	inactive). Alternatively you can also build the bootrom so that
	it does not allow the BIOS to look for bootable partitions. The
	program which actually creates the bootrom ('makerom', it gets
	called when you run 'make bootrom') will ask you about this.

	Another problem might be that your BIOS doesn't detect the
	bootrom. First you should make sure that your network card really
	supports ROMs of the size used. For example some network cards
	are known to offer the use of 32kB ROMs with their setup software,
	but in reality only allow access to the first 16kB. You should
	boot your system with plain DOS and check with a debugger that
	the whole ROM area is readable and exactly the same as in the
	binary file you used for burning the EPROM. When using a debugger
	do NOT use any memory manager like EMM386. Also you should always
	turn off any ROM shadowing for the bootrom. You won't get any speed
	improvement with this anyway due to the design of the bootrom code.
	When using a PnP network card make sure that you use a system with
	a BIOS which supports PnP. Almost all PnP network cards need a
	proper initialization before they enable the ROM. Without a PnP
	BIOS this initialization is usually done by the operating system,
	which is obviously too late for the bootrom.
	If you can't get the ROM version to work, but the floppy version of
	the bootrom operates as expected, you can search for the error by
	using the romcheck program. Refer to the file README.romcheck for
	further information.
	A special problem exists with some newer versions of the 3Com 3C905B
	NIC. These cards don't recognize the bootrom even if it's been setup
	correctly for some strange reasons. If you have such a card and can't
	get the bootrom running you will have to use a FlashCard. I have no
	3C905B available to find the reason of this problem.

	Starting with version 0.9 the netboot bootrom is compatible with
	the BIOS Boot Specification (BBS). If you have a BIOS which supports
	BBS, you have to select the network boot in your BIOS setup in order
	to start the bootrom. However note that some BIOSes (notably Award
	Modular BIOS) have a setup option for network boot but are not BBS
	compliant (see the next question).



Problem: My BIOS supports the "network boot" option in it's setup but no
         matter how this switch is set, the bootrom never starts, or it
         always starts even if I tell the BIOS not to start it

	There are three common bootstrap methods for starting the bootrom:

	1.) Int 18h

		Historically, Int 18h was used to invoke the built-in ROM
		BASIC interpreter. This was done by any option ROM or bootstrap
		program that was invoked by Int 19h (see below). It was also
		done by the system BIOS if there were no option ROMs (like
		network bootroms) or bootstrap programs (like floppy or hard
		disk boot sectors) to run.

		Some BIOS vendors added to their BIOSes the ability to select
		which devices could be boot devices, and in what order to try
		to boot them. At first, you could select from floppy or hard
		disk. Then, CD-ROMs were added to the list, and finally, network
		boot was added. BIOSes that support int 18h boot order selection
		detected network boot devices by checking to see if the option
		ROM (e.g. the netboot bootrom) would hook int 18h during it's
		initialization phase. If an option ROM hooks int 18h and network
		was the first bootable device in the boot order list, the option
		ROM that hooked int 18h would be called by the BIOS. There is
		no check if the option ROM really is a network boot device.

		If your BIOS supports int 18h boot order selection, you have to
		answer to makerom's question

			Do you want the BIOS to look for boot disks?

		with 'yes'. In this case, the netboot bootrom will hook int 18h
		upon startup, and therefore gets controlled by the BIOS. If your
		BIOS does NOT support int 18h boot order selection, and you
		answer 'yes' to this makerom question, the BIOS will always
		first try to load an operating system from an installed boot
		medium before trying to start the netboot bootrom.

	2.) Int 19h

		When the BIOS completes it's POST it will invoke int 19h which
		usually points back into the BIOS and starts looking for a boot
		disk (either floppy, hard disk or CD-ROM). If you answer to the
		above mentioned makerom question with 'no', the netboot bootrom
		will hook int 19h and therefore prevent the normal BIOS startup
		process. In this case, the netboot bootrom always gets control
		no matter what boot order you select with your BIOS setup. This
		is called a "legacy" boot. If your BIOS doesn't recognize the
		netboot bootrom this is kind of a last resort for starting it
		up. When creating a bootrom which hooks int 19h as described
		above, makerom will ask you:

			Do you want the bootrom to ask before booting from
			network?

		If you answer 'yes' to this makerom question, the bootrom will
		lateron ask the user upon system startup whether to boot from
		the network or not. If the user answers with 'y' the bootrom
		will continue with the network boot. Otherwise it will return
		to the BIOS and let it continue with it's standard disk boot
		sequence.

		Please note that when int 19h hooking is selected, the netboot
		bootrom will always first look for a boot floppy in the A: drive
		by itself. It therefore simulates some of the normal BIOS boot
		process itself. This has been implemented in order to allow to
		boot a client even if some of the network is down or otherwise
		inoperative.

	3.) PnP BIOS/BBS:

		When your BIOS complies to the BIOS Boot Specification, the
		netboot bootrom will only startup if you select network boot
		in the BIOS setup boot order. The netboot bootrom will auto-
		matically detect whether it's running on a BBS compliant
		system or not. Be aware that even if your BIOS says that it's
		PnP compatible, it doesn't necessarily have to be compliant
		with BBS. And even if it supports BBS, some BIOSes may require
		the bootrom to be physically located on the network card (instead
		of being installed on a seperate card like a FlashCard) to take
		advantage of the BBS features.

	If your system doesn't start the netboot bootrom as expected you have
	to experiment a little bit with your answers to the makerom questions
	mentioned above, as there is no easy way of predetermining the way how
	your BIOS has been implemented. I'm still looking for experience reports
	regarding different BIOSes, so if you have any special problems with
	starting the netboot bootrom please let me know. Especially, include
	the type and version number of your BIOS in your message.



Problem: The bootrom behaves strange during startup, and may even hangup
         the whole system

	If you compiled the mknbi programs on a system with big endian
	byte order (like Motorola or PPC systems) this might indicate
	that the configuration program couldn't find the correct byte
	order. It might also be that there is a bug in the byte ordering
	code. Some systems like SPARCs also do not allow data accesses at
	misaligned addresses. 'configure' should usually find out about
	these conditions. In any case, if 'configure' is not able to pro-
	perly detect what kind of system you are using, edit the file
	config.h accordingly by hand and try it again. Please report this
	condition, and also note which system you used for installation.
	Of course, this error condition can also appear with a bug in the
	bootrom code itself. Therefore, if you can't solve it yourself,
	please report such problems to me.



Problem: The network driver is not able to start properly

	First check what error message the network driver prints. Usually
	this problem is a result of an incorrect setup of the network
	card, so check that it uses an I/O address, interrupt line and DMA
	channel (if applicable) of it's own, and that the network driver
	uses the correct values. Another common problem with ethernet
	cards which use shared memory (like WD80?3 cards) is an overlap-
	ping of this shared memory with the rom area used by the bootrom.
	Select a different shared memory address in that case. If that's
	ok you should next check that you configured the network driver
	correctly with the bootrom configuration program 'makerom'. Usually
	the network driver prints out what it expects the hardware to look
	like so you can use this information to check up your setup.
	It might also be that your network driver doesn't get as much memory
	as it wants without printing an error message, or during loading the
	network driver gets scrambled up due to memory problems. This can
	happen if 'makerom' assumes an invalid memory requirement for the
	network driver. To solve such a problem you should use the minsize/
	maxsize parameters for your network driver. Please check the 'makerom'
	man page for further information on these parameters.



Problem: The bootrom tells me that there is not enough memory but I have
         xx megabytes installed

	This problem is a result of the fact that the BIOS starts the
	bootrom in the processor's real mode. The bootrom is therefore
	only able to access the lower 1 megabyte of memory, regardless
	of how much you installed. And 384kB of this is reserved for
	ROM's and the video memory, so there is only 640kB left. Unfor-
	tunately some systems even reserve memory from these lower 640kB
	for internal BIOS data. This is called extended BIOS data area,
	and known to be used on most PS/2 systems. But also some other
	BIOSes use such an extended BIOS data area, which is usually
	selectable in the system's setup. Therefore you should try to
	deselect such a feature.

	It might also be that your network driver is too large. Even if it
	physically fits into the bootrom this might happen, because the
	driver has to run in the memory space made available by the DOS
	simulator running within the bootrom. The actual amount of memory
	available to the network driver can't easily be predicted. However,
	you should try to use a different driver (either a packet or NDIS
	driver) for your network card. Also, experimenting with the minsize
	and maxsize parameters of a network driver definition in the file
	/usr/local/lib/netboot/netboot.drivers might help. Please consult
	the makerom man page on information about the minsize and maxsize
	network driver parameters.

	Another problem can be that the network driver tries to allocate
	a whole lot of memory for transmit and receive buffers. If your
	network driver supports selecting the size or number of such buffers
	(sometimes also called send - / receive - queues), use a value of 1.
	The bootrom is only able to utilize one such queue, which is suffi-
	cient for it's purposes, so anything more is just a waste of free
	memory. In this case it might also help to increase the value of
	the minsize and maxsize parameters - please consult the man page of
	'makerom' for further information.



Problem: The bootrom prints an error message with an error number

	Those error messages look like:

		Bootrom error:PXE-xx

	with xx being a hexadecimal error number. Some more commonly encoun-
	tered error numbers are:

		10	ARP canceled
		11	ARP timeout
		20	MCOPY problem: the BIOS is unable to correctly copy
			a received packet
		30	TFTP ARP problem
		32	TFTP open timeout
		33	received unknown TFTP opcode
		35	TFTP read timeout
		36	received invalid TFTP opcode
		38	error during TFTP open
		39	error during TFTP read
		3B	boot image not found on server
		3C	access violation while opening boot image on server
		40	BOOTP canceled by keystroke
		41	BOOTP timeout
		42	some information (like the TFTP filename) is missing in
			the BOOTP answer
		50	DHCP canceled by keystroke (if DHCP is supported)
		51	DHCP timeout (if DHCP is supported)
		52	missing server IP address in DHCP/BOOTP answer
		53	missing boot image file name in DHCP/BOOTP answer
		61	media test failed by network driver
		62	cannot initialize NIC for multicast
		63	network driver is unable to initialize the NIC
		64	network driver is unable to initialize the NIC hardware
		67	the NIC has an invalid hardware ethernet address
		69	UNDI driver out of resources
		D0	invalid boot image

	Especially the hardware errors or timeout problems might be caused
	by the interrupt handling of the bootrom. PCI cards can have shared
	interrupts. Even though network interface cards should never use a
	shared interrupt for performance reasons, the BIOS usually doesn't
	care about this. The packet and NDIS driver interfaces are unable to
	handle such situations. Therefore, you have to check that there
	are no PCI interrupts shared. For example, you can remove all PCI
	cards in your system but the network and video cards. If you had
	an interrupt sharing problem, the bootrom should now be able to
	work correctly. You can then try to add more PCI cards. If one
	card causes hangups again, try enabling more interrupt lines for
	PCI and PnP services using the BIOS setup. A good source for further
	PCI shared interrupt issues is:

		http://support.3com.com/infodeli/inotes/techtran/d2fa_5ea.htm

	Even though this is specifically for 3Com network interface cards,
	it can also be applied to all other NICs.



Problem: The bootrom doesn't receive a BOOTP/DHCP answer and just hangs printing
         dots

	First you should check if bootpd or dhcpd runs on your server or is
	started properly from inetd. Then check that the server's configuration
	files (for example /etc/bootptab when using bootpd) are setup correctly.
	Especially the hardware address and the client's IP address and name
	have to be correct. 
	Most BOOTP/DHCP servers have the ability to write debugging information
	into a log file. Use that feature to verify that your server really
	receives bootp requests from the client's bootrom and sends out a
	valid answer. Also check for error messages in the log file. Even
	if your server doesn't write into a seperate log file it might use
	syslog on your system, so find the log file name from your syslogd
	configuration file and check for errors.
	If you are able to use a network tracing program like tcpdump you
	can check if the bootrom sends out correct requests and that the
	server is answering correctly. In that case it is more likely to
	be a problem in the bootrom, so when using a packet driver you should
	create a new bootrom image with the packet driver debugging module
	included. You should then see the bootrom's request packets going out,
	and the server's answers coming in. If there are no packets coming in
	although you verified that the server is sending out correct replies
	there might be a problem with your network card. Did you set it up
	correctly?
	If everything fails try to boot the diskless client with the
	intended operating system and try to access the network card
	using that operating system's tools to check the proper operation
	of the network card.
	If the server is not sending out answer packets, but it's logfiles
	indicates correct answers, it might be a problem with the arp setup
	on your server. Normally arp shouldn't be a concern for you. However,
	some older versions of bootpd for Linux had problems here, which could
	be solved by setting the kernel arp table manually, or upgrading to a
	newer kernel _and_ bootpd version.



Problem: The bootrom did get a BOOTP/DHCP answer but is not able to load the
         bootimage file

	This is likely to be a problem with the tftpd setup on the server.
	Does tftpd run when you startup the bootrom code? If not, check
	that inetd is configured correctly. Also there might be a TCP/IP
	wrapper running on your server which might prohibit access to
	the tftp service (which is known to be very insecure and therefore
	a candidate for getting started by an internet security wrapper
	like tcpd). Check any access configuration files for tcpd.
	Furthermore tftpd has to be able to access the bootimage file. It
	usually runs as a user with very low privileges because of security
	reasons and might not be allowed to read the bootimage file, so
	you should check and set the bootimage file's permissions correctly.



Problem: The boot image loader reports an error

	Congratulations! You just discovered a bug in the boot loader.
	Please report it to me.



Problem: When I'm using the bootrom menu to load a Unix system off the local
         hard disk, it reports some weird error messages to me (especially,
         SCO Unix says that it's not able to open boot device). However,
         booting without the bootrom works without a problem.

	Some operating systems, especially Unix like systems, read the
	partition table after booting and try to find their own boot par-
	tition. When using the bootrom, it's not necessary to mark the
	Unix partition as bootable, so the Unix startup loader fails.
	To solve this problem, mark the Unix partition active with some
	fdisk program. To avoid that it starts running instead of the
	bootrom, create the bootrom so that it does not allow the BIOS
	to search for boot partitions on the installed hard disks ('makerom'
	will ask you about this).



Problem: When trying to boot Linux, the system does a reboot immediately
         after the boot image has been downloaded

	This problem sometimes occurs with Linux kernels 2.1.x and newer,
	because they have changed the layout of the boot sectors of the
	kernel slightly. If you experience this problem, you should first
	upgrade mknbi-linux to the latest netboot version. If that doesn't
	cure your problem, try compiling the Linux kernel as a bzImage
	instead of a normal zImage. If the problem still persists, please
	let me know.



Problem: I'm loading Linux onto my diskless client and the kernel tells
         me to insert a root floppy and press enter

	First you should check that you built your kernel correctly. It
	should have support for the root filesystem built in. If you want
	to use an NFS mounted directory as root the kernel should have
	TCP/IP support installed. Also it has to have a driver for your
	network card built in, and NFS and NFSROOT have to be both speci-
	fied. When using a ramdisk it's support has to be compiled in
	as well as support for the filesystem with which you formatted
	the ramdisk image. Please note that the loaded kernel is not
	able to use modules at bootup time (only _after_ the root file-
	system has been mounted, but not before), so everything has to
	be compiled in.

	If the kernel is not able mount it's root via NFS, this might
	have many different reasons. It requires all addresses in the
	bootpd or dhcpd configuration files to be correct, and the access
	rights on the server have to be set correctly - not only in
	/etc/exports but also the permissions for the directory to be
	mounted. If that's correct check that a portmapper is running on
	the server, and that it registered the mountd and nfsd services
	correctly. You can usually do this by running the command

			rpcinfo -p

	Note that services are only listed here if their associated server
	process is really running. The rpcinfo output should then look
	something like this:

		   program vers proto   port
		    100000    2   tcp    111  portmapper
		    100000    2   udp    111  portmapper
		    100003    2   udp   2049  nfs
		    100003    2   tcp   2049  nfs
		    100005    1   udp    663  mountd
		    100005    1   tcp    665  mountd

	However, the port numbers might be different.

	When the kernel starts mounting the NFS root directory it prints
	out the name of that directory on the server. It should be the
	same as the one configured with bootpd/dhcpd. Check that it's
	correct. If not you can try to use the -d option with mknbi-linux
	to specify the name explicitely.

	If the kernel gets an error from the server's nfsd, it prints
	a number which is defined according to the NFS protocol. The
	most commonly occurring numbers are:

		 1  -  permission denied to access directory
		 2  -  directory doesn't exist
		 5  -  I/O error on server filesystem
		13  -  nfsd is unable to access directory
		20  -  path name is not a directory
		63  -  path name is too long

	Note that some nfsd and mountd programs only read /etc/exports
	on startup. If you changed this file afterwards, you will have
	to restart both daemons. Additionally, with nfsd versions for
	Linux earlier than 2.1 you will have problems with special files
	like UNIX domain sockets or block/character special files on
	your NFS partitions. You should therefore use the latest avai-
	lable versions.



Problem: The Linux kernel mounts it's root correctly but doesn't give me
         a login prompt.

1.)	This might be the result of an incorrect setup of the root file-
	system (see No. 2 below). However, it's also possible that your
	server reported the wrong major/minor numbers for the console device
	even though you specified them correctly in the NFS mounted root
	directory. I know of this problem with AIX and HP-UX servers,
	but there might exist others as well which don't transfer special
	devices via NFS as Linux requires it. One solution to solve this
	problem is to boot the diskless client with a ramdisk image as
	it's root, and then mount the should-be-root directory on the
	server using NFS. Then you can create the special files in the
	dev directory using Linux's mknod program, and use the NFS root
	mounting bootimage again.
	Another way is to try to find out, how the server operating system
	encodes major/minor numbers on it's own filesystem. For example,
	HP-UX uses a 32 bit device number, with the 8 highest bits being
	the major number, and the lower 24 bits being the minor device
	number:

		major << 24 | minor   ==>   aaaaaaaabbbbbbbbbbbbbbbbbbbbbbbb

	In this representation (a) means a bit of the major number, and
	(b) means a bit of the minor number. Linux uses the following
	scheme instead:

		major << 8 | minor    ==>   0000000000000000aaaaaaaabbbbbbbb

	The NFS protocol now transfers these 32 bits just as they are,
	without any further interpretation regarding major/minor numbers.
	That means, that all relevant bits in the Linux representation
	fit into the minor number on HP-UX. Therefore, if you create a
	device on the HP-UX server, you have to always give it a major
	number of zero and compute the minor number the way mentioned
	above for Linux. For example, to let Linux see a device 5/2 in
	it's NFS-mounted /dev directory, you can compute the minor device
	number on HP-UX as

		5 << 8 | 2    ==>  1282

	So the device to create on the HP-UX server is 0/1282. This will
	let Linux see 5/2 after the filesystem is mounted with NFS.

2.)	Another reason for this problem might be that the init process
	doesn't get started at all. This can be a result of incorrect
	shared libraries, which the client might see but without a proper
	ld.so.cache file. Or the shared libraries are not reachable by
	the client at all. Bruce Janson and Markus Gutschke collected a
	good list of possibilities, which you should check out:

		- you do not have a private copy of the /, /etc, /var, ...
		  directories

		- your /dev directory is missing entries for /dev/zero and/or
		  /dev/null or is sharing device entries from a server that uses
		  different major and minor numbers (i.e. a server that is not
		  running Linux - see above).

		- your /lib directory is missing libraries (most notably libc*
		  and/or libm*) or does not have the loader files ld*.so*

		- you neglected to run ldconfig to update /etc/ldconfig.cache
		  or you do not have a configuration file for ldconfig.

		- your /etc/inittab and/or /etc/rc.d/* files have not been
		  customized for the clients.

		- your kernel is missing some crucial compile-time feature
		  (such as NFS filesystem support, booting from the net, trans-
		  name (optional), ELF file support, networking support, driver
		  for your ethernet card).

		- missing init executable (in one of the directories
		  known by the kernel: /etc, /sbin, ?)

		- missing /etc/inittab

		- missing /dev/tty?

		- missing /bin/sh

		- system programs that insist on creating/writing to files
		  outside of /var (mount and /etc/mtab* is the canonical
		  example)



Problem: The netboot kernel supports multicast TFTP transfers, but it doesn't
         use multicasting with my PXE server

	The netboot bootrom supports multicast TFTP using the protocol as speci-
	fied in RFC2090, while PXE servers usually only support the multicast
	extensions as specified by Intel's PXE specification. However, this
	Intel protocol extensions are buggy like hell, which is why they haven't
	been implemented into netboot. You should get an RFC-compliant multi-
	cast TFTP server if you like to use multicast.



Problem: Why does the bootrom not use multicast when downloading the boot
         image

	The bootrom is unable to load a boot file using multicast TFTP trans-
	fers. Only mknbi-mgl can use multicast TFTP. Therefore, you should
	write a small MGL boot image, which then loads the boot image file.
	The MGL program will then use multicasting by default if it's avai-
	lable by the server. This is because it's highly difficult to load
	the tagged boot image file using multicast, and the space is too
	limited in the bootrom to support multicast loading.



Problem: The boot image reports that the bootrom doesn't support "required
         services"

	There was a bug in the netboot version 0.9.x bootrom PXE API which has
	been fixed with version 0.10. Unfortunately, this causes boot images
	produced with any version 0.9.x mknbi program to fail loading with a
	bootrom version 0.10 or newer. Therefore, you have to regenerate all
	boot image files.



Problem: I've downloaded a bootrom code from rom-o-matic, but after the client
         downloaded the boot image, it hangs the system completely.

	rom-o-matic provides bootroms which are incompatible with the current
	netboot boot image standard. Create a new bootrom using makerom.



Problem: Can't compile the bootrom

	Please get in touch with me if you encounter any problems
	while recompiling the bootrom.


Back Back to the last page

Created automatically from source file PROBLEMS by getdoc on Fri Mar 29 05:51:09 UTC 2024