Hello! I have been successful using SYSLINUX and Etherboot to create a generic "PXE-on-a-disk" package, a floppy image and CD image that support as many Ethernet cards as possible. These have support for all of Etherboot's modules that support real PCI cards: about 25-or-so drivers and 250-or-so cards. I've built Etherboot ZLILO images, one for each driver, set up to boot as a PXE stack. I've used "ethersel.c32" to choose the correct image for each detected PCI card, and it seems to work. I made a fairly straightforward Perl script to take Etherboot's internal PCI device table and munge that into a fairly large SYSLINUX config file that is scanned by ethersel. I've tested it on a fair variety of different hardware and it works! It auto-detects the correct driver to load, without user interaction, and behaves just as a PXE BIOS would. A limitation is that it will only work with the "first" card detected by ethersel. In a situation where 2 PCI cards are installed, both from different drivers (for example, one 3com and one Intel), only one of them will work. I was pleased to see that Etherboot can work with multiple copies of the same card, though, trying each in a round-robin fashion. I'd love it if the Etherboot module could somehow "return" to SYSLINUX, instead of rebooting the entire machine or trying forever in a loop, if there is a problem/timeout. Then, ethersel could have the chance of detecting another PCI card in the system, and continue trying with that. Then, it would work even in systems with multiple PCI cards from different vendors. However, that's an Etherboot question, not a SYSLINUX question, so I won't continue with it here. I use PXELINUX as my bootloader (of course), and have my TFTP and DHCP server set up and working correctly to serve it, and a Linux kernel/initrd. The flow of control: Boot --> SYSLINUX (or ISOLINUX if CD) --> ethersel (detect PCI card and choose Etherboot kernel) --> Back to SYSLINUX (load and run Etherboot kernel) --> Etherboot (PXE stack, download of PXELINUX) --> PXELINUX (downloaded from server and ran, downloads Linux kernel) --> Linux Kind of convoluted, but it works nicely! My main problem is on the Intel EM64T (Intel's clone of AMD's 64-bit x86 architecture). Right after SYSLINUX prints the final "Ready." line, it reboots! I see the kernel and initrd downloaded correctly by TFTP. There were no errors. However, instead of getting the normal kernel startup text after SYSLINUX's final "Ready." line, I get an immediate reboot! Yes, I'm downloading an Intel EM64T kernel, not an AMD64 kernel. Yes, the kernel boots fine when loaded from other means (local hard disk, for instance). For testing, I tried enabling the motherboard's on-board PXE BIOS for booting, and it worked. So, the problem seems to be in some difference between my Etherboot-created software PXE stack, and the BIOS's real PXE stack. Are there any known issues with the final handoff phase from SYSLINUX/Etherboot/PXELINUX to the kernel, on Intel EM64T machines? Anything I can do to help troubleshoot this? At first, I had a feeling it has something to do with freeing the PXE stack in memory (from Etherboot), but since it works on other AMD64 machines and all 32-bit machines I have found, I don't think this would be the problem. I'll post this to the Etherboot list as well, but thought I'd also mention it here, in hopes that someone else has seen this before (since a universal "PXE-on-a-disk" boot floppy/CD image is quite useful, and seems to be the killer app for Etherboot these days). Josh
Hi Josh: There is a similar one in http://sourceforge.net/project/shownotes.php?release_id=190646 http://sourceforge.net/project/showfiles.php?group_id=80408 I tried it compiled it in etherboot 5.4.0 and 5.4.1, and it works. Could you please tell me what's the difference between yours and that one ? Thanks in advance. ---------------------------------- Steven Shiau E-mail: steven _at_ nchc.org.tw; steven _at_ stick.idv.tw
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Dec 02, 2005 at 01:07:11PM -0800, Josh Lehan wrote:> Hello! I have been successful using SYSLINUX and Etherboot to create a > generic "PXE-on-a-disk" package, a floppy image and CD image that > support as many Ethernet cards as possible. > > These have support for all of Etherboot's modules that support real PCI > cards: about 25-or-so drivers and 250-or-so cards. I've built Etherboot > ZLILO images, one for each driver, set up to boot as a PXE stack. I've > used "ethersel.c32" to choose the correct image for each detected PCI > card, and it seems to work.Sounds like http://etherboot.anadex.de/> I made a fairly straightforward Perl script to take Etherboot's internal > PCI device table and munge that into a fairly large SYSLINUX config file > that is scanned by ethersel. I've tested it on a fair variety of > different hardware and it works! It auto-detects the correct driver to > load, without user interaction, and behaves just as a PXE BIOS would.Please tell more about it or even better: document it on a webpage.> A limitation is that it will only work with the "first" card detected by > ethersel. In a situation where 2 PCI cards are installed, both from > different drivers (for example, one 3com and one Intel), only one of > them will work. I was pleased to see that Etherboot can work with > multiple copies of the same card, though, trying each in a round-robin > fashion. > > I'd love it if the Etherboot module could somehow "return" to SYSLINUX, > instead of rebooting the entire machine or trying forever in a loop, if > there is a problem/timeout. Then, ethersel could have the chance of > detecting another PCI card in the system, and continue trying with that. > Then, it would work even in systems with multiple PCI cards from > different vendors. However, that's an Etherboot question, not a > SYSLINUX question, so I won't continue with it here.But where will it be continued? (did I mis a posting? ( here or at the etherboot mailinglists ))> I use PXELINUX as my bootloader (of course), and have my TFTP and DHCP > server set up and working correctly to serve it, and a Linux kernel/initrd. > > The flow of control: > > Boot > --> SYSLINUX (or ISOLINUX if CD) > --> ethersel (detect PCI card and choose Etherboot kernel) > --> Back to SYSLINUX (load and run Etherboot kernel) > --> Etherboot (PXE stack, download of PXELINUX) > --> PXELINUX (downloaded from server and ran, downloads Linux kernel) > --> Linux > > Kind of convoluted, but it works nicely! > > My main problem is on the Intel EM64T (Intel's clone of AMD's 64-bit x86 > architecture). > > Right after SYSLINUX prints the final "Ready." line, it reboots!Mmm ....> I see the kernel and initrd downloaded correctly by TFTP. There were no > errors. However, instead of getting the normal kernel startup text > after SYSLINUX's final "Ready." line, I get an immediate reboot! > > Yes, I'm downloading an Intel EM64T kernel, not an AMD64 kernel. > > Yes, the kernel boots fine when loaded from other means (local hard > disk, for instance). For testing, I tried enabling the motherboard's > on-board PXE BIOS for booting, and it worked. So, the problem seems to > be in some difference between my Etherboot-created software PXE stack, > and the BIOS's real PXE stack. > > Are there any known issues with the final handoff phase from > SYSLINUX/Etherboot/PXELINUX to the kernel, on Intel EM64T machines?You could be the first in that area. ( in other words: I haven't seen reports of Intel EM64T with syslinux (no success, neither failures) )> Anything I can do to help troubleshoot this? At first, I had a feeling > it has something to do with freeing the PXE stack in memory (from > Etherboot), but since it works on other AMD64 machines and all 32-bit > machines I have found, I don't think this would be the problem.I think it is kernel start code for the EM64T that differs too from AMD64 and plain i386.> I'll post this to the Etherboot list as well, but thought I'd also > mention it here, in hopes that someone else has seen this before (since > a universal "PXE-on-a-disk" boot floppy/CD image is quite useful, and > seems to be the killer app for Etherboot these days).I also think it is a killer application, so please do that posting.> JoshGSt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDnDXFOSINbgwa/7sRAnd0AKCTydNJkBK4M2q76/w4+IXSQJ5OlACgltcf OERdMhzqRA7P+CbXSOnR32Y=jLYx -----END PGP SIGNATURE-----
Paolo Salvan wrote:> Hi all! > > ...As I'm the author of > http://sourceforge.net/project/shownotes.php?release_id=190646 > http://sourceforge.net/project/showfiles.php?group_id=80408 > (for Steven: these two links are for the SAME file...)Nice! I didn't know these were the same file, as Sourceforge presented the two pages very differently. So, there are only 3 "PXE-on-a-disk" projects known so far, not 4.> My approach is more minimalistic: etherboot have already the > capabilities to build a multi-drive boot image, and can autodetect the > correct driver to start (using the PCI-ID, but it also try the ISA > drivers in sequence if no PCI NIC is found...), so I simply built anI'd love something like that for ethersel.c, perhaps a "None Of The Above" option. Right now, it either detects the PCI card, or fails to boot. Is there a way to designate a fallback command line that ethersel will follow, in the event of detection failing for every PCI device? That's a good idea that I also wanted to try: building a driver with as many old ISA drivers as possible, if PCI autodetection fails to find a supported PCI card.> very pubblicized)... the only drawback I know of my approach is that I > knocked against an etherboot memory limitation: the multi-driver is > compressed, and when it is uncompressed, it is temporaily kept in > low-memory (the dear old 640Kb limitation...), and so for some built I > have to exlude 1 or 2 rarely used big drivers to get it fit in memory... > but it seems that in the future etherboot versions this limit will be > overcomed...Good job, you got farther than I did. I ran into the 64K segment size limitation of 16-bit code, and couldn't link anything totaling more than 64K, let alone 640K, so could only build a handful of drivers at a time. This was with Etherboot several months ago, though, maybe the 64K linker bug has been fixed since then. Sounds like Etherboot is running into the same problem the Linux kernel did a few years ago: not being able to fit its entire image into the low 640K during initial booting... will this be fixed? My guess is no, since the original design goal of Etherboot was to be able to fit on physical ROM sockets in NIC cards, and so there's probably many people that want it to remain lean and mean, and not become "Etherbloat" :) Building a larger Etherboot with multiple drivers might be better than my approach of building many small Etherboots, one for each driver. The reason is for systems with multiple different NIC cards installed. Only one of them will be detected and work, because of the Etherboot that is chosen by ethersel. The other card(s) will lie dormant. To my knowledge, the standard PC chain-boot technique offers no way to "return" from Etherboot back into SYSLINUX, allowing ethersel.c to try a different card. So, by building a few large Etherboot kernels instead of many small ones, we at least have the chance of working with a group of drivers, instead of only one driver. Josh Lehan jlehan at scyld.com