PXE Boot Issues
-
[quote=“Junkhacker, post: 42157, member: 21583”]does ipxe load? what does it look like when it fails? have you configured your dhcp server for pxe boot? are you using the dhcp server option built into fog?[/quote]
Yes, I tried IPXE. No it doesnt load. It just hangs up on
CLIENT IP: XXX.XXX.X.XXX MASK:XXX.XXX.XXX.X DCHP IP:XXX.XXX.X.XXXI haven’t configured the DHCP server beyond the initial configuration that is done during the installation process. I am using the DHCP server built into FOG.
I noticed another user had a [URL=‘http://fogproject.org/forum/threads/tftp-not-working-fog-1-1-1-on-ubuntu-12-04-server.10867/#post-30888’]similar issue[/URL] to mine. I have tried everything he did, and I’m still not getting any PXE menu.
With the default undionly.kxpe I get this output:
[CODE]Configuring (net0 xx:xx:xx:xx:xx:xx)…[/CODE]
-
Maybe you can try to capture all traffic between server and client to see if kernel and init.xz are being transfered:
[CODE]# tcpdump -i eth0 host 192.168.1.11[/CODE]
You should see HTTP requests as well as TFTP requests.I had a problem with a misspelled option in the ipxe menu. To find out what was wrong I needed to take a video because the error message came to the screen only for a split second. Pausing the video I was able to figure out what was wrong…
-
what kind of network configuration do you have set up? managed or un-managed switches?
-
This post is deleted! -
[quote=“Junkhacker, post: 42161, member: 21583”]what kind of network configuration do you have set up? managed or un-managed switches?[/quote]
For now I am just trying to configure FOG on a really basic LAN.FOG SERVER <------> ROUTER <------> CLIENT 1
I plan on scaling the system up to a larger scale later.
-
The fact that it gets ipxe means your tftp server is working fine.
The “any key to reboot” with the “Configuring (net0 xx:xx:xx:xx:xx:xx)…” tells me a couple of things.
First is the network you’re (basic as it may seem) setup with STP?
If STP is enabled, is it setup for Rapid STP or PortFast?
If it isn’t enabled, is there IP helpers to tell the system to obtain dhcp?
Is there more than one NIC on the system?
-
[quote=“Tom Elliott, post: 42165, member: 7271”]The fact that it gets ipxe means your tftp server is working fine.
The “any key to reboot” with the “Configuring (net0 xx:xx:xx:xx:xx:xx)…” tells me a couple of things.
First is the network you’re (basic as it may seem) setup with STP?
If STP is enabled, is it setup for Rapid STP or PortFast?
If it isn’t enabled, is there IP helpers to tell the system to obtain dhcp?
Is there more than one NIC on the system?[/quote]
I am not aware of any STP configuration. All I have done is installed Ubuntu Server 12.04 on a Virtual Machine (using VirtualBox). In the “Network” category I have the network adapter attached to the “Bridge Adapter” with promiscuous mode set to “Allow VMs.” I installed FOG on top of this. I have verified that the TFTP and DCHP configuration is working. I can communicate with the TFTP server, and the DCHP server is working correctly. I’m not aware of any IP helpers. And, in general, I’m not really that well rounded with networking in general…I do know that the virtual machine has two network interfaces: lo and eth0.
-
[quote=“Tom Elliott, post: 42165, member: 7271”]The fact that it gets ipxe means your tftp server is working fine.
First is the network you’re (basic as it may seem) setup with STP?
If STP is enabled, is it setup for Rapid STP or PortFast?
[/quote]
[LIST]
[]Tom is refrering to this information. [url]http://fogproject.org/wiki/index.php/IPXE#STP.2FPortfast.2FRSTP.2FMSTP_To_Enable_or_Disable.3F[/url]
[]These settings are on your swithes if they are managed. Some unmanaged switches will set STP automatically but are rare.
[*]Limit the network adapters in the VM to 1
[/LIST] -
[quote=“Wolfbane8653, post: 42183, member: 3362”]
[LIST]
[]Tom is refrering to this information. [url]http://fogproject.org/wiki/index.php/IPXE#STP.2FPortfast.2FRSTP.2FMSTP_To_Enable_or_Disable.3F[/url]
[]These settings are on your swithes if they are managed. Some unmanaged switches will set STP automatically but are rare.
[*]Limit the network adapters in the VM to 1
[/LIST]
[/quote]
VirtualBox is set to limit the network adapters in the VM to 1. I will look into STP. I’m not familiar with it at all. -
Before going on not so about looking into STP what about changing on the only file so you’re using the ipxe.pxe
-
[quote=“Tom Elliott, post: 42187, member: 7271”]Before going on not so about looking into STP what about changing on the only file so you’re using the ipxe.pxe[/quote]
The issue was DHPC.
The router was configured to be a DHPC server and the FOG server was designated as a DHCP server as well… I fixed this and it works great! Thanks for all the assistance!
-
This post is deleted! -
I must be having the same or similar problem with DHCP. I’m not exactly sure how to fix it the best way.
At first, when I booted, the clients would find DHCP and load iPXE. However, after that load was done, there was about a 50-50 chance that it will go to the Fog PXE menu or an error message would flash by and it boots from the clients local disk.
After reading this thread, I unplugged the lab from the external (Internet) connection so that the Fog server and clients are all isolated together now on the LAN. After that, the problem disappears and the clients consistently get to the PXE menu.
In my environment, I don’t control the “real” DHCP server. It runs externally at the ISP office. If this seems bizarre to you, then you feel the same as me. But that doesn’t change the fact that I cannot affect the “real” DHCP server’s settings.
Is the answer changing the Fog settings to say that the Fog server is the only DHCP server?
This won’t really work very well to have the Lab cut off from the Internet while loading. Because some machines I need to load are wired outside that LAN and I cannot isolate them.
Thanks!
-
[quote=“mkstreet, post: 43838, member: 24215”]Is the answer changing the Fog settings to say that the Fog server is the only DHCP server?[/quote]
No. At boot time the client will request a response from a DHCP server. If you have multiple servers, the first response received will be acted upon.
The right solution is to disable your fog dhcp server, and set up your other dhcp server to serve fog clients properly.
If you don’t have control over dhcp, you can try to block dhcp messages from leaving your network, and reaching the other dhcp server.
-
I don’t have any control over the other DHCP (though you have no idea how much I wish I did!).
I’m not sure how to block the DHCP messages… suggestions?
This must be something that is working very different under Fog 1.2.0? I didn’t really have any problems like this with Fog 0.32.
-
The request for a response from the DHCP server comes from your NIC ROM. Nothing to do with fog. And perhaps previously dhcp messages were not leaving your private network? They never should.
Blocking dhcp messages depends on your router: if it’s pfSense based, you have a gui, if it’s pure Linux, you can look at iptables, all depends on what software is running on your router.
-
What I mean is…I think the PXE boot sequence has changed under Fog 1.2.0 such that the DHCP has a bigger role now.
This is different than Fog 0.32. The only thing that has changed in the picture is attempting to upgrade from Fog 0.32 to Fog 1.2.0.Unfortunately, in our network, DHCP has always been run by a server at the ISP’s office. This has always been the case.
I guess technically that is still our private network, logically speaking, but it is offsite and unmanaged (at least by us). -
[quote=“mkstreet, post: 43838, member: 24215”]At first, when I booted, the clients would find DHCP and load iPXE. However, after that load was done, there was about a 50-50 chance that it will go to the Fog PXE menu or an error message would flash by and it boots from the clients local disk.[/quote]
Would you be able to record this with a camera and re-play it in slow motion (or pause/play through) to get to see the error message?It’s very interesting that with internet connection being hooked up still all clients seam to load iPXE because the DHCP server had to be involved to make this work already! Maybe it’s because the local FOG DHCP server is faster in that very first step…
To give you a little more insight on how this works (and what might be different in FOG 1.2.0):
[LIST]
[]PC boots up
[]BIOS is configured to boot from network so it sends a DHCP request (broadcast)
[]DHCP request is answered (including options for ‘next-server’ and ‘filename’)
[]PC loads boot image from tftp://<next-server>/<filename> (e.g. tftp://192.168.1.1/undionly.ipxe)
[]iPXE boot image is loaded and executed on the PC
[]iPXE sends another DHCP request to get an IP address (before being able to load things via HTTP, TFTP or other protocols)
[*]…
[/LIST]
I guess this is where things go wrong from time to time… In FOG 0.32 pxelinux was used instead of iPXE. As far as I could find out pxelinux does not request an IP from the DHCP server (because it is less capable of loading things).Not sure if this helps!?
-
[quote=“Uncle Frank, post: 43959, member: 28116”]Would you be able to record this with a camera and re-play it in slow motion (or pause/play through) to get to see the error message?
It’s very interesting that with internet connection being hooked up still all clients seam to load iPXE because the DHCP server had to be involved to make this work already! Maybe it’s because the local FOG DHCP server is faster in that very first step…
To give you a little more insight on how this works (and what might be different in FOG 1.2.0):
[LIST]
[]PC boots up
[]BIOS is configured to boot from network so it sends a DHCP request (broadcast)
[]DHCP request is answered (including options for ‘next-server’ and ‘filename’)
[]PC loads boot image from tftp://<next-server>/<filename> (e.g. tftp://192.168.1.1/undionly.ipxe)
[]iPXE boot image is loaded and executed on the PC
[]iPXE sends another DHCP request to get an IP address (before being able to load things via HTTP, TFTP or other protocols)
[*]…
[/LIST]
I guess this is where things go wrong from time to time… In FOG 0.32 pxelinux was used instead of iPXE. As far as I could find out pxelinux does not request an IP from the DHCP server (because it is less capable of loading things).Not sure if this helps!?[/quote]
Your description sounds spot-on.
First, I agree that my FOG DHCP is likely faster in that first step. The FOG server is on the same router as the PC’s I want to load. Whereas the “real” DHCP is offsite, several kilometers away.Second, I agree that the “iPXE” sending another (second) DHCP request to load things via HTTP is where things are going wrong. This would be new behavior with Fog 1.2.0, over Fog 0.32, as you noted.
I did get a screen shot of what happens when it loads, though the image appears a little jumbled, I have attached that frame here. What would follow this frame would be booting Windows from the local HDD.
I had to do this twice when making the video. The first time the Fog DHCP was “fast enough” on both DHCP requests and it went to the PXE menu. The second attempt is what led to the opportunity to capture this screen shot.Um… so… what are my options to fix this situation?
[url=“/_imported_xf_attachments/1/1789_ipxe error.png?:”]ipxe error.png[/url]
-
If you could be so willing, maybe svn/trunk of fog will work? In 1.2.0 and prior I had iPXE always re initialize to get dhcp. I learned how to get Ipxe to use the PXE requested dhcp which should keep the reinitialization down to when it’s actually needed vs every time.