> Message: 4 > Date: Tue, 30 Nov 2010 13:11:49 -0500 > From: "John Stoffel" <[email protected]> > Subject: Re: [lopsa-tech] Issues with PXE boot on VMware with dhcpd > To: Matt Simmons <[email protected]> > Cc: LOPSA Technical Discussions <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > Matt, > > I wonder if the network is part of the issue? I've got a kickstart > server setup which consists of a Cisco 4507 in the core, with various > DELL PowerConnect 5[23]24 switches hooked up. If I try to kickstart a > system not on the same switch as the kickstart server, it fails. > > I'm not at work today to run some tests, but I'm certain it's an issue > with PortFast or SpanningTree or something like that. It hasn't been > enough of a hassle for me to want to try and poke at my network and > break things. > > So maybe you need to just investigate the network setup a little? > > John > > -- >
I've been burned by that one a couple of times. I've had both Portfast and AutoSpeed/AutoDuplex issues that I resolved by force... Force the speed and duplex for kickstart on the old DELL's I was using with Intel 100BaseTX cards. Force the Cisco switches. If I couldn't get the force working af 100/full resort to 100/Half duplex for the kickstart. The kickstart would set the correct full duplex at the post install and I'd reset the switch then. The gigabit is much more forgiving since they got it worked out right. The etherboot floppy disks didn't IIRC give me any way to force the speed/duplex. But it at least let me remote boot and kickstart the boxes. Bill > > ------------------------------ > > Message: 7 > Date: Tue, 30 Nov 2010 13:55:06 -0500 > From: Matt Simmons <[email protected]> > Subject: Re: [lopsa-tech] Issues with PXE boot on VMware with dhcpd > To: LOPSA Technical Discussions <[email protected]> > Message-ID: > > <[email protected]<aanlktintdra%2brkkyctg7ro-jy9m%[email protected]> > > > Content-Type: text/plain; charset=UTF-8 > > Hi everyone, > > Thanks very much for all of the advice. I've made a significant step > forward in figuring out what the heck is going on, but I still don't > know why. > > Despite the fact that I'm using identical versions of ISC dhcpd (down > to the md5 checksum of the binary) and identical configurations, the > difference is that the misbehaving server is NOT setting the > "next-server" and "boot file name" flags in the DHCP OFFER packet. > > Fortunately, this narrows down the possibilities quite a bit. It is > absolutely a problem with that particular machine and/or the software > on it, not in the network or on the client machine. > > I am currently trying to narrow down what the differences are between > those machines. Here's what they have in common: > > Identically configured and installed CentOS 5.5 virtual machines being > hosted on identically configured ESXi hosts (version 4.1.0, 260247). > Fully updated with the CentOS repositories > Identical configuration files, with only the network and MAC addresses > changed to reflect the different sites > > I have already removed and reinstalled the dhcp package, however I am > in the middle of building another VM to perform the same services. If > this works, I will assume that the original problem was due to solar > flares reflecting from the swamp gas on Venus. Assuming it doesn't > work, I'm going to be copying the VM image from the site that works > and trying it with the other netblocks. If that works, I may cry. If > it doesn't, I suppose the only thing left is to dive into the source > RPMs for dhcpd and figure out where the bug lies. I sincerely hope > that I don't have to get anywhere near that far in. > > Thanks again, everyone. I really appreciate all of the help and > suggestions. It's always great to get new ways to look at a problem. > > --Matt > -- > LITTLE GIRL: But which cookie will you eat FIRST? > COOKIE MONSTER: Me think you have misconception of cookie-eating process. > > Let me propose a check for one thing. I actually once had a ghost DHCP server on another box with similar configs that was putting out responses... No matter what I did it didn't change. There was this engineer who set up this one test box in the lab years ago... Right now the kickstarts for my VM's are coming from a RedHat kickstart VM box in my virtual infrastructure since I had no control over the network to modify the dhcp/pxe/dns at the time. There's a vswitch with a 10.0.0.0/255.0.0.0 subnet totally disconnected that I kickstart on and then migrate the VM's to the correct vswitch. Of course, once I got this all established I was given the job of admin on all that as well. You may want to try to virtualize the dhcp/dns/kickstart on one box and kickstart all the VMs there. It worked out well here. The kickstart here is kind of unusual. It is generated by my coworker's kickme cgi that concatenates different pre/post install segments along with the different standard disk layouts we use so we can build different configurations based on standardized configs without the manual editing step. Pre and post install are separate text scriptlets as is the network information and disk partitioning. The perl cgi does some variable substitution (IP, hostname, etc) and concatenates and sends back a unified kickstart. Good luck. I hope you have an easier time finding yours than I did tracking down that dhcpd running in the corner. -- Bill -- d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now! pechter-at-gmail.com
_______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
