PXE Boot Issues
-
[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.
-
[quote=“Tom Elliott, post: 43969, member: 7271”]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.[/quote]
Hello. Sure, I am willing to try that. How do I set about doing that? -
See here: [url]http://www.fogproject.org/wiki/index.php/SVN[/url]
I’d suggest setting up a test server first to see if this works for you before upgrading your production server…
-
You know, what I’d recommend is asking whoever controls DHCP to change options 066 and 067 so you can do your job.
Explain to them what you’re trying to do, be nice.
-
Actually, I read further into this thread (should have from the start)…
Why would an ISP control your internal DHCP? Are you [B]sure[/B]?
Or, is it just the home office that is running DHCP?
On a windows client, you can find out exactly where DHCP is coming from:
[CODE]ipconfig /all[/CODE]
There is a line item just for the DHCP server:
[IMG]http://i.stack.imgur.com/5ikMH.jpg[/IMG]
You can then take that IP and do a reverse lookup to give you a [U]name[/U].
[CODE]nslookup x.x.x.x[/CODE]
Sample output:
[IMG]http://files.cyberciti.biz/uploads/faq/2010/12/windows-nslookup-reverse-lookup.png[/IMG]
-
[quote=“Wayne Workman, post: 44027, member: 28155”]Actually, I read further into this thread (should have from the start)…
Why would an ISP control your internal DHCP? Are you [B]sure[/B]?
Or, is it just the home office that is running DHCP?
On a windows client, you can find out exactly where DHCP is coming from:
[CODE]ipconfig /all[/CODE]
There is a line item just for the DHCP server:
[IMG]http://i.stack.imgur.com/5ikMH.jpg[/IMG]
You can then take that IP and do a reverse lookup to give you a [U]name[/U].
[CODE]nslookup x.x.x.x[/CODE]
Sample output:
[IMG]http://files.cyberciti.biz/uploads/faq/2010/12/windows-nslookup-reverse-lookup.png[/IMG][/quote]
Hi Wayne,
My DHCP is run at the ISP’s site and under their control. Yes, I am sure. I know it seems odd and strange. It is.
You have no idea how much I don’t like this. Every time our connection to the ISP goes down (which is often in a third world country), I can’t even print on a printer on my LAN because the routing can’t be figured out anymore.Per your suggestion, I have done the ipconfig and so forth.
The address shown for the DHCP is not on my network. It is the ISP’s domain. Really, it is.
Screen prints here:
[ATTACH=full]1790[/ATTACH][url=“/_imported_xf_attachments/1/1790_dhcp info.jpg?:”]dhcp info.jpg[/url]
-
Well, that’s a whole new story but would you be interested to get rid of this dependency from your ISP? I don’t say that you should change your ISP but you could do DHCP yourself (using the exact same addresses) and ignore the external DHCP traffic completely. Feel free to start a conversation on this with me and we should be able to set this up for you…
-
[quote=“Uncle Frank, post: 44034, member: 28116”]Well, that’s a whole new story but would you be interested to get rid of this dependency from your ISP? I don’t say that you should change your ISP but you could do DHCP yourself (using the exact same addresses) and ignore the external DHCP traffic completely. Feel free to start a conversation on this with me and we should be able to set this up for you…[/quote]
Tom, the SVN version seems to be working. I haven’t done a truly scientific analysis, but I think we are consistently not having the problem. The few times it has blown past to Windows I think are due to a loose or bad Ethernet cable. If I remain on this SVN version, will I be cut off (orphaned) from regular product updates to Fog?
Uncle Frank, I am interested in the idea of running my own DHCP. From my perspective, I wouldn’t feel like I needed to use the exact same IP addresses, unless that is a requirement for your plan? I wouldn’t be able to shut down the ISP’s DHCP. So, whatever we did would have to be something I could completely affect / setup / configure from my side, on my own. The ISP is staff and service are worthless, at best.
-
[quote=“mkstreet, post: 44037, member: 24215”]Tom, the SVN version seems to be working. I haven’t done a truly scientific analysis, but I think we are consistently not having the problem. The few times it has blown past to Windows I think are due to a loose or bad Ethernet cable. If I remain on this SVN version, will I be cut off (orphaned) from regular product updates to Fog?
Uncle Frank, I am interested in the idea of running my own DHCP. From my perspective, I wouldn’t feel like I needed to use the exact same IP addresses, unless that is a requirement for your plan? I wouldn’t be able to shut down the ISP’s DHCP. So, whatever we did would have to be something I could completely affect / setup / configure from my side, on my own. The ISP is staff and service are worthless, at best.[/quote]
I think that Uncle Frank is planning on helping you configure your router & switches to block their DHCP altogether. It’s easily doable. Then, you can just set your own up (or let FOG handle it).
Also, you can upgrade from one SVN revision to another without any issues. I do it sometimes at my work.
Also, one more thing… Just want to see how far away your DHCP server is; out of pure curiosity…
[CODE]tracert 1.179.130.137[/CODE]
That will tell you how many routers are between your host & the DHCP server. -
[quote=“mkstreet, post: 44037, member: 24215”]If I remain on this SVN version, will I be cut off (orphaned) from regular product updates to Fog?
[/quote]SVN versions are almost always built one on top of another in a linear fashion. upgrading from a lower SVN to a higher SVN, or to a release version newer than your current SVN version, is almost always going to be possible. However, downgrades are not supported. Make sure you have backups or a snapshot you can revert to in case you have problems.
-
[quote=“Wayne Workman, post: 44051, member: 28155”]I think that Uncle Frank is planning on helping you configure your router & switches to block their DHCP altogether. It’s easily doable. Then, you can just set your own up (or let FOG handle it).
Also, you can upgrade from one SVN revision to another without any issues. I do it sometimes at my work.
Also, one more thing… Just want to see how far away your DHCP server is; out of pure curiosity…
[CODE]tracert 1.179.130.137[/CODE]
That will tell you how many routers are between your host & the DHCP server.[/quote]Hi Wayne,
I will run the tracert when I get back to the office in the morning, but I can pretty much tell you from memory what it will say.
It’s like this… the PC on my desk (for example) is 192.168.1.32.
Our LAN has a router box at 192.168.1.1 and that is local to me, though I cannot really do anything or affect it.
192.168.1.1 connects directly to 1.179.130.137 which is at the ISP’s central office for our area. -
Sorry for the delay… here is the tracert.
I believe the configuration is like this…
my pc (192.168.1.xxx) --> our gateway (192.168.1.1) --------> long cable ----> ISP’s box (1.179.130.137)
That 1.179.130.137 is the first box, our connection, at the ISP’s site.
[url=“/_imported_xf_attachments/1/1901_tracert.jpg?:”]tracert.jpg[/url]
-
Wow, you made it back!
And I find the “long cable” to be quite funny.
So, you have 2 options for getting FOG working on your network.
Option 1, try dnsmasq. [url]http://fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server[/url]
Option 2, block the ISP’s DHCP and run your own.
Either option is as viable as the other. If you’ve got access to your gateway, I’d recommend blocking the DHCP and running your own.
dnsmasq is something I could help you with setting up. You’ll find the walk-through above quite useful.Basically, dnsmasq just gives additional information to clients that ask for IP config from DHCP. Nothing to it really. You could get that going in a morning probably. Others would need to help you with blocking the ISP’s DHCP if you choose that route.
-
Sorry it took so long. We’ve been on new year’s holiday here for a couple weeks. But this week its blazing hot – like 40+ degrees – so we all want to stay inside with aircon and work.
Thanks for your reply. Uncle Frank has pointed out ProxyDHCP to me… I will look into that.
