[CentOS] CentOS 6 and pxeboot

[Pete Biggs]

> > >         .../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.
> > 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. 

Yeah, different hardware tickling different bugs ...

> 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.

On the TFTP server can you not just do

  ln -s default b8945908-d6a6-41a9-611d-74a6ab80b83d

or 

  cp default b8945908-d6a6-41a9-611d-74a6ab80b83d

rather than playing with mapping files - just for testing purposes.

Have you tried pxelinux.0 instead of gpxelinux.0? Or possibly iPXE?

> > 
> > 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.
> 
I was more thinking of seeing if the server responds at all - the
symptoms you see look like the server either ignoring the commands or
just not seeing them. I would suggest that a firewall is in the way
somewhere or wrong subnet or something like that, but as you say, it's
working for other clients.

P.