> On Tue, 9 Jul 2002, Jason Bechtel said: >> As I said, "with otherwise proven software". I take it >> Sophos is a precompiled binary. In that case, sure. Your >> underlying system libraries could have an effect, >> especially the way Red Hat likes to play with versions of >> glibc... But in this case it was about the LTSP >> distributed binaries running on an LTSP client. The system > > That's the part I wasn't sure about. Actually, I was thinking that the DC > perhaps was getting the dhclient binary which resides on the server and > executing it from within the LTSP environment, which uses a different set > of libraries than those which the binary was compiled under. I wasn't > questioning the internal consistencies of LTSP.
The client should be getting its dhclient binary from the appropriate NFS-root share from the LTSP server (/opt/ltsp/<arch>/, where <arch> is [i386|PPC|Sparc|...]). If it were getting it from the LTSP server's host OS, then you wouldn't be able to network book other architectures using DHCP. Now, I'm not a DHCP hacker, but I would *think* that DHCP isn't limited to the i386 architecture and that the network-layer services provided are ignorant of the underlying hardware. I guess DHCPD could supply binaries for a bunch of known architectures and ask the client which one it is and then send it the right one, but I can't imagine that this is how DHCP works. I thought that the Etherboot code did the first call to DHCP, obtaining the network info along with the path for the TFTP download of the kernel. The kernel itself then makes the next call to DHCP to determine its network info (which isn't passed along when the kernel is network-booted by Etherboot). To do this, the kernel has to be compiled with the necessary options. Therefore, I would conclude that the dhclient code is part of the kernel (probably in the initrd) and was compiled with the kernel for a particular architecture. > It does indeed seem to be hardware related, but as far as I can tell, the > mobo (ASUS P5A) is to blame. I've swapped the entire client machine (with > the same mobo) as well as the hub and patch cables with the same problem. > Due to the intermittent nature it's difficult to say with real certainty, > but the problem appears to occur only when the P5A has an AGP card > installed. I tried two different AGP cards - a generic card employing a > Trident Blade3D chip, and an ATI Rage Pro. The problem disappears when I > replace the AGP card with an ISA video card. Interesting. Thanks for the update on that. I was a computer tech for a while in college at a local shop. I recall with frustration the hard-to-pin-down hardware conflicts. This is the only downside to the PC architecture. Even with standards out the wazoo, these companies manage to make parts that don't work with certain other parts... But then I ask myself if I could spend $2,500 on an Apple system (to run Linux/PPC, of course) and I have to say that the commodity pricing keeps me coming back. Sigh... > I am declaring the test a success though, because I won't be using the > ASUS P5A machines as clients for the main part of the project. Although > it's still disappointing because I do have a few of the P5A which I was > thinking I could use as DC's later on. If it really is just a conflict with the AGP slot, you could still try a decent PCI graphics board. They sometimes cost more, but ISA is in its twilight years... Jason ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf _____________________________________________________________________ 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.openprojects.net
