Host isn't booting into FOG menu

[george1421]

@Benjamin_D said in Host isn't booting into FOG menu:

I think you understand correctly, here, but just to clear any confusing of your use of the term “master”, the server at “HQ” isn’t meant to store anything, and the storage node on the other end of the VPN is the master storage node that will be the machine holding the host’s image.

OK so the sites/roles are reversed. You have a master fog server at the remote site. Gotcha. Just be aware you can only capture to and multicast from a fog master node.

Correct (although I believe you made a typo, since I believe it is option “67” not “77”).

Yep that was a silly type-o. Typing too fast

Ok, so both dhcp (udp port 67 and I assume 68) and the tftp (udp port 69) are running. So the target should be getting something.

From your note, you feed that both dhcp options 66 and 67 are set correctly, yet no file is received by the client.

quick check: Can you tftp using a windows computer, and transfer a file like undionly.kpxe from the master FOG server?

If that fails then we need to see what’s going down the wire. We can do that with your fog server as long as the pxe booting target computer and the fog server are on the same subnet. ref: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If you know wireshark and can read the dhcp boot process you may review it, or post the pcap file here and we can take a look. What will be interesting to see is if the fog server IS responding to the dhcp request and what file name is the target computer being told to transfer.

Edit: just as a thought, you only have one dhcp server at the remote location… and that’s the fog server right?

[Benjamin_D]

@george1421 said in Host isn't booting into FOG menu:

Ok, so both dhcp (udp port 67 and I assume 68) and the tftp (udp port 69) are running. So the target should be getting something.

From your note, you feed that both dhcp options 66 and 67 are set correctly, yet no file is received by the client.

Correct.

quick check: Can you tftp using a windows computer, and transfer a file like undionly.kpxe from the master FOG server?

While I can ping the server’s LAN IP, the command: tftp 192.168.10.100 GET undionly.kpxe C:/ returns a “Connect request failed”

If that fails then we need to see what’s going down the wire. We can do that with your fog server as long as the pxe booting target computer and the fog server are on the same subnet. ref: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If you know wireshark and can read [0_1497894431090_Capture.pcapng](Uploading 100%) the dhcp boot process you may review it, or post the pcap file here and we can take a look. What will be interesting to see is if the fog server IS responding to the dhcp request and what file name is the target computer being told to transfer.

Here’s a link to the capture. I stopped it once it got to the login screen: https://drive.google.com/open?id=0B5vOQkrBMlbtNUtrM0VQdzlBZjA

Edit: just as a thought, you only have one dhcp server at the remote location… and that’s the fog server right?

Correct. If it helps, here is the relevant part of my dhcpd.conf file:

subnet 192.168.10.0 netmask 255.255.255.0
{
        range 192.168.10.2 192.168.10.9;
        default-lease-time 600;
        max-lease-time 7200;

        # option 66
        option tftp-server-name "192.168.10.100";

        # option 67
        option bootfile-name "undionly.kpxe";
        option routers 192.168.10.1;
}

192.168.10.100 is the storage node, the client shows that it has an appropriate IP when I run “ifconfig”, and 192.168.10.1 is the router.

[george1421]

@Benjamin_D In the pcap file I see you are pxe booting a ia86 system. Your dhcp server is 192.168.10.100. Its giving the target computer an ip address of 192.168.10.4 with a subnet mask of 255.255.255.0.

The next sever is the dhcp server of 192.168.10.100 but there is no boot file name given. (packet #793 btw it would have been much easier to find/read if you used the capture filters defined in that tutorial).

I would expect your dhcp config file to look similar to example 1 here: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

[Sebastian Roth]

@Benjamin_D There are two places in a DHCP packet where the relevant PXE boot information can be delivered. One is within what I call DHCP header. In the picture below this is “Next server IP address: 10.1.1.51” and “Boot file name: ARDBP32.BIN”:

And you can also see option 66/67 further down. As far as I know clients can handle both quite well. Some servers only provide the information in the “header” others via options and some do both (as you can see in the picture).

What I see in the PCAP file you posted is next-server set in the “header” but filename via option 67. So both are there but seems like clients don’t like the information to be split in both sections. I don’t know what other things you have in your dhcpd.conf but most often I use next-server x.x.x.x; and filename "undionly.kpxe"; for ISC-DHCP servers.

[Benjamin_D]

@george1421 Okay I’ve reformatted my dhcpd.conf to match example 1, and now it gets to where it is trying to grab boot.php.

However, it fails to do that, and I believe that is due to the fact that the host is using the VPN IP of the storage node to grab boot.php, as opposed to the LAN IP. Is there a way to have the clients use the LAN IP address for grabbing boot.php even though I have to add the storage nodes via the VPN IP address?

[george1421]

@Benjamin_D While you have a unique setup and I don’t recommend doing this, in the default.ipxe that should point to the local fog server.

The other thing that IS supported is to install the location plugin. Create a location, assign your storage nodes to that location, and finally when you register a target computer ensure you assign it to that location. That way you can control which fog server the target will connect to.

[Benjamin_D]

@george1421 said in Host isn't booting into FOG menu:

@Benjamin_D While you have a unique setup and I don’t recommend doing this, in the default.ipxe that should point to the local fog server.

The other thing that IS supported is to install the location plugin. Create a location, assign your storage nodes to that location, and finally when you register a target computer ensure you assign it to that location. That way you can control which fog server the target will connect to.

I’ve changed the IP address in default.ipxe to the storage node’s LAN IP, which leads me to this error:.

As far as the location plugin is concerned, it’s been installed and I use it, but I don’t see how that exactly solves my issue here. As far as IP schemes are concerned, it’s no different then just telling FOG what storage group to use like you would without the plugin, right?

[george1421]

@Benjamin_D OK I think I need to get a clear picture of what is going on here, including the vpn tunnel.

You have a remote site where a FOG Master node is installed. In addition to this device being a fog master node its also running isc-dhcp server.

The fog master server’s IP address is 192.168.10.100 and its issuing IP address < .100.

When you pxe boot target computers at that site it should boot from the local fog server.

Is that not happening? Now we are focusing on the master node at the remote site, pxe booting clients at the remote site.

(a quick doodle of your setup with ip addresses, might be in order here)

[Benjamin_D]

@george1421 said in Host isn't booting into FOG menu:

@Benjamin_D OK I think I need to get a clear picture of what is going on here, including the vpn tunnel.

Okay, let’s see if I can get us all on the same page here.

You have a remote site where a FOG Master node is installed. In addition to this device being a fog master node its also running isc-dhcp server.

Yes. It is a FOG storage installation that is itself the master node, and yes it is running ISC-DHCP-Server.

The fog master server’s IP address is 192.168.10.100 and its issuing IP address < .100.

Yes that is the IP address, however it’s range is only from .2 through .9 (it’s a test network with only one client for it to lease IPs to)

When you pxe boot target computers at that site it should boot from the local fog server.

Is that not happening? Now we are focusing on the master node at the remote site, pxe booting clients at the remote site.

Given that it does successfully talk to the master node at the remote site for the tftp portion, it seems like it’s getting part way through the boot at least.

(a quick doodle of your setup with ip addresses, might be in order here)

Okay, this has a bit more information that we probably need to solve it, but just to give you a full picture of the test network I have setup (the end goal is the VPN will be over the Internet, in-case you are wondering why it’s setup like it is):

[george1421]

@Benjamin_D OK the picture tells me a bit more of what is going on.

What you are calling the control server (normal install) IS the fog master node. It IS the fog server that has the mysql database on it. A storage node is a FOG server without its own local database.

So as its currently designed, your control server is the only server in your setup that can capture images. Both systems can deploy images just fine.

In your setup clients at the 192.168.10.x subnet must be able to reach your control server during pxe booting. The control server will redirect the pxe booting clients to the storage node. Now understand the clients at 192.168.10.x can pxe boot (download undionly.kpxe) from your storage node, it will download default.ipxe from the storage node (which needs to point to your control server to pick up the boot.php file).

VPN still isn’t an issue here as long as the clinets on 192.168.10.x can ping the control server at 192.168.1.100.

[george1421]

@Benjamin_D I guess I would have to ask, what is your goal in this design. It appears you are trying to tunnel the fog network through your existing network of 10.9.2.x

I also wonder why you have two fog servers in this setup if only the remote location will only have pxe client computers. I’m just trying to understand your design intent. On the surface it should work like this as long as the dhcp clients can reach the normal install FOG server.

[Benjamin_D]

@george1421 said in Host isn't booting into FOG menu:

In your setup clients at the 192.168.10.x subnet must be able to reach your control server during pxe booting. The control server will redirect the pxe booting clients to the storage node. Now understand the clients at 192.168.10.x can pxe boot (download undionly.kpxe) from your storage node, it will download default.ipxe from the storage node (which needs to point to your control server to pick up the boot.php file).

So, if I understand you correctly, I should go into default.ipxe and change the IP address to 10.8.0.1? I know you said that VPN isn’t the issue, but I don’t understand how the host is able to know where to go for the 10.8.0.1 IP, if it isn’t part of the VPN tunnel.

[george1421]

@Benjamin_D switching to chat for a bit faster turnaround. Look at the talk bubble on the fog forum tool bar.

[Sebastian Roth]

@Benjamin_D Is this solved?