Error: PXE-E53: No boot filename received (DS 6.x & 7.x)
|Article:TECH10532|||||Created: 2005-12-28|||||Updated: 2013-04-30|||||Article URL http://www.symantec.com/docs/TECH10532|
When a client computer is trying to boot to PXE, it receives the following error message:
PXE-E53: No boot filename received
PXE-M0F: Exiting Intel PXE Rom.
All versions of Deployment Server, including 5.x, 6.x, 7.x
The client computer requested a PXE boot menu and did not receive sufficient instructions on how to get one.
The basic PXE process starts with a DHCP request which is expecting responses that include 1) an IP address for the booting system, 2) the address of the PXE server and 3) the name of the .0 file (the PXE boot menu). If only #1 is returned and not 2,3, an E53 error is displayed.
Following are some possible reasons Deployment Solution may have this problem.
- (6.x) In the PXE Configuration utility, under the DS tab, the option for "Enable response to request from computers not in the DS Database" box is not enabled which stops new computers from being able to receive the PXE boot menu. Also there is an option under the same DS tab for "Enable response to computers with active DS job assigments only". If this option is checked computers with no DS job scheduled will get the PXE-E53 error when attempting to PXE boot.
- The PXE server service is not running. Either this service failed to start up when the computer first booted, or it started up, and then stopped afterward for some reason.
- The network infrastructure is not configured properly for the PXE server to see DHCP requests from the client computers and respond back with the PXE boot menu. This could be caused by the network devices (such as routers and switches) not properly forwarding DHCP broadcast traffic to the PXE server.
- Option 60 is set on the DHCP server when there are no PXE services on the same.
- If the PXE services are on the DHCP server, scope option 060 is not set correctly on the DHCP server.
- Some other program or service on the PXE server is using ports 67, 68, or 4011 and is preventing the PXE Server from listening on those ports (including possibly another PXE service)
- The PXE server is responding either too quickly, or too slowly for the client computer to receive and understand the response.
- The client computer is a pre-PXE 2.0 compliant system and is receiving a incompatible BSTRAP.0 file.
- The PXE service is not responding for some reason (e.g. corrupted installation, MAC Filtering enabled, etc)
- A Firewall on the PXE server or routers is blocking PXE communications, as well as other Network utilities that may block or drop PXE traffic.
- Possible corruption of the pxe.ini (6.9) file or the InitialPXEConfigPath.txt file (7.x).
- If the server uses multiple network card, an incorrect binding order of the network cards can prevent PXE Server to bind to the production one.
- (6.9) The option to "Enable response to request from computers not in the DS Database" is not selected. If you can reimage computers already in the Deployment Console, but can't with new computers, make sure that the PXE Configuration Utilities' DS tab has the "Enable response to request from computers not in the DS Database" enabled. Also make sure the option for "Enable response to computers with active DS job assigments only" is disabled.
- PXE Service is not running: If the PXE Server service is not running, start the service up and make sure that it stays running. Verify that the service account has sufficient rights to run the service (it should be set to "Local System"). If the service starts and then stops check the system event logs for more information on why the service is stopping. The PXE installation might be corrupt, and the PXE server/Site server might need to be reinstalled if the service will not start or stay running.
- Network Infrastructure: If you do NOT use DHCP Forced mode, the DHCP broadcast traffic MUST make it to the PXE Server for processing. Most routers in a network will forward DHCP request packets to the DHCP server, however they are not set up by default to forward these same packets to a PXE server. DHCP Forced mode (see HOWTO7071) is one way around this limitation, but if not used the PXE server needs to see these packets to respond. Many routers and switches can use IP helpers to forward these packets to the PXE server. To test for this scenario, try PXE booting with a computer that is on the same subnet or VLAN as the PXE server. If local computers to the subnet/vlan work but others do not, this is the problem you are having. Adding IP helpers is one resolution or using DHCP Forced Mode as mentioned.
- Setting DHCP Option 60 when it should not be set: If those two components are on different computers, option 060 needs to not be set on the DHCP server.
- Incorrect configuration of DHCP scope option 060: If the PXE server and DHCP server are on the same physical computer, DHCP option 060 needs to be set to "PXEClient".
- Another program using PXE ports: If another program is using the ports 67, 68, or 4011, the PXE Server will not be able to bind to those ports and respond to PXE traffic properly. You will need to remove, disable, or reconfigure the other application not use those ports. You can determine what other program is using those ports by first turning off our PXE Server services, and then running from a command line the following:
This command will show a full list of all programs and services that are using a network connection and the ports they are using, to help you identify who is competing with us for those 3 ports.
- PXE responding too slowly: (Applicable only to DS 6.x at this time. 7.x has no exposed options.) Open the PXE Configuration Utility and select the "PXE Server" tab on Deployment Solution 6.5+, and "General" on previous versions. The following screenshot is from PXE 6.5.
The response time on this will need to be changed based on your environment. Try setting this to a Delayed response, or if it is already delayed try setting this to a short delayed response or setting it to immediate.
- Client Computer is pre PXE 2.0. Under very rare circumstances, the BStrap.0 file can become corrupted in relation to PXE 1.0 client computers and may require a reinstall of the PXE services. Most systems today are PXE 2.0 compliant though, which is why this is very rare.
- PXE Service is not responding. This can occur for several reasons, such as a corrupted installation of PXE (reinstall the PXE Server or Site Services) or because MAC Filtering is enabled.
- In DS 6.x, reinstallation steps are found in article HOWTO7814. To disable MAC filtering, check PXE Configuration > MAC Filter tab and disable all filtering or edit configuration to include/exclude necessary MAC addresses.
- In DS 7.x, reinstallation steps can be found in article XXXXX. To disable MAC filtering (7.5+) check the Deployment Solution | General Settings menu option.
- Firewall on PXE Server or other devices. If you have a firewall or other filter on a network appliance (e.g router, InfoBlox, network firewall), you'll have to configure exceptions for PXE traffic to the PXE server. If on the PXE server, create firewall exceptions in your application for both the TFTP and PXE Server services to the exception list (to find the service executable names and locations, check the service(s) properties).
- Possible corruption of or bad information in the pxe.ini file or InitialPXEConfigPath file.
- DS 6.x: Stop the PXE Config Helper Service, edit the pxe.ini file to remove everything below ServerIP= save your changes and restart the service to reconfigure the rest of the contents.
- DS 7.x Stop the PXE services, edit the InitialPXEConfigPath file to have the correct IP settings. You will then also have to edit a table in the DB to correspond with the new IP settings. See KB XXXXX for more information.
- Possible wrong binding order.
To modify the binding order, follow these steps:
1. Navigate into Network Connections
2. Press the ALT key (to display the menu bar if not already showing) and select 'Advanced' > 'Advanced Settings'
3. On the 'Adapters and Bindings' tab in the 'Connections' window adjust the order of the Networks to adjust the OS connection preference.
Move network card used in production to the first place.
- More troubleshooting can be done with a network trace. Wireshark is a common tool we use for this. See HOWTOxxxx for more information.
Article URL http://www.symantec.com/docs/TECH10532