> Nonetheless, the idea of using PXE to boot EtherBoot and from there to boot > Linux is certainly ingenious, and evidently works well in in a Linux > environment. However, it has some drawbacks, even in this environment.
Well, thanks for saying it's ingenious - I can authoritatively assure you that it isn't (I submitted the original patch, so I can say this), although it is certainly useful. The first drawback is not a feature of Etherboot per se, and the second is being actively fixed. > First I find the need for a conditional in the dhcpd.conf to figure out > which phase of booting is underway to be somewhat cumbersome, even if there > was a Windows client out there to handle it. Cumbersome? Complexity and simplicity are largely in the eye of the beholder... see below. Actually, I agree that ISC's config language is not that great, but I don't think that's what you are saying. I don't understand why a Windows client affects you, but if you are constrained to use a Windows server, then you may have a problem. It is actually quite easy to use the ISC DHCP server on a Unix box and peacefully coexist with a Windows DHCP server (perfectly good legal use of DHCP, not a "hack") but many sites do have over-paranoid policies which may prevent this. > Second, and this is my real objection, it is necessary to maintain an > Etherboot image for each client NIC type, and figure out at boot time which > one to download. Although quite straightforward, this presents a maintenance > nightmare. Agreed, this is the biggest drawback just now, but not in the long term; the latest Etherboot now allows images with multiple drivers (all of them, if you want). This makes for a fairly large Etherboot image, but if we are pulling it via tftp that's no problem. Etherboot may also shortly use the PXE UNDI driver directly (though, as I note below, this may NOT be an "ideal" solution). Either way, one should be able to get an image which suits the vast majority of cases. > The solution I have adopted, and which, so far, works extremely well, is to > leave dhcpd.conf alone for my EtherBoot clients, so that they boot the > tagged bzImage as built by the LTSP initrd buildk, as before. > The PXE clients (identified by their MAC to be in a different dchpd group) > initially boot pxelinux (http://syslinux.zytor.com/), which then loads the > bzImage and the gzipped initrd. Hm. And you regard this is *less* cumbersome then a conditional in dhcp.conf? You have two configs in parallel; you just moved some of the stuff into a TFTP config file. I'd argue that it is *much* neater to keep the Etherboot config and the kernel images the same for all clients (this, after all, is the config which affects Linux) and just add an extra note for PXE clients to pull themselves an Etherboot image. So... definitely in the eye of the beholder. > The big advantage of this is that it uses the client's BIOS to drive > the network card, so there's no faffing about with drivers. > Subjectively, it also seems to boot faster. Unfortunately, the big *disadvantage* of this is that it uses the client's BIOS to drive the network card. :) Much of the traffic on the syslinux mail list and HPA's web site is devoted to the shortcomings of BIOSen in general and PXE implementations in particular (which are usually derived from Intel's closed source library inherit its characteristic bugs). If you idealistically think that hardware vendors are the best people to write firmware, think again. I haven't met anyone with significant experience of PXE who doesn't regard design or implementation (usually both) as seriously flawed. Don't misunderstand me, PXE is undoubtedly convenient in simple environments (e.g. one nic in the machine) if everything works out of the packet. Conceptually, it's a great idea. It's also a completely unfixable nightmare in circumstances where the default behaviour, design flaws and implementations let one down, and that tends to happen fairly quickly once any circumstance out of the ordinary happens. I promise you that your mobo / nic vendor will not be interested in your problems unless you are about to order 10,000 units. But it's not all gloom - adding some of the PXE API to Etherboot (i.e. so that PXE code runs on top of Etherboot, not vice versa) is being seriously discussed. This would keep everyone happy - with one lump of firmware the PXE fans would get a reliable, fixable PXE implementation and the Etherboot fans would get to just ignore PXE. > FWIW, I would recommend adding an alternative pxe-howto on the ltsp.org > documentation site to use this method, to supplement the cumbersome > PXE/EtherBoot/Linux route. I'll write it if there's interest in me doing so. *I* don't think it's cumbersome. :) That howto was written by Marty connor based on my email describing use of the Etherboot via PXE written by my colleague Vasil Vasilev here at Sychron, and believe me we wouldn't have bothered if we didn't think it was worth doing. By all means add your input - I wouldn't dreaming of trying to stop you and can't anyway - but please at least concede that *you* finding it cumbersome doesn't mean that everyone else does. It's human nature to assume that the solution which works for oneself must be "correct" for everyone else, but this usually means one hasn't met the big problems yet. I've been intending to write a PXE howto for some time with the express intention of presenting the main alternatives. Maybe we can collaborate and do a better job. I'll happily explain my point of view offlist or by phone - we're a bit off topic for LTSP now. Given that we are geographically close (I'm in central Oxford), how about meeting IRL? ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _____________________________________________________________________ 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
