Can I draw your attention to a similar project that uses PXE pretty much exclusively and is less complex.
pxes.sourceforge.net It all depends on your particular client equipment on which project is best for your needs. PXES is particually good if connecting to MS Terminal Services. >> 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 Regards, Neil Hiorns ------------------------------------------------------- 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
