PXE-E53: No Boot Filename Received
-
I have seen this error a few times while trying to diagnose the issue over the last few days but nothing seems to work.
I have done a clean install of Ubuntu 10.4.4 and from there a fresh install of FOG 0.32. And I am still getting the same issue.
Our Fog server was working perfectly fine, but then one day the above error just started showing up. No one had made any changes to the FOG server accept use it for deploying or capturing images.
The server is fully isolated and built following these instructions [url]http://www.fogproject.org/wiki/index.php/FOG_on_an_Isolated_Network[/url]And this is the network setup that was used on the previous working FOG and current FOG.
[CENTER][SIZE=3][I][FONT=Arial]# The loopback network interfaces[/FONT][/I][/SIZE][/CENTER]
[CENTER][SIZE=3][I][FONT=Arial]auto lo[/FONT][/I][/SIZE][/CENTER]
[CENTER][SIZE=3][I][FONT=Arial]iface lo inet loopback[/FONT][/I][/SIZE][/CENTER]
[CENTER][SIZE=3][I][FONT=Arial]# The primary network interface[/FONT][/I][/SIZE][/CENTER]
[CENTER][SIZE=3][I][FONT=Arial]auto eth0 eth1[/FONT][/I][/SIZE][/CENTER]
[CENTER][SIZE=3][I][FONT=Arial]iface eth0 inet static[/FONT][/I][/SIZE][/CENTER]
[CENTER][SIZE=3][I][FONT=Arial]address 10.10.10.1[/FONT][/I][/SIZE][/CENTER]
[CENTER][SIZE=3][I][FONT=Arial]netmask 255.255.255.0[/FONT][/I][/SIZE][/CENTER]
[CENTER][SIZE=3][I][FONT=Arial]gateway[/FONT][/I][FONT=Arial] 10.10.10.1[/FONT][/SIZE][/CENTER][CENTER][FONT=Arial][SIZE=3]iface eth1 inet dhcp[/SIZE][/FONT][/CENTER]
[LEFT] [/LEFT]
[LEFT] [/LEFT]
[LEFT][FONT=Arial][SIZE=3]Even after a fully clean build I get this error straight away whilst trying to pull the first image. Before installing FOG the server was fully updated and I fear it may be something in an update that is having an affect on FOG.[/SIZE][/FONT][/LEFT]
[LEFT] [/LEFT]
[LEFT][FONT=Arial][SIZE=3]Any help as to why this is happening or if anything can be done? The instructions I have been following are the instructions that have successfully worked for creating a FOG server the last 3 times it was needed. [/SIZE][/FONT][/LEFT]
[LEFT] [/LEFT]
[LEFT][FONT=Arial][SIZE=3]I can access the FOG [/SIZE][/FONT][SIZE=2][FONT=Arial]management, and it is using kernel 3.8.8 Core, which had worked widely with our other computers. We must of used FOG to image almost 100 computers before we reached this issue[/FONT][/SIZE][/LEFT] -
I’m going out on a limb here, I don’t think the issue is with the server, but the network.
I say this because this SAME issue plagued me from the START of my setting up fog.
I had to set up IP address helpers in my network in order to help with the resolution of my fog server, I then installed the DNSmasq service to help with the pxe boot process of finding my pxelinux.0 file.
My recommendation is to install the dnsmasq and use it a proxy dhcp server (Don’t worry it ONLY works during boot up process it will not affect the dhcp of the entire network).
I would also look into the changes that have been implemented in the network, something has changed, maybe a new switch? or replaced a piece of hardware? Maybe someone changed a setting? Make sure your Next-Server (option 66) is point to FOG, also verify that your pxe boot file (option 67) is set to pxelinux.0 (note it is pxelinux.ZERO).
-
We can’t see how it would be a network problem, We have not changed any of our hardware or configuration. And FOG is isolated, I can get to the web management side of it via IP
But I will try the DNSmasq and see how that goes. I will also give a look into the settings to see they are configured as you have said.
I will report back if I get it to work
-
Do you have a Windows imaging server in your network? Does it dole out pxeboot information? I ran into this issue with IP helpers from other buildings within my corporation.
I know you feel like NOTHING in your network has changed but fog doesn’t just magically stop being able to provide the boot file, unless it was never able to be provided in the first place.
I think there is something in the network that is either preventing the full cast of the boot file (that was the case in my environment) or you did not set up the correct information at the DHCP server, you can correct the information at the DHCP, or you can use a proxy dhcp service to serve ip addresses during the pxe boot stage (I HIGHLY recommend this method as it has worked in the past for myself and many others, AND you don’t have to mess up your network to do it!)
Just because the Web side of FOG works doesn’t mean that the FTP sections are behaving as expected. It could also be a misspelling in the boot file name, please note it should be pxelinux.0 (that is a ZERO not an O), or it could be a wrong password. Did you set up passwords for MYSQL when the prompt presented itself?
So please report back what your findings are so was can help further.
If you don’t want to try the proxy dhcp: You can start by isolating the FOG network on a hub or router (something needs to dole dhcp during pxe boot or you won’t get anywhere) and see if you can get a piece of hardware to boot to the FOG pxe menu.
If the device fails, try another make and model (if available).
Running wireshark in your network can help to pin point the issue where the pxeboot file is being dropped as well.
-
Hi Jaymes,
I have no idea what was the problem, but I was doing a clean install of Ubuntu 10.4.4 just to be starting on a fresh slate after going the dnsmasq route. After the clean install of both Ubuntu and FOG, it is now working perfectly. The only thing that had changed is that it is another clean install.
This is the 3rd clean install from disk in a week to try fix this problem. I have no idea why it is working now, as I followed the same instructions every time. The only difference now is eth1 is now running on an IP address of 192.168.1.133 instead of 192.168.1.138. But eth0 is still running on 10.10.10.1
I have gotten as far as the FOG splash screen, and am currently uploading an image as a test.
Thank you so much for your help
-
Wow that is odd, glad you got it sorted and your back up and running, good luck!
-
It was really quite odd, it just stopped working out of the blue and came back out of the blue. Really confusing but I’m glad it had its holiday and everything is back working.
-
Just about a week of FOG working and the issue happened again. I have no idea what is up with it. I am positive that nothing has changed on our network/firewall/hardware configuration. My only guess is it might be a computer in the office that was not powered on last week.
This is some of the strangest happenings. FOG has been used in this office for over a year at this point, and most the computers in the office have been around for that long or longer. I shall try another reinstall of FOG and see what happens.
-
What’s the configuration of the tftpboot file?
What I mean by this is is tftpboot actually stored on another device rather than the local FOG Server’s filesystem? Possibly shared by samba or nfs off of another system?Do you have VoIP on the same network?
This should affect too many things if it’s still trying to contact the tftpserver, however if it’s actually connecting to the wrong one, and your scope is trying to tell the system to pickup the files from the VoIP system. Is it possible there’s two PXE servers within the same network?Did the server get restarted at some point during the week? Maybe the system has a bad power supply, or the MOBO’s dying? I don’t know much about Ubuntu 10.4.4, but maybe check that the tftp service is running. I know 12.04 had an issue where tftp-hpa was trying to start before there was even a NIC available (or more specifically an IP assigned to the NIC), so you had to manually start the service, or tell it to start later on in the init.d processing.
I hope to help you out with narrowing down the issues you’re seeing though. I don’t know, even if a reinstall fixes it, how long everything will continue to work for you.
-
This post is deleted! -
[SIZE=3][FONT=arial][COLOR=#222222]Hi Tom,
The tftpboot file is stored on the FOG server, the attached image is the folder structure. I am not sure if there should be the other tftpboot folder inside this folder? It is empty regardless. For the pxelinux.0 file, I can not open it to view it. Even using sudo it says it cannot be opened.We have nothing running Samba unless Ubuntu 10.04 installs it as default. And we have nothing running VoIP.
We also do not have any other PXE servers running.
This is the shutdown log, all but Thursday were definitely done by me. But I had used the server on Friday and it worked.
$ last -x | grep shutdown | tail -n 10
shutdown system down 2.6.32-56-generi Tue Feb 25 10:57 - 10:59 (00:01)
shutdown system down 2.6.32-56-generi Tue Feb 25 10:35 - 10:36 (00:01)
shutdown system down 2.6.32-56-generi Thu Feb 20 16:22 - 16:24 (00:01)
shutdown system down 2.6.32-56-generi Wed Feb 19 12:07 - 12:09 (00:01)
shutdown system down 2.6.32-56-generi Wed Feb 19 11:36 - 11:37 (00:01)
shutdown system down 2.6.32-56-generi Wed Feb 19 11:28 - 11:29 (00:01)[/COLOR][/FONT][/SIZE]
The tftp service is running.
~$ service tftpd-hpa status
tftpd-hpa start/running, process 2571I have just tried by changing the port we have been using for the last year, it now seems to work on a different port. I have no idea why. I literally just chanced my arm and moved it across one port. The port that FOG did not like still works perfectly fine, just not with FOG.
But to get to this stage I had removed FOG from the server and re-installed it. Using this code [FONT=monospace][COLOR=#000000] [/COLOR][/FONT][FONT=monospace][COLOR=#000000]sudo mv /opt/fog/.fogsettings /opt/fog/fogsettings-firstInstall [/COLOR][/FONT] did nothing.
Thank you so much for everyone giving me pointers and helping me to try figure this out, from doing so many installs of FOG I thought I had got it down as a skill, I think this shows it as a big no.
[url=“/_imported_xf_attachments/0/562_tftpboot folder.PNG?:”]tftpboot folder.PNG[/url]
-
It is working now, and I have been told it is a cabling issue. I can’t see why, as the cable works fine, but I have been told to stop questioning it and just accept it will work where it is now and not where it used to be.
Thanks again for the help.