mounting /images failed: Connection timed out

[george1421]

@sjensen ls -la /images and ls -la /images/dev

[sjensen]

@george1421

[Tom Elliott]

@sjensen THen my other question, what is the exact output of cat /etc/exports

Please don’t screen shot and leave a “part” of it out this time?

[george1421]

@Tom-Elliott for reference this is what my fog server has (note the fsid is different for each export [share]):

pi@pi01:~ $ cat /etc/exports 
/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

[sjensen]

@george1421 What does that affect? Should I change it?

[Tom Elliott]

@sjensen I need to see it.

/images should have FSID of 0
/images/dev should have FSID of 1.

If you must change these values for other reasons, they cannot be the same, and they should be “iterative”

[george1421]

@sjensen said in mounting /images failed: Connection timed out:

@george1421 What does that affect? Should I change it?

In a word, please show us your cards first. Then we will tell you if you won or not.

[sjensen]

@george1421

[Tom Elliott]

Please give a shot at changing the fsid’s so they are in order:
/images with fsid 0
/images/dev with fsid 1.

Also, please give a try at:

sudo touch /images/.mntcheck
sudo touch /images/dev/.mntcheck
sudo chown -R fog:root /images
sudo chmod -R 777 /images
sudo exportfs -a
sudo service nfs-kernel-server restart
sudo service ufw disable

[sjensen]

@Tom-Elliott Ok I did what you asked. Should I try to upload an image again?

[Tom Elliott]

Yes please.

[sjensen]

@Tom-Elliott same result…sorry

[sjensen]

@Tom-Elliott yesterday I did a kernel update would that have broken anything? I did it via terminal.

[Tom Elliott]

@sjensen The fact that it’s saying timeout leads me to think the the connection is unable to reach the server.

[george1421]

@Tom-Elliott Possibly schedule a debug deploy and then check what FOS is seeing?

[Tom Elliott]

@george1421 Sure? I don’t know. This seems awefully fishy and we aren’t getting anywhere.

The stuff all points that something else is blocking the connection. Maybe the subnet the systems are booting from (and being issued IP addresses) is not allowed to request data?

[george1421]

@sjensen said in mounting /images failed: Connection timed out:

@Tom-Elliott yesterday I did a kernel update would that have broken anything? I did it via terminal.

I guess we need to collect a little more information here then.

What version of FOG are you using?
What version of kernel did you just update to?
Why did you update it?
What hardware are you trying to capture? (manufacturer and model)
Is the FOG server and target computer on the same subnet? (I think you already answered this)

What you are experiencing is not typical with FOG. We need to identify where the gap is. It appears the target computer has network access, but it doesn’t have nfs access to the fog server(??). You can mount the nfs shares locally on the fog server, so the fos engine should be able to do the same. You have confirmed that the IP address of the FOG server matches the IP address from the error page. There is something going on here that is for sure.

[sjensen]

@Tom-Elliott I dont think this makes a difference, but my fog server is a virtual it is on one vlan and my host is on another vlan. I can connect to the web interface for Fog with no issues from my computer which is on another vlan.

[sjensen]

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

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