PXE Boot Issues



  • I’m working on setting up a small scale FOG server to make backups of machines in my office, but I am having issues PXE booting. Right now I am just trying to register one machine with server. Here’s what I have done so far:

    1. Installed Ubuntu 12.04 on a Virtual Machine

    2. Downloaded and installed the latest version of FOG (FOG 1.2.0). The installation went well, and the FOG control panel is accessible at [url]http://xxx.xxx.x.xxx/fog/[/url] .

    3. Verified the permissions in /var/www/fog
      [CODE]
      drwxr-xr-x 12 www-data www-data 4096 Feb 12 09:15 .
      drwxr-xr-x 4 root root 4096 Feb 12 09:15 …
      drwxr-xr-x 2 www-data root 4096 Feb 12 09:15 av
      drwxr-xr-x 2 www-data www-data 4096 Feb 12 09:15 client
      drwxr-xr-x 3 www-data www-data 4096 Feb 12 09:15 commons
      -rw-r–r-- 1 www-data www-data 1406 Feb 12 09:15 favicon.ico
      -rw-r–r-- 1 www-data www-data 50 Feb 12 09:15 index.php
      drwxr-xr-x 7 www-data www-data 4096 Feb 12 09:15 lib
      drwxr-xr-x 12 www-data www-data 4096 Feb 12 09:15 management
      drwxr-xr-x 4 www-data www-data 4096 Feb 12 09:15 mobile
      drwxr-xr-x 3 www-data www-data 4096 Feb 12 09:15 public
      drwxr-xr-x 3 www-data www-data 4096 Feb 12 09:15 service
      drwxr-xr-x 2 www-data www-data 4096 Feb 12 09:15 status
      drwxr-xr-x 2 www-data www-data 4096 Feb 12 09:15 wol
      [/CODE]

    4. Verified UFW (firewall) is disabled using:
      [CODE]sudo service ufw status[/CODE]

    5. Checked to make sure the TFTP server is running.
      [CODE]tftp -v xxx.xxx.x.xxx -c get undionly.pxe[/CODE]

    The TFTP server connection is successful, and the file gets downloaded properly:
    [CODE]
    fog@FOG-SERVER:/tmp$ tftp 192.168.1.108 -v -c get undionly.kpxe
    Connected to 192.168.1.108 (192.168.1.108), port 69
    getting from 192.168.1.108:undionly.kpxe to undionly.kpxe [netascii]
    Received 103273 bytes in 1.1 seconds [724805 bit/s]
    [/CODE]

    The client machine connects to the TFTP server and it tries to pull down the image, but it immediately just displays a “PRESS A KEY TO REBOOT”.

    I verified this using tcpdump on port 69. When a client connects it shows the request:
    [CODE]fog@FOG-SERVER:~$ sudo tcpdump -i eth0 port 69
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

    10:13:07.254773 IP 192.168.1.11.2070 > 192.168.1.108.tftp: 30 RRQ “undionly.kpxe” octet tsize 0
    10:13:07.276370 IP 192.168.1.11.2071 > 192.168.1.108.tftp: 35 RRQ “undionly.kpxe” octet blksize 1456
    [/CODE]

    At this point I think that it is an issue with the ‘undionly.pxe’ file itself…?



  • 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.


  • Moderator

    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 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]



  • [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.


  • Developer

    [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.


  • Moderator

    [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=“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.


  • Developer

    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=“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]


  • Moderator

    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]


  • Moderator

    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.


  • Developer

    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…



  • [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?


  • Senior Developer

    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=“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]


  • Developer

    [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!?



  • 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).



  • 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.



  • 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.


Log in to reply
 

391
Online

39.3k
Users

11.0k
Topics

104.4k
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.