Hello Tony, Wednesday, January 29, 2003, 1:48:43 PM CET, you wrote:
TvdH> OK, just to close this issue, and to express my thanks to all contributors: Some more comments. "SCNR"... [...] TvdH> In fact, those two options are substantially identical. Using PXE directly TvdH> doesn't really seem to be supported. That's AFAIK 'related' to the fact that PXE imposes limitation on the maximal file size to be downloaded, which was to small to fit initrd and kernel into it. TvdH> Something I didn't mention in my original post (because it's - well - TvdH> embarrassing ;-) is that I haven't been able to pursuade the customer to go TvdH> for a Linux DHCP server. So it's an NT box. I have an adequate shareware TvdH> Windows DHCP server, but it doesn't have the nice features of the latest TvdH> linux dhcp daemon; in particular no conditionals, which rather stymies the TvdH> idea of booting via EtherBoot. A feature of Etherboot lets you use the "very fine"(TM) scripting facilities of dhcpd anyhow. It's that REQUIRE-VCI. TvdH> Nonetheless, the idea of using PXE to boot EtherBoot and from there to boot TvdH> Linux is certainly ingenious, and evidently works well in in a Linux TvdH> environment. However, it has some drawbacks, even in this environment. TvdH> First I find the need for a conditional in the dhcpd.conf to figure out TvdH> which phase of booting is underway to be somewhat cumbersome, even if there TvdH> was a Windows client out there to handle it. Mkay, but it could be as simple as two lines switching the filename, every next option couuld be in host-statements as you wish. TvdH> Second, and this is my real objection, it is necessary to maintain an TvdH> Etherboot image for each client NIC type, and figure out at boot time which TvdH> one to download. Although quite straightforward, this presents a maintenance TvdH> nightmare. This should prove to be untrue. I did not test it, but the developers claim etherboot to have the power to support several NIC types in a single image, at least for the newest etherboot versions. It probably has not reached rom-o-matic.net yet, but you could get the tar.gz's and try it out yourself. Eventually you could ask for help on the etherboot-users list. TvdH> The solution I have adopted, and which, so far, works extremely well, is to TvdH> leave dhcpd.conf alone for my EtherBoot clients, so that they boot the TvdH> tagged bzImage as built by the LTSP initrd buildk, as before. My solution against that admin nightmare would be to have a multi-NIC-etherboot. Should solve the problem alltogether: In case some new NICs enter the place, worst case you had to get a new .lzpxe with more NICs supported inside. TvdH> The PXE clients (identified by their MAC to be in a different dchpd group) TvdH> initially boot pxelinux (http://syslinux.zytor.com/), which then loads the TvdH> bzImage and the gzipped initrd. The big advantage of this is that it uses TvdH> the client's BIOS to drive the network card, so there's no faffing about TvdH> with drivers. Subjectively, it also seems to boot faster. Probably one fewer DHCP query. Could save time depending on the speed of dhcp system. TvdH> FWIW, I would recommend adding an alternative pxe-howto on the ltsp.org TvdH> documentation site to use this method, to supplement the cumbersome TvdH> PXE/EtherBoot/Linux route. I'll write it if there's interest in me doing so. Although I might seem to hate your procedure (which is not the case, I just try to outline that the current solution should work too) I would be interested to read about that solution. TvdH> Cheers, Tony Best regards, Anselm mailto:[EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
