When I run vortex-diag -e I get the message: A BIOS ROM of size 0Kx8 is expected
This is after I ran vortex-diag -L 3c905c.lxrom Brian Micael Beronius wrote: > Hello Marty, > > 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 message, including any attachments, is intended solely for the use of the named recipient(s) and may contain confidential and/or priveleged information. Any unauthorized review, use, disclosure or distribution of this communication(s) is expressly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy any and all copies of the original message. ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _____________________________________________________________________ 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
