On Wed, 19 Nov 2003, Zate wrote: >#1 - tg3/bcm5700 drivers > >I am using Compaq hardware for kickstarting Advanced Server 2.1 and when >the boxes come up, they are not bringing up eth0(which I provide all the >ip information for) because its not loading the tg3 driver module. In my >/etc/modules.conf it has bcm5700 which is the wrong driver to use, it >should be tg3. Suggest you look through the archives of linux-poweredge to make sure this assumption is correct. tg3 went through hell in the last year, but AIUI the current kernels from Redhat have it fixed. http://lists.us.dell.com/pipermail/linux-poweredge/ >How can I tell the install to use tg3 for the driver ? Either find the equivalent of /usr/share/hwdata/pcitable which anaconda uses, or just rewrite /etc/modules.conf in a %post script. %post perl -pi -e 's/bcm5700/tg3/' /etc/modules.conf >#2 - PXE Server > >We have a rather large data center, with lots of VLANs set up for various >servers. Internal VLANS, 3 Tier hosting network VLANS, etc etc. What is >the best way to get PXE working in this environment ? [snipped] A better question might be: what are the tradeoffs/complications to having PXE work in-situ versus isolated? For an isolated environment, i.e. where you hook up the kickstart server and "client" to the same switch but nothing else, the server has to provide all resources (some of DHCP, TFTP, DNS, HTTP, NFS, rdate, NTP) and cannot leverage your existing infrastructure. For an in-situ PXE kickstart, sometimes the existing infrastructure gets in the way, e.g. you don't have sufficient access or are unwilling to change the DHCP setup. The "happy" medium, as you suggest, can be to use a spare network port to perform the kickstart in-situ. This usually gets you the best of both worlds, but care must be taken to specify the correct "eth0, eth1" in all places. Tricky, but not impossible. Hope that helps, Phil
