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

@J3ff
The only way I’ve solved the problem was to upgrade to svn 6889.
After that the web ui kernel update has let me upgrade to this kernel

Official Published Kernels
Kernel - 4.5.0 TomElliott
Date : March 14, 2016
Version : 4.5.0
FOG Type: TomElliott
Arch Type: (x86_64)

Marking as solved (not directly a FOG issue)

@george1421 Thanks for testing and letting us know. Seams to work with the latest trunk so I am marking this solved now. Please let us know if you feel images are not moved properly (please check FTP first!).