11 Replies Latest reply on Dec 17, 2007 3:20 PM by Dan Fitzpatrick

    PXE-E53 and PXE-E32 Provisioning Errors

    Valerian Jone

      Hey all,


      So we're trying to do some provisioning of some blade servers (HP BL465c). We're on 7.4.1. The application server and pxe server and datastore are all on the same vlan/network segment as the bare-metal box.


      Instead of configuring a linux or windows dhcp server, the client is configuring the router to give out DHCP.


      So when we initially reboot the baremetal server, we get this error:


      PXE-E53: No boot filename received


      I know that typically means that the dhcp server did not reply to the broadcast request from the baremetal server (and that the baremetal server has no dhcp IP) but from our dhcp logs, we see that an IP was given out on the same network segment. We didn't do DHCP/IP helper because everything is on the same vlan/network segment.


      What's weird is that if we set the boot file scope option on the dhcp router (giving it a specific boot file name), then we seem to get past the PXE-E53 error. We then are able to actually see the IP that was given out by the dhcp router on the bare metal console screen.


      So I guess the question is, has anyone ever seen the need to set the boot file scope option to give the specific boot filename? (we also set the normal 211 and 212 option as well).


      After all that and after we kept the boot filename option set to some file name, we then get this error:


      PXE-E32: TFTP Open Timeout


      Which again typically means the tftp server is not running or we can't connect to it. If we manually do a tftp command to our pxe/tftp server on the same vlan/network segment, it succeeds, but the baremetal server never seems to execute the tftp request or is pointing to something incorrect and nothing gets logged in the tftpsvr.log file when the baremetal server gives the PXE-E32 error. I double checked the Provisioning Manager Console for the Tools->Configuration TFTP tab and the correct IP address is set there. There are 2 NICs on the bare metal server, 1 NIC is connected to a production network, the other NIC is connected to the provisioning network. I'm specifying the IP of the NIC that is on the provisioning network.


      Both pxesvr.log and tftpsvr.log are set to the DEBUG levels. I can't completely decipher the pxesvr.log but this one message stood out: Does anyone know what this means?


      SPacket: no data for opt 93


      Thanks for any help/insight!



        • 1. Re: PXE-E53 and PXE-E32 Provisioning Errors

          The e53 error most likely indicates that the initial DHCP request by the bare-metal client either didn't make it to the PXE server, or the PXE server didn't reply for some reason. I'd start by validating that the bare-metal client is, in fact, getting an address.


          Additionally, the PXE server sends the boot file information, so you shouldn't be manually setting that. Once you get PXE working, it'll take care of it for you since it's dynamic throughout the provisioning process.


          If you're getting the e32 error as part of the MTFTP part, disregard it. That has never worked and pretty much always spits it out. The boot image transfer happens by means of TFTP instead.

          • 2. Re: PXE-E53 and PXE-E32 Provisioning Errors

            If the App/PXE server has multiple NICs I have sometimes run into the problem where the PXE service binds to the wrong interface. Change the PXE config to listen to "ALL" instead of "eth0".


            If you look in the PXE debug logs search for messages that indicate the PXE has successfully bound and formed a socket. You can also use netstat and look for the UDP port that PXE listens on.

            • 3. Re: PXE-E53 and PXE-E32 Provisioning Errors
              Valerian Jone

              For the PXE-E53 error, how do you typically verify that the bare-metal server is getting an address? Because by the console screen on the bare metal server, I don't see it picking up the address but by the DHCP logs, I do see that it is giving out an address. In the DHCP logs, I see the correct MAC Address associated with the DHCP IP. Thanks.

              • 4. Re: PXE-E53 and PXE-E32 Provisioning Errors
                Valerian Jone

                Hm, interesting, I can try doing that as well, but I think in this case it is binding correctly since in the PXE logs, I do see a request sent back out for the appropriate MAC address after the DHCP broadcast is made by the bare-metal server.

                • 5. Re: PXE-E53 and PXE-E32 Provisioning Errors

                  so is it giving out a new address lease or not? if you check your dhcp logs the request should update lease/renew time.

                  • 6. Re: PXE-E53 and PXE-E32 Provisioning Errors
                    Valerian Jone

                    lease {

                    starts 1 2007/12/17 15:34:21;

                    ends 1 2007/12/17 19:34:21;

                    binding state active;

                    next binding state free;

                    hardware ethernet 00:1b:78:e0:af:96;



                    The above is the new entry in the dhcpd.leases file. Although I guess now that you mention it, it says 15:34:21 but right now it is only 07:38:58 . It always gives out the same IP address,, when i restart the dhcp service. is the last IP in the range of permissible IP's

                    • 7. Re: PXE-E53 and PXE-E32 Provisioning Errors
                      Valerian Jone

                      From /var/log/messages I see this continuously as well:


                      Dec 17 07:52:18 imdalapp154 dhcpd: DHCPDISCOVER from 00:1b:78:e0:af:96 via eth0

                      Dec 17 07:52:18 imdalapp154 dhcpd: DHCPOFFER on to 00:1b:78:e0:af:96 via eth0



             is the IP that is offered and the MAC address 00:1b:78:e0:af:96 is the MAC of the baremetal server that we're rebooting.

                      • 8. Re: PXE-E53 and PXE-E32 Provisioning Errors
                        Valerian Jone

                        Actually scratch the lease time issue, it's all in UTC and I was looking at local time.

                        • 9. Re: PXE-E53 and PXE-E32 Provisioning Errors

                          ok, so you know it's getting an address which means its an issue with your pxe server.

                          • 10. Re: PXE-E53 and PXE-E32 Provisioning Errors
                            Valerian Jone

                            So just to clarify exactly how and when an IP address is obtained:


                            dhcpd.leases does not get populated if the dhcp bootfile-name option is not set. Only when bootfile-name option is set, does the dhcp IP seem to be given out (i.e. dhcpd.leases is populated with an entry for the MAC address of the baremetal server).


                            From the man page for dhcp-options:


                            "option bootfile-name text;


                            This option is used to identify a bootstrap file. If supported by the client, it should have the same effect as the filename declaration. BOOTP clients are unlikely to support this option. Some DHCP clients will support it, and others actually require it."


                            The interesting point seems to be "and others actually require it".


                            Is it possible that we're running up against a bare metal server with a dhcp client that is requiring this option to be set? And is there a way to turn it off?


                            If we cannot turn it off, do you think that if we set the bootfile-name option to a correct boot image, that the pxeserver will be able to respond with the correct IP address of the tftp server so that the baremetal server will be able to initiate a tftp download? Or would we even have to specify the tftp-server-name option as well as another dhcp option to point the baremetal server to the tftp/pxe server?


                            Basically which takes precedence, dhcp options in dhcpd.conf, or values (tftp server ip and bootfile name) sent from the pxe server?

                            • 11. Re: PXE-E53 and PXE-E32 Provisioning Errors

                              in our provisioning process, the boot file name is handed out by our pxe response, not by dhcp. we've never required that one set the dhcp option, nor have we encouraged or supported it. i can also tell you with reasonably solid confidence that this hardware wont require it either.


                              you need to be looking at the pxe server. is it bound to the right interface, is it receiving the initial dhcp discover packet? is it processing it? is it sending out a reply? is said reply being seen on the network where the bare-metal target is?