mounting /images failed: Connection timed out

sjensen · Dec 21, 2016, 9:31 PM

@george1421 Fog version 1.2.0
the latest kernel (i saved the old kernels)
I updated because i was trying to download an image to a computer (HP prodesk 600 g2) and was getting an error “tsc fast tsc calibration failed”
all posts I read said to update the kernel.
I am trying to capture a HP 6005 usff. I have made a test image of this pc prior.
Yes both Fog server and client are on the same subnet.

Tom Elliott · Dec 21, 2016, 10:13 PM

@sjensen Your information is conflicting.

You state the FOG Server and the client are on the same subnet, but the post before that you state they’re on different VLAN’s.

Now, being issued different IP’s is fine as your DHCP controller can handle passing the boot files and with the use of IP Helpers all will seem to work fine.

The difference, however, is something is obviously not right and we now have conflicting information making it that much harder to figure out.

If they are on separate vlan’s I’m assuming there’s a switch handing out information and there’s probably a central point where all things reach out through. After that, there’s probably a firewall and traffic is all routed to that point?

I’m just trying to understand the layout. Two clients on the same subnet (Server and host) should have no problems mounting an NFS share. But if you throw a firewall into the mix and separate vlan’s, I can only guess the network has no idea where to go, or it’s entirely blocked from that particular connection.

george1421 · Dec 21, 2016, 4:41 PM

@sjensen just for clarity (since you are using FOG 1.2.0) what is “the latest kernel, specifically” The latest kernel for FOG 1.2.0 is not he latest kernel for FOG 1.3.0. If you revert to the previous kernel and do a compatibility test from the fog menu, do both networking and hard disk pass?

Also for clarity has this setup ever worked? I know you said that it worked the other day, but how much history do you have with this FOG server?

As Tom noted, and I also picked up on. You talk about vlans and then mentioned that both the fog server and the target computer is on the same subnet. I see a discrepancy here. I specifically asked if they where on the same subnet to ensure there was no kind of screening / firewall router between the target computer and the FOG server that may be blocking NFS traffic, but passing http traffic.

You mentioned that FOG worked before (for some system), does it sill work if you tested with that model?

As noted before this system is acting inconsistent with what we would expect from FOG. There has to be something that changed beyond the kernel.

We may need you to do a debug capture for this computer. (the debug capture for 1.2.0 is on the advanced menu in the host settings page). By doing a debug capture and then pxe booting the target computer FOG will drop you to a command prompt on the target computer so we can do some additional debugging steps.

The first thing I would try is for the target computer (running in debug capture mode) to see if it can ping the fog server.

sjensen · Dec 22, 2016, 1:44 PM

@george1421Please understand I am very new to Linux, I appreciate all the commands you have sent. I downloaded the latest kernel for 1.2.0, however i do not remember the version. I can try to revert to old kernel.

To clarify, yes the setup worked. I was able to upload and download an image. Host had an ip address ending in 6.62, Fog server Vm ip address ending in 28.10, client got its ip from the dhcp server in the subnet as fog server 28.xx.

No the original system does not work any longer.

TO my knowledge I have not changed anything else except the kernel.

As a test this morning I put host, server, and client on the same subnet. I still get the same result. I am thinking its got to be the kernel. Thoughts?

Tom Elliott · Dec 22, 2016, 1:50 PM

@sjensen The kernel has nothing to do with connecting to the NFS Mount point. Support for NFS is embedded in every kernel in the same way (so if one kernel works all the rest will as well).

You can try reverting to the original kernel but I don’t think that will fix the issue either. From a client within a Debug mode: (From FOG GUI goto Host->Basic Tasks->Advanced->Download - Debug)

Let the system boot and press enter if/when prompted to. It will drop the client machine booting into a console shell.

Let me know when it’s there.

george1421 · Dec 22, 2016, 1:56 PM

@sjensen Thanks for the clarity on the issue.

So now we know there is a router between the target computer and the FOG server. Might you think there is some kind of filter turned on this router? Is the fog server and the target computer on the same physical campus? Understand I’m trying to get a picture of your setup. But Tom is right getting access to the target computer’s command prompt by a debug capture mode will allow us to type in commands on the target computer, to see (in a way) what the target computer sees in the form of your network.

sjensen · Dec 22, 2016, 2:23 PM

@Tom-Elliott OK i will do so. Do i want download debug or upload debug?

Tom Elliott · Dec 22, 2016, 2:24 PM

@sjensen I thought my information was specific enough, but ultimately either one or the other will work just fine. In your case, as you’re trying to upload a new image?: Use upload debug.

sjensen · Dec 22, 2016, 2:30 PM

@Tom-Elliott Ok it is waiting at the command prompt.

Tom Elliott · Dec 22, 2016, 2:36 PM

@sjensen Try mounting the nfs: run->

mkdir /images
mount -o nolock,proto=tcp,rsize=32768,wsize=32768,intr,noatime "192.168.28.10:/images/dev" /images

Tom Elliott · Dec 22, 2016, 2:38 PM

Also, so we know the kernel version you’re running, can you get us the output of:

uname -rm

george1421 · Dec 22, 2016, 8:40 AM

@sjensen The first thing I want you to do is this:

On the console of the target computer key in

ip addr show that will tell you the current IP address of the target computer (please post it here)
I need you to give root a password so we can connect to it remotely (so you don’t have to sit in front of the target computer) passwd and give root a password it can be something as simple as Password-1 or complex, it is up to you. This password will exist until the target computer is rebooted so its only temporary.
Install putty on your computer [ http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html ], its a free download and will allow you to connect to the target computer over the network. You will need this to copy and paste commands given by Tom or myself. The exe is not installed, but just run.

I see Tom went in directly to the point.

sjensen · Dec 22, 2016, 2:44 PM

@Tom-Elliott

sjensen · Dec 22, 2016, 2:51 PM

This post is deleted!

george1421 · Dec 22, 2016, 8:56 AM

@sjensen OOoops you fell into the kernel hole. The kernels between 4.2 and 4.6 don’t work for FOG 1.2.0, if you upgrade to latest kernels for FOG 1.3.0 you will be in a better state.

cd /var/www/html/fog/service/ipxe
cp bzImage bzImage.old
cp bzImage32 bzImage32.old
wget -P https://fogproject.org/kernels/bzImage
wget -P https://fogproject.org/kernels/bzImage32

Now here is the part I’m not sure of, and Tom will need to answer. I was under the impression that FOG 1.2.0 was 32bit only? if that’s the case we need to rename the kernel file

sjensen · Dec 22, 2016, 2:53 PM

@Tom-Elliott this is what got
mount: cant find images: in /etc/fstab

Tom Elliott · Dec 22, 2016, 2:54 PM

@sjensen I need to see the exact mount command you used.

The command should not run multiple lines.

Tom Elliott · Dec 22, 2016, 2:55 PM

@george1421 1.2.0 (1.0.0 and up really) all used 64 bit and auto adjusted for 32 bit.

george1421 · Dec 22, 2016, 2:56 PM

@Tom-Elliott said in mounting /images failed: Connection timed out:

@george1421 1.2.0 (1.0.0 and up really) all used 64 bit and auto adjusted for 32 bit.

OK so the names bzImage == x64 and bzImage32 == x86 is still proper for 1.2.0?

Tom Elliott · Dec 22, 2016, 2:57 PM

@george1421 Yessir.

mounting /images failed: Connection timed out

242

12.0k

17.3k

155.2k