[CentOS] CentOS 6 and pxeboot

Tue Apr 11 21:01:56 UTC 2017
Bruce Ferrell <bferrell at baywinds.org>

On 04/11/2017 01:33 PM, m.roth at 5-cent.us wrote:
> Pete Biggs wrote:
>>>     We've been using pxeboot to pull up a menu, to build or rebuild
>>> machines for years. We have this new server, and it fails. Times out.
>>> What's happening is that it tries in this order
>>>          .../pxelinux.cfg/b8945908-d6a6-41a9-611d-74a6ab80b83d
>>>   	.../pxelinux.cfg/01-88-99-aa-bb-cc-dd
>>>   	.../pxelinux.cfg/C0A8025B
>>>   	.../pxelinux.cfg/C0A8025
>>>   	.../pxelinux.cfg/C0A802
>>>   	.../pxelinux.cfg/C0A80
>>>   	.../pxelinux.cfg/C0A8
>>>   	.../pxelinux.cfg/C0A
>>>   	.../pxelinux.cfg/C0
>>>   	.../pxelinux.cfg/C
>>>   	.../pxelinux.cfg/default
>>> The first are MAC addresses, etc.
>> To be pedantic, the first one is a MAC address, the others are hex
>> versions of IP addresses - i.e. (the discovered DHCP IP
>> address)
> I understand all that.
>>>   I want it to pull default. It takes
>>> *minutes* to time out each option, so after a dozen or 15 min, when it
>>> gets to defaul, tftp has timed it out.
>> It shouldn't time out on trying to retrieve a file if the TFTP server
>> is responding - each attempted retrieval should return a "not found"
>> rather than sitting there doing nothing. Trying symlinking the MAC
>> address filename to 'default' so it retrieves it first before any
>> timeout could have happened.
> You'd think. And as I said, this has been working for years, on three or
> four OEM's hardware. Suddenly, there's this new box from Penguin that's
> IBM-based, and it's using  something called "openether.org" firmware, and
> it takes minutes between timeouts, instead of seconds. I'm talking to the
> OEM, but trying to figure out what's going on. I haven't found a timeout
> on the server side, though I suspect there is one, but I really *don't*
> want to make it 20 min. I've also just been googling, trying to find out
> if -mapfile for tftp will let me rename what it's looking for to
> "default", but that search is going nowhere, fast.
>> Also, you might like to try tcpdump to see what is actually happening
>> on the TFTP port.
> I'm under the impression I know - the client *tells* me what it's looking
> for, in the order above, but it sits there, and sits there, before it
> tries the next option.
>         mark
Whatever openether.org is, it sounds buggy.

I do a lot of pxe and your post intrigued me so I poked around some and when I try openether.org, it redirects to www.openether.org and fails.

Might I suggest this page:


There is some discussion of broken pxe stacks and just as a test for you, how about pxe on a floppy/cdrom/usb key?  I've done crazy things like that on occasion.

One other possibility that just occurred to me is it may not be a bug per se, but a UEFI pxe boot attempt... Which could do this too. I just *LOVE* UEFI pxe and someday I will find 
the person who thought it up in a dark alley and make them show me a universal setup.