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 http://xxx.xxx.x.xxx/fog/ .

    3. Verified the permissions in /var/www/fog

    
    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
    
    
    1. Verified UFW (firewall) is disabled using:
    sudo service ufw status
    
    1. Checked to make sure the TFTP server is running.
    tftp -v xxx.xxx.x.xxx -c get undionly.pxe
    

    The TFTP server connection is successful, and the file gets downloaded properly:

    
    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]
    
    

    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:

    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
    
    

    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. http://fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server

    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.

    tracert.jpg



  • @Wayne Workman, post: 44051, member: 28155 said:

    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…

    >tracert 1.179.130.137
    >```
    That will tell you how many routers are between your host & the DHCP server.
     
     
     
    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

    @mkstreet, post: 44037, member: 24215 said:

    If I remain on this SVN version, will I be cut off (orphaned) from regular product updates to Fog?

    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

    @mkstreet, post: 44037, member: 24215 said:

    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.

    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…

    tracert 1.179.130.137
    

    That will tell you how many routers are between your host & the DHCP server.



  • @Uncle Frank, post: 44034, member: 28116 said:

    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…

    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…



  • dhcp info.jpg


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

    ipconfig /all
    

    There is a line item just for the DHCP server:

    ""

    You can then take that IP and do a reverse lookup to give you a [U]name[/U].

    nslookup x.x.x.x
    

    Sample output:

    ""


  • 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: http://www.fogproject.org/wiki/index.php/SVN

    I’d suggest setting up a test server first to see if this works for you before upgrading your production server…



  • @Tom Elliott, post: 43969, member: 7271 said:

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



  • ipxe error.png


  • Developer

    @mkstreet, post: 43838, member: 24215 said:

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

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

    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
 

646
Online

38729
Users

10555
Topics

99937
Posts

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