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 email@example.com 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 firstname.lastname@example.org (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 to the last page
Created automatically from source file PROBLEMS by getdoc on Wed Apr 26 04:08:21 UTC 2017