Might be faster to ship them a hard drive in the mean time…

But I agree with Tom, you can setup a storage node there and use the location plugin.

Fog doesn’t need anything super powerful. An old P4 or Core 2 Duo would work fine. You can even get an Intel NUC to use a fog storage node.

@Sebastian-Roth Thank you for all your help I updated to latest Trunk and followed the troubleshooting guide got all my credentials set correctly and images are capturing now!

@Sebastian-Roth thanks for suggestion, there was a problem with snapin configuration. In field “Snapin File (exists)” was “Please select an option”
Thanks once again
Regards

Just wanted to say I updated to SVN 6955 and inventory is running great. Thanks Sebastian and Tom for the hard work.

@Tom-Elliott From what wrs2 posted so far it does not seam that he’s tried to update!! Just plain FOG 1.2.0 installation which started to show a DB issue. Maybe I am wrong but that’s what I found from his explanations.

Edit: Sorry I somehow missed this from @wrs2’s post:

I actually just remembered that we have been having this problem after we updated the code from 1.1.2.

So Tom is probably right about this having been a schema update issue.

Guys,

Thank you, I was trying to capture 7240.
I was able to capture 7250 successfully, so I think you are correct.

Thanks,

Tom

Reported here as well: https://forums.fogproject.org/topic/7010/install-fog-with-2-disks. Tried to replicate the issue but no. Free space is shown correctly for me.

@Tom You reported the same issue here. I tried to reproduce but I can’t. Please check if /images/<image-name> is still present after deleting the image definition?!?

Hello ALLLLLLLLLL!
I did it!!! 😆 😆 😆
The problem was when the client executes the chain command, it sends another request to the DHCP server, and it points the client back to the same iPXE server because that’s what the DHCP server has.

The solution is to explicitly specify the PXE server with command “set net0/next-server iPXE-server-ip”.
Please see below for my screenshot.
0_1458935856581_upload-77255287-209f-40df-bbc4-b1e534ccd24a

Thank you guys for all the help!!! 😀

@alexh Hi, please create another topic about you problem. First time look at that : https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP

We were able to get the stuff figured out. YAY!

The connection is now operational. FOG Interface displays properly.

You are welcome! 🙂 As well I learned to pay even more attention to what I see in the PCAP file. Would have saved us at least an hour or two… When testing with the command line client Scott didn’t know about the important -i option for Windows tftp command line client as described here. When looking at the PCAP file Scott sent me I didn’t notice that it tried to request the file in ‘netascii’ mode instead of ‘binary’.

So everything is working now and it was just the upper case filename option in the DHCP config…

@Satya because this is a consumer grade router is there any special configurations on it doing special things? If not there usually is a reset button on the router that will allow you to reset to the factory defaults. What the sequence of doing so is would require the manual of the device which you can find online.

@MagicLink Correct, they are compressed.

@fredlwal Why did you enable it? It should remain disabled.

sudo ufw disable

I am amazed typed in /dev/sda and I am now in the process of uploading. You guys rock.

Yep, @Tom-Elliott helped me realize that over chat. Reboot, rinse, repeat. Thanks @Wayne-Workman for having a look-see. You can mark this is as solved.

Thank you Wayne. That did the trick.

Seems like people from the same place maybe? Posting at the same time about the same issue. https://forums.fogproject.org/topic/7000/image-cloning-fails

You can mark this is as solved. This was a case of good old SE linux set to enforce. Can’t believe it. Thanks @Tom-Elliott!!