Hello Marty, [Sorry if this appears twice, I had a problem with my mailaccounts!]
I have exactly the same problems as Brian (as posted on etherboot-users), also with the 3c905 (tested 3c905 and 3c90b). In short I have tested all kinds of solutions for burning the rom/flash; bromutils vortex-diag and a regular EPROM programmer, so I'm pretty sure that the ROM are fine. (verified by reading back to file and comparing lzrom image among others. I have some errors coming out vortex-diag (saying there's no ROM installed, and that vortex format checksum is incorrect), but apart from that I begin to suspect that there is a incompatibility of the motherboard (Abit KX333, KT333 chipset, award BIOS). Used 3com util to make sure the ROM is enabled. Booting with ROM gives me nothing, it does not detect the etherboot code. If I enable LAN boot in BIOS, the computer restarts every 10-15 seconds without any messages. I guess "LAN" is when there's a built in ethernet? Yes, I have double checked the PCI ID's. ;-) I post the output of the vortex-diag below again.. If you guys have any hint on what's not happening here .. thanks, Micael ./vortex-diag -e vortex-diag.c:v2.14 12/28/2002 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a 3c905B Cyclone 100baseTx adapter at 0xd000. Station address 00:10:5a:4c:c9:55. Receive mode is 0x07: Normal unicast and all multicast. Saved EEPROM settings of a 3Com Vortex/Boomerang: 3Com Node Address 00:10:5A:4C:C9:55 (used as a unique ID only). OEM Station address 00:10:5A:4C:C9:55 (used as the ethernet address). Device ID 9055, Manufacturer ID 6d50. Manufacture date (MM/DD/YYYY) 9/22/1998, division 6, product QR. No BIOS ROM is present. Transceiver selection: Autonegotiate. Options: force full duplex, link beat required. PCI Subsystem IDs: Vendor 10b7 Device 9055. 100baseTx 10baseT. Vortex format checksum is incorrect (c0 vs. 10b7). Cyclone format checksum is correct (0xa8 vs. 0xa8). Hurricane format checksum is correct (0xa8 vs. 0xa8). Tuesday, July 22, 2003, 4:25:49 PM, you wrote: MC> On Tuesday, July 22, 2003, at 07:29 AM, Brian Delaney wrote: >> ok, I am a newbie with this stuff. >> I am using thinstation to connect to a citrix server using the ica >> protocol. >> This works great with a rom-o-matic floppy disk. I have setup the tftp >> and dhcp server and the thinstation.nbi image works fine. >> I would like some simple plain english help on how to convert from the >> floppy disk to using the rom on the 3c905c NIC. >> I have tried several things and get errors from "file to image to >> large" >> to incorrect file format to nothing happpening once i hit the tftp >> server..... >> any help will be appreciated....thanks MC> Brian, MC> I have collected several methods that may allow you to reach your goal. MC> I think you may not understand the difference between Etherboot and MC> PXE, and may not realize that the code burned into the flash of your MC> NIC is not Etherboot, but some 3Com code that implements various MC> booting methods, such as RPL, TCP/IP and PXE. They call their code MBA MC> (for Managed Boot Agent), and it _implements_ various booting MC> protocols, none of which is Etherboot. MC> You can either replace their code with Etherboot using a flashing MC> utility, use their code directly directly (that is use one of the MC> protocols they support, like PXE), or use their PXE support to load MC> Etherboot, and let Etherboot load your kernel. Any of the three can MC> very probably be made to work. But it will require some understanding MC> in any of the three cases. How much understanding, I cannot say. MC> I will describe several options, and I will put them all in this one MC> message, since this might be of more general usefulness. Someday I'll MC> get around to writing a docbook document that is more accessible, but MC> hopefully this message will help people succeed (and it _can_ be done!) MC> I'll help as I am able, but the strength of Free Software is the MC> strength of the community, of which I am but a single member. So MC> someone(s) will help you, you can be sure. MC> -- Marty MC> P.S. If you're going to reflash your 3Com card, you have to know what MC> the PCI IDs for the card are. If you're using rom-o-matic.net you can MC> go to the menu and (in your case) you probably want a 3c905c-TPO with MC> IDs 0x10b7 and 0x9200. The IDs *must* match the card you want to boot MC> from, or the ROM code will not be run by the BIOS. The Etherboot MC> documentation describes how to find the IDs using the 'lspci' utility MC> (available in a linux distribution near you), or doing 'cat MC> /proc/bus/pci/devices' and looking for the correct 2nd column entry. MC> Booting from floppy is less picky because the BIOS loads whatever is on MC> the floppy, and the 3Com driver can support many cards. The BIOS does MC> some extra checking when loading from ROM space. MC> OK. Here we go. Good luck, and let us know how you eventually get it to MC> work. MC> ========= Door Number 1 ========== MC> - You can reprogram the Flash EEPROM on the 3C905C using cromutil MC> (modified) README file for cromutil, available in the contrib MC> subdirectory of etherboot distributions: MC> This utility was apparently writen by John Finlay and came to me MC> via Richard Schroeder who got it from Greg Beeley. John, if you want MC> to be credited with your full address or whatever in the Etherboot MC> documentation, please contact me (Etherboot maintainer). MC> 1/18/2000 Marty Connor ([EMAIL PROTECTED]) added code for the 3C905C MC> with AT49BV512 Flash memory, and created cromutil and bromutil to MC> differentiate the versions. cromutil is for 3C905C and bromutil is MC> for 3C905B. MC> Be careful. You can easily erase your Flash memory using these MC> utilities. Make *sure* to back them up first using the "read" MC> command. You must "erase" before using "prog" to program the chip with MC> Etherboot code. This code comes with NO WARRANTY, and you take sole MC> responsibility and liability for whatever it does. Read the MC> "romutil.txt" file for more information on commands. MC> That being said, if you are programming a 3C905C-TXM (for example) MC> you would do something like this: MC> First, goto rom-o-matic.net and get a .lzrom file for the 3C905C-TPO MC> and put it somewhere convenient. MC> you might want to name it something easy like: MC> $ mv eb-5.0.10-3c905c-tpo.lzrom 3c905.lzrom MC> or not. MC> Then go untar etherboot and go the contrib directory MC> $ cd etherboot-x.x.x/contrib MC> $ make MC> The key point is that the IO address needs to be entered - Grab it MC> from the dmesg output: MC> 01:0b.0: 3Com PCI 3c905C Tornado at 0xcc00. Vers LK1.1.18-ac MC> 00:01:02:59:03:73, IRQ 10 MC> or "cat /proc/pci" to find the "I/O at XXXXXX" for your 3Com Card. MC> # replace 0xcc00 with whatever the IO Addr for your card is!!!! MC> $ ./cromutil 0xcc00 read > 905cbackup.bin MC> $ ./cromutil 0xcc00 erase MC> $ ./cromutil 0xcc00 prog < 3c90x.lzrom MC> You should now have an Etherboot-enabled 3c905C-TXM. MC> =============== end of Door Number 1 ================== MC> ================ Door Number 1A =============== MC> - You can also reprogram the Flash EEPROM on the 3C905C using Don MC> Becker's ether-diag tools. Here is part of a message Ken forwarded to MC> the list a little while ago (it's for the 3C905B, and it's a bit more MC> advanced, since you have to download ether-diag code and link MC> libraries, but it is a really nice tool): MC> [Reposted from comp.os.linux.networking. Replies to original author MC> whose URL is at the bottom of the page, not me.] MC> (I'm posting this for people to find later with google, since I MC> found precious little on this when I searched) MC> Finally, after dreading building that EPROM burner for months, MC> I succeeded in using Linux and a network card to program a EEPROM. MC> I tried about a year ago to find a cheap source of MC> NIC-programmable EEPROMs, and despite having ATMEL in town, MC> didn't find one. Then, about a week ago, I remembered I had some MC> just laying around: the BIOS chips in my stack of old motherboards! MC> A few minutes of scrounging, and then I had two 32-pin AMI BIOS MC> chips: an ATMEL AT29C010A and an SST 29EE010 (32 pin chips, won't MC> fit in most of my NICs, anybody got a cheap source of 28-pin EEPROMs?) MC> I downloaded and compiled the diag-ether tool from: MC> ftp://www.scyld.com/pub/diag/diag-ether-2.3.tgz MC> After trying to program these EEPROMs via a Linksys LNE100TX and MC> failing, I tried them in my workstation's NIC, a 3Com 3c905B, MC> which has a 32 pin socket. Happily, the EEPROMs were recognized MC> by this card and the vortex-diag utility. MC> One of the first things I learned while using this tool to MC> program the EEPROM, was to first shut down the interface: MC> ifconfig eth0 down MC> before programming the EEPROM (i.e. before using -B, -L or -S) MC> I viewed the EEPROM contents with "vortex-diag -B|less", MC> then saved the original EERPOM contents (in case I needed MC> to use the old motherboard again) with MC> vortex-diag -S filename.bin MC> Next, I went to www.rom-o-matic.com and downloaded a 5.0.8 MC> Etherboot ROM image for my Linksys LNE100TX card (which has MC> a 32 pin socket also). I then wrote the image to the EEPROM: MC> vortex-diag -L eb-5.0.8-centaur-p.lzrom MC> I shut down my box, and moved the programmed EEPROM into the MC> Linksys socket, put that card in a test PC, and booted it. MC> Came right up into booting off the network! I had previously MC> installed LTSP, and have been using floppies to boot my X MC> terminals for awhile. MC> I tried and failed to get bootable EEPROMs with a couple of MC> 3c595-TX cards I had laying around. They may have been too MC> old to be able to read the EEPROMs, or maybe I was using the MC> wrong boot image (although I tried all 3 that were available MC> on romomatic). MC> I did the programming while running the 2.4.20 kernel, on a MC> Mandrake 8.2 PC (haven't got around to upgrading to gentoo MC> yet). This is the NIC I used for programming: MC> Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev MC> 30) MC> Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100 MC> Flags: bus master, medium devsel, latency 32, IRQ 11 MC> I/O ports at ec00 [size=128] MC> Memory at d9000000 (32-bit, non-prefetchable) [size=128] MC> Expansion ROM at <unassigned> [disabled] [size=128K] MC> Capabilities: [dc] Power Management version 1 MC> Class 0200: 10b7:9055 (rev 30) MC> So far, I've only been able to test this with the 128K EEPROMs MC> in the 29XXXXX series, which is a waste since the Etherboot MC> image is only 16K. I really need some 28-pin EEPROMs that MC> are flash-programming compatible with my 3c905b, but I'm MC> not certain if the smaller sizes are compatible, although MC> I assume they are: MC> AT29C256 (32K, 28 pin) MC> AT29C512 (64K, 32 pin) MC> Of course, even if I can find the AT29C256 chips in a DIP MC> form factor, I still don't know if they will work in my MC> generic, cheap RTL8139 NICs...? MC> -- MC> http://www.pcisys.net/~brihall MC> Linux Consultant MC> =============== end of Door Number 1A ================== MC> ================ Door Number 2 =============== MC> - Or, you could use PXELINUX instead of Etherboot to load a kernel MC> with the PXE code that is already on your card. Here is a piece of a MC> message that I wrote recently to help someone to do that: (you can MC> ignore all the USB mouse and keyboard stuff unless you really feel you MC> need it, and obviously the most interesting part is the server part for MC> you): MC> CONFIGURING THE XXXXXX BIOS MC> Go into the BIOS of the XXXXXX by hitting F10 upon power up. MC> On the "Advanced BIOS Features" screen, Enter "Network" for the "First MC> Boot Device" and "Disabled" for the other two. MC> On the "Integrated Peripherals" screen, Enable the Network Controller, MC> USB Controller, USB Keyboard and USB Mouse support. MC> Exit, saving the BIOS settings changes. MC> CONFIGURING THE LTSP SERVER MC> I am assuming your client already has configured an LTSP setup, and MC> only needs to add PXELINUX support for one or more thin clients, so I MC> will refer to directories normally created and existing during LTSP MC> operation. MC> First download the pxestuff package at: MC> http://prdownloads.sourceforge.net/ltsp/pxestuff-3.0.5-i386.tgz?download MC> unpack it into a convenient directory with: MC> tar -zxvf pxestuff-3.0.5-i386.tgz MC> This will create a pxestuff directory. MC> Become root, then move some files around: MC> su MC> cd pxestuff MC> cp bzImage-2.4.19-ltsp-1 initrd-2.4.19-ltsp-1.gz /tftpboot/lts MC> cp pxelinux.0 /tftpboot/lts MC> mkdir /tftpboot/lts/pxelinux.cfg MC> cp pxelinux.cfg/default /tftpboot/lts/pxelinux.cfg/ MC> Edit your /etc/dhcp.conf file to add your XXXXX host (modify this host MC> section for your own particular situation): MC> # XXXXXXXX using PXELINUX MC> host ws136 { MC> hardware ethernet 00:0B:CD:6D:80:67; MC> fixed-address 192.168.2.136; MC> filename "/lts/pxelinux.0"; MC> } MC> Restart your dhcpd daemon with something like: MC> /etc/init.d/dhcpd restart MC> Make sure there is a line in your /etc/hosts file with the IP address MC> for ws136: MC> 192.168.2.136 ws136.in.myveryown.net ws136 MC> You will need to edit your /opt/ltsp/i386/etc/lts.conf file to add some MC> modules for the XXXXX client(s). MC> This is because the XXXXX requires a USB keyboard and mouse, and so the MC> kernel modules for USB must be loaded in order for these devices to be MC> recognized. Here is an example entry for the XXXXX client ws136 MC> mentioned above: MC> [ws136] MC> MODULE_01 = MC> /opt/ltsp/i386/lib/modules/2.4.19-ltsp-1/kernel/drivers/usb/usbcore.o MC> MODULE_02 = MC> /opt/ltsp/i386/lib/modules/2.4.19-ltsp-1/kernel/drivers/usb/uhci.o MC> MODULE_03 = MC> /opt/ltsp/i386/lib/modules/2.4.19-ltsp-1/kernel/drivers/input/input.o MC> MODULE_04 = MC> /opt/ltsp/i386/lib/modules/2.4.19-ltsp-1/kernel/drivers/input/mousedev.o MC> MODULE_05 = MC> /opt/ltsp/i386/lib/modules/2.4.19-ltsp-1/kernel/drivers/usb/usbmouse.o MC> MODULE_06 = MC> /opt/ltsp/i386/lib/modules/2.4.19-ltsp-1/kernel/drivers/input/keybdev.o MC> MODULE_07 = MC> /opt/ltsp/i386/lib/modules/2.4.19-ltsp-1/kernel/drivers/usb/usbkbd.o MC> X_MOUSE_PROTOCOL = "IMPS/2" MC> X_MOUSE_DEVICE = "/dev/input/mice" MC> Restart your thin client, and you should be up and running! MC> ================ End of Door Number 2 ================== MC> Or you could use the PXE->Etherboot chaining method, which uses MC> /etc/dhcpd.conf entries and Etherboot's .lzpxe format to allow a two MC> stage boot. First PXE loads Etherboot, then Etherboot loads the kernel MC> (using whatever Etherboot options you may wish to specify). MC> Here's a message I sent a couple years ago on the subject: MC> ================= Door Number 3 =================== MC> From: Marty Connor <[EMAIL PROTECTED]> MC> Date: Sun Jul 8, 2001 5:54:00 PM US/Eastern MC> To: "Etherboot Users" <[EMAIL PROTECTED]> MC> Cc: "Etherboot Developers" MC> <[EMAIL PROTECTED]>, "LTSP Discussion List" MC> <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> MC> Subject: Adventures with Etherboot, DHCP, PXE, and LTSP MC> Write a driver or play with the PXE stuff... Write a driver or play with MC> the PXE stuff... MC> I was deciding what to do this weekend when in came a message about MC> someone trying to use the Etherboot/PXE feature, so I decided I'd look MC> at MC> that. MC> What follows is a description of that process. MC> Executive Summary: MC> I got it to work. Two PXE cards (a 3COM and an Intel) with PXE built in MC> were able to boot by loading Etherboot and the letting Etherboot do the MC> kernel load. Sweet. MC> If you want to hear the tale, read on. You're probably used to my MC> messages by now ;-) MC> Background: MC> Etherboot and PXE are two pieces of software that allow one to boot a MC> workstation over a network. Some other ways exist like Netboot and RPL. MC> I mostly understand Etherboot because I like to work with Free Software. MC> I've got two pristine, fancy, expensive ethernet cards that I use for MC> testing: MC> - 3COM 3C905C-TXM MC> - Intel EEPRO100+ MC> These cards have flash memory on them, with code that will boot the MC> workstation connected to them. They both have PXE as a boot method. MC> Now, a while back, we in the Etherboot project had developed the MC> technology to reprogram the flash memory on the cards with Etherboot. MC> For the 3COM card, see: MC> http://www.rom-o-matic.net/5.0.2/contrib/3c90xutil/ MC> and for the Intel EEPRO100 see: MC> http://www.rom-o-matic.net/5.0.2/contrib/eepro100notes/ MC> There are also motherboards that have PXE flashed in them, like the MC> ThinkNIC computer. Perhaps someday they will have Etherboot as well. MC> Reflashing cards and BIOSes is not possible sometimes, either for MC> technical reasons, or because people want to be able to the original PXE MC> code. It also requires some work inside the case of the computer, and MC> we MC> don't have tools to reflash all BIOSes. MC> So, to create a way to use PXE cards and BIOSes without reprogramming MC> them, Peter Lister and Vasil Vasilev recently asked the question "Why MC> can't PXE code load Etherboot and let Etherboot take over?". They then MC> wrote the code to make it happen, and so now you can build a ".lzpxe" MC> image and when your PXE ROM or BIOS loads the file, it will actually be MC> starting Etherboot, and you can use your Etherboot environment. MC> Peter and Vasil rock. MC> The Goal: MC> I wanted to boot both cards (3C905C-TXM and EEPRO100) using PXE to load MC> Etherboot, and have Etherboot load the kernel and start it. From there, MC> it is up to LTSP or whatever software is handling the session. Once the MC> kernel loads and starts, Etherboot has done its job. MC> "DHCP for people of reasonable intelligence... MC> who can't read the documentation" ;-) : MC> When PXE and Etherboot start running, they are both looking for the same MC> thing: A DHCP server. They need some information, like their IP MC> address, MC> a name server, the server where they should load a boot file, and the MC> path to that file, and various other things. MC> The thing is, that the DHCP server needs to be able to know if it is PXE MC> asking for information, or if it is Etherboot asking. MC> If it is PXE calling, we should hand it a file name to a ".lzpxe" file, MC> which is an Etherboot image wrapped in a form PXE can load. If however MC> it is Etherboot calling, we want to hand it a ".nbi" or network bootable MC> image, a linux kernel that has been wrapped using mknbi-linux, or a DOS MC> image made with mknbi-dos. mknbi is available for download on the MC> Etherboot download page at: MC> http://etherboot.sourceforge.net/distribution.html MC> Alright, so let's look at the parts we need: MC> - DHCP Server MC> - TFTP Server MC> - PXE Ethernet cards MC> - mknbi package MC> - Tagged kernel (prepared with mknbi-linux) MC> - .lzpxe image (from rom-o-matic.net or made with Etherboot v5.0.2 + MC> Patches) MC> The DHCP Server needs to be able to differentiate between PXE Clients MC> and MC> Etherboot Clients. I want to keep things simple. I want to be able to MC> say: MC> host ws137 { MC> hardware ethernet 00:02:B3:25:45:56; MC> fixed-address 192.168.2.137; MC> if substring (option vendor-class-identifier, 0, 9) = MC> "PXEClient" { MC> filename "/tftpboot/eepro100.lzpxe"; MC> } else if substring (option vendor-class-identifier, 0, 9) = MC> "Etherboot" { MC> filename "/tftpboot/lts/vmlinuz-test.nbi"; MC> option vendor-encapsulated-options MC> 3c:09:45:74:68:65:72:62:6f:6f:74:ff; MC> } MC> } MC> It turns out that ISC DHCPD version 3 MC> (http://www.isc.org/products/DHCP/dhcp-v3.html) can do this. Version 2, MC> which is what I had on my Progeny Debian machine cannot (at least not MC> this way. If someone knows how to do something like this in v2.x, MC> please MC> let us know). MC> So I had to upgrade my DHCPD to v3.0. I downloaded the package from: MC> ftp://ftp.isc.org/isc/dhcp/dhcp-latest.tar.gz MC> I then enabled root privs and moved the file to /usr/src/local and did: MC> mv dhcp-latest.tar.gz dhcp-3.0rc10.tar.gz MC> I then did: MC> tar -zxvf dhcp-3.0rc10.tar.gz MC> to unpack it. This gave me a directory called dhcp-3.0rc10 so I did: MC> cd dhcp-3.0rc10 MC> more README MC> ./configure MC> make MC> make install MC> This gave me new version of /usr/sbin/dhcpd . I then did MC> touch /var/state/dhcp/dhcpd.leases MC> and MC> /etc/init.d/dhcp restart MC> to start up my new DHCP daemon. I checked MC> /var/log/daemon.log MC> to make sure everything was alright with the DHCP startup: MC> Jul 8 15:05:42 ll dhcpd: Internet Software Consortium DHCP Server MC> V3.0rc10 MC> Jul 8 15:05:42 ll dhcpd: Copyright 1995-2001 Internet Software MC> Consortium. MC> Jul 8 15:05:42 ll dhcpd: All rights reserved. MC> Jul 8 15:05:42 ll dhcpd: For info, please visit MC> http://www.isc.org/products/DHCP MC> Jul 8 15:05:42 ll dhcpd: Wrote 0 deleted host decls to leases file. MC> Jul 8 15:05:42 ll dhcpd: Wrote 0 new dynamic host decls to leases file. MC> Jul 8 15:05:42 ll dhcpd: Wrote 0 leases to leases file. MC> Jul 8 15:05:42 ll dhcpd: Listening on MC> LPF/eth0/00:50:ba:77:1d:9f/testingnet MC> Jul 8 15:05:42 ll dhcpd: Sending on MC> LPF/eth0/00:50:ba:77:1d:9f/testingnet MC> Jul 8 15:05:42 ll dhcpd: Sending on Socket/fallback/fallback-net MC> Now I needed a new /etc/dhcpd.conf file. I wanted to make the simplest MC> file I could, and not use all the whizzy new features of v3.0. If I MC> could have used v2.x I would have, but I couldn't figure out how to MC> cleanly do the conditional (the "if" statement) that I wanted to use. MC> So MC> I made a very simple /etc/dhcpd.conf file. Heck, I don't even claim to MC> know very much about DHCP. (why are you reading this? :-) MC> Here is what my /etc/dhcpd.conf file looks like: MC> # Configuration file for ISC dhcpd v3.0 MC> not authoritative; MC> ddns-update-style none; # required for ISC v3.0 MC> shared-network testingnet { MC> subnet 192.168.2.0 netmask 255.255.255.0 { MC> } MC> } MC> group { MC> default-lease-time 21600; MC> max-lease-time 21600; MC> use-host-decl-names on; MC> option domain-name "thinguin.net"; MC> option subnet-mask 255.255.255.0; MC> option broadcast-address 192.168.2.255; MC> option routers 192.168.2.1; MC> option domain-name-servers 192.168.2.56; MC> option log-servers 192.168.2.56; MC> option root-path "/tftpboot/lts/ltsroot"; MC> host ws121 { MC> hardware ethernet 00:80:C6:F8:AB:2A; MC> fixed-address 192.168.2.121; MC> filename "/tftpboot/lts/vmlinuz.all"; MC> } MC> host ws136 { MC> hardware ethernet 00:01:02:c1:79:c7; MC> fixed-address 192.168.2.136; MC> if substring (option vendor-class-identifier, 0, 9) = MC> "PXEClient" { MC> filename MC> "/tftpboot/eb-5.0.2-mc1-3c905c-tpo.lzpxe"; MC> } else if substring (option vendor-class-identifier, 0, 9) = MC> "Etherboot" { MC> filename "/tftpboot/lts/vmlinuz-test.nbi"; MC> option vendor-encapsulated-options MC> 3c:09:45:74:68:65:72:62:6f:6f:74:ff; MC> } MC> } MC> host ws137 { MC> hardware ethernet 00:02:B3:25:45:56; MC> fixed-address 192.168.2.137; MC> if substring (option vendor-class-identifier, 0, 9) = MC> "PXEClient" { MC> filename "/tftpboot/eepro100.lzpxe"; MC> } else if substring (option vendor-class-identifier, 0, 9) = MC> "Etherboot" { MC> filename "/tftpboot/lts/vmlinuz-test.nbi"; MC> option vendor-encapsulated-options MC> 3c:09:45:74:68:65:72:62:6f:6f:74:ff; MC> } MC> } MC> } # group MC> Let's walk through this, a piece at a time. This is all explained in MC> the MC> DHCP documentation, but I'll try to break it down even more for people MC> who can't hack that. MC> # Configuration file for ISC dhcpd v3.0 MC> not authoritative; MC> The "not authoritative;" line is there because I don't want my DHCP MC> server to be giving out information to hosts on my network that it MC> doesn't have information for. Some DHCP clients get confused when a MC> DHCP MC> server NAKs (say NO!). If you're setting up a server to serve Etherboot MC> clients, and you don't want to interfere with another DHCP server, you MC> need to say "not authoritative;" (even with version 2.x of ISC DHCPD). MC> You'll be glad you did. MC> ddns-update-style none; # required for ISC MC> v3.0 MC> This is required for ISC DHCPD v3.0. It has to do with dynamic DNS MC> updates. If you really care, you can read the documentation. ddns lets MC> you tell your DNS server what a host's address is or what host is at an MC> address. Since my hosts have fixed addresses, I don't worry about this. MC> You have to say something, however. MC> shared-network testingnet { MC> subnet 192.168.2.0 netmask 255.255.255.0 { MC> } MC> } MC> This defines the subnet that I'm interested in serving information MC> about. MC> group { MC> The "group" tag just says that I'm going to be talking about some hosts MC> who are related in some way. MC> default-lease-time 21600; MC> max-lease-time 21600; MC> These two lines set some parameters for DHCP leases. MC> use-host-decl-names on; MC> This says to send to the client the name defined by the "host" statement MC> as the host's name. If I didn't include it, I'd have to explicitly put MC> a MC> statement naming each host in its "host" entry. MC> option domain-name "thinguin.net"; MC> option subnet-mask 255.255.255.0; MC> option broadcast-address 192.168.2.255; MC> option routers 192.168.2.1; MC> option domain-name-servers 192.168.2.56; MC> option log-servers 192.168.2.56; MC> option root-path "/tftpboot/lts/ltsroot"; MC> These are pretty self-explanatory, or you can check the DHCPD doc. MC> Now the good stuff: MC> host ws135 { MC> hardware ethernet 00:a0:cc:a0:e6:5b; MC> fixed-address 192.168.2.135; MC> filename "/tftpboot/lts/vmlinuz.all"; MC> } MC> This is for a normal ethernet card. It's a Netgear FA312. It has no MC> PXE, and Etherboot is the only thing that would be asking the DHCP MC> server MC> about it. Since everything else it needs to know has been defined above MC> just under the "group" tag, we just add the three things it needs and MC> away it goes. MC> host ws136 { MC> hardware ethernet 00:01:02:c1:79:c7; MC> fixed-address 192.168.2.136; MC> if substring (option vendor-class-identifier, 0, 9) = MC> "PXEClient" { MC> filename MC> "/tftpboot/eb-5.0.2-mc1-3c905c-tpo.lzpxe"; MC> } else if substring (option vendor-class-identifier, 0, 9) = MC> "Etherboot" { MC> filename "/tftpboot/lts/vmlinuz-test.nbi"; MC> option vendor-encapsulated-options MC> 3c:09:45:74:68:65:72:62:6f:6f:74:ff; MC> } MC> } MC> OK, this is what you've been waiting for. This is for the 3C905C-TXM MC> card. It's like the card above, except that it starts up with PXE. So, MC> what we do is to check to see who is calling from this hardware address MC> (00:01:02:c1:79:c7). You see, when PXE starts up, it sends "PXEClient" MC> in its DHCP message. So if we see that, we send back a file name of MC> "/tftpboot/eb-5.0.2-mc1-3c905c-tpo.lzpxe", which is an Etherboot image MC> that PXE can load. PXE loads it, and it promptly unloads PXE and gives MC> control to Etherboot. (so much of life is bootstrapping, after all :-). MC> Now, Etherboot starts up, and the first thing it does is to send a DHCP MC> request. In this case, the "else if" part of the conditional gets run, MC> and we hand back (among other things): MC> filename "/tftpboot/lts/vmlinuz-test.nbi"; MC> option vendor-encapsulated-options MC> 3c:09:45:74:68:65:72:62:6f:6f:74:ff; MC> The "filename" part is obvious. That's a Linux kernel. The next part: MC> option vendor-encapsulated-options MC> 3c:09:45:74:68:65:72:62:6f:6f:74:ff; MC> is not so obvious. MC> Here's the problem. What if you have two DHCP servers on the network, MC> and you want to make sure that your server is the one that your MC> Etherboot MC> clients choose. How do you guarantee that it will reject replies from MC> the other DHCP server? MC> Well, you first set the option: REQUIRE_VCI_ETHERBOOT when you make your MC> ".lzpxe" image (or Configure it at rom-o-matic.net). This tells MC> Etherboot to ignore any reply that doesn't contain the VCI (vendor class MC> identifier) "Etherboot". Then you add the line: MC> option vendor-encapsulated-options MC> 3c:09:45:74:68:65:72:62:6f:6f:74:ff; MC> to your "host" entry. This says "send the VCI 'Etherboot' back to the MC> requesting client". So now you can be pretty sure your client will be MC> talking to the right DHCP server. MC> Put it all together and you get: MC> host ws136 { MC> hardware ethernet 00:01:02:c1:79:c7; MC> fixed-address 192.168.2.136; MC> if substring (option vendor-class-identifier, 0, 9) = MC> "PXEClient" { MC> filename MC> "/tftpboot/eb-5.0.2-mc1-3c905c-tpo.lzpxe"; MC> } else if substring (option vendor-class-identifier, 0, 9) = MC> "Etherboot" { MC> filename "/tftpboot/lts/vmlinuz-test.nbi"; MC> option vendor-encapsulated-options MC> 3c:09:45:74:68:65:72:62:6f:6f:74:ff; MC> } MC> } MC> Smoke test: MC> I put in the 3COM card, set it to do PXE. Did "/etc/init.d/dhcp MC> restart" MC> to restart my DHCPD. and rebooted my workstation. MC> Here's what I get [fake screen shot, yes i typed it all in by hand]: MC> Managed PC Boot Agent (MBA) v4.00 MC> (C) Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com MC> Corporation MC> All rights reserved. MC> Pre-boot eXecution Environment (PXE) v2.00 MC> (C) Copyright 1999 Intel Corporation. MC> (C) Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com MC> Corporation MC> All rights reserved. MC> DHCP MAC ADDR: 00 01 02 C1 79 C7 MC> DHCP.... MC> CLIENT IP: 192.168.2.136 MASK: 255.255.255.0 DHCP IP: 192.168.2.56 MC> GATEWAY IP: 192.168.2.1 MC> PXE loader for etherboot(with ZLOADER) MC> PXENV+ unloaded MC> ROM segment 0x07C0 length 0x3000 reloc 0x9400 MC> Etherboot 5.0.2 (GPL) Tagged ELF for [3C90X] MC> Boot from (N)etwork or from (L)ocal? N MC> Found 3Com905C-TXM at 0xDC00, ROM address 0xE300 MC> Probing...[3C90X] MC> 3C90X Driver 2.00 Copyright 1999 LightSys Technology Services, Inc. MC> Portions Copyright 1999 Steve Smith MC> Provided with ABSOLUTELY NO WARRANTY. MC> ------------------------------------------------------------------------ MC> --- MC> ------- MC> MAC Address - 00:01:02:C1:79:C7 MC> Connectors present: 10Base-T / 100Base-TX. MC> Searching for server (DHCP)... MC> Me: 192.168.2.136, Server: 192.168.2.56, Gateway 192.168.2.1 MC> Loading 192.168.2.56:/tftpboot/lts/vmlinuz-test.nbi (NBI)... done MC> Linux Net Boot Image Loader Version 0.8.1 (netboot) MC> Copyright (C) 1996,1997 G. Kuhlmann and M. Gutschke MC> Copyright (C) 1995-1998 G. Kuhlmann MC> Not enough memory MC> <abort> MC> Hmmmmmm, now what could be going on here. We were doing so well. PXE MC> had started, loaded Etherboot. Etherboot had taken over. Etherboot had MC> loaded the kernel. And failed to execute. MC> Whoa. It looks like we've got a tagged-image that was tagged with an MC> old MC> version of mknbi-linux. It's a tagged-kernel I got from the LTSP site. MC> Under normal circumstances Etherboot doesn't seem to care, but MC> apparently MC> after PXE has been in memory life is more complicated... MC> What would happen if I took a kernel and tagged it with mknbi-1.2? MC> This: MC> Searching for server (DHCP)... MC> Me: 192.168.2.136, Server: 192.168.2.56, Gateway 192.168.2.1 MC> Loading 192.168.2.56:/tftpboot/lts/vmlinuz-test.nbi (NBI)... done MC> mknbi-1.2-2/first32.c (GPL) MC> 129792k total memory MC> Uncompressing Linux... Ok, booting the kernel MC> Linux version 2.2.19 ([EMAIL PROTECTED]) (gcc version 2.95.2 20000220 MC> (Debian GNU/Linux)) #1 Thu Apr 5 15:18:02 EST 2001 MC> BIOS-provided physical RAM map: MC> BIOS-e820: 00090000 @ 00000000 (usable) MC> BIOS-e820: 07dc0000 @ 00100000 (usable) MC> Detected 564845 kHz processor. MC> Console: colour VGA+ 80x25 MC> Calibrating delay loop... 1127.21 BogoMIPS MC> Memory: 126600k/129792k available (1124 kernel code, 472k reserved, MC> 1524k MC> data, 72k init) MC> ........ MC> Sweet. The Intel EEPRO100+ card worked similarly, which means their PXE MC> implementation of PXE seems compatible. I hope some other people will MC> try this and let us know how it works for them. The DHCP server and the MC> mknbi-1.2 requirement seem to be the only tricky parts. Maybe someone MC> will come up with a clever way to do this in v2 of the DHCP server. MC> So there's one way to use PXE to load Etherboot. I hope this helps some MC> people who want to try this. Maybe we should put this message in the MC> contrib directory for people who need some help getting started with MC> this, or maybe we can work it into the documentation for Etherboot. MC> Marty MC> =================== End of Door Number 3 =================== MC> So there you go. Hopefully, this will help you get going. It may also MC> help others help you. MC> Someday I'll get around to writing it down more coherently, but for MC> now, this is what I can do. MC> Marty -- Best regards, Micael mailto:[EMAIL PROTECTED] ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
