As you all are probably well aware this should be fixed.

@Sebastian-Roth @george1421

Hi both, thanks for the pointer to log, that showed me issue. Had reinstalled from trunk and while fog password was ok per my records in the below locations I had like a complete rookie forgotten to reset password on the server itseld post upgrade… d’oh!

Storage Management > All Storage Nodes > Default Member > Management Password
Fog Configuration > Fog Settings > TFTP Server > FOG_TFTP_FTP_PASSWORD

cheers all
Kiweegie.

@Tom-Elliott He’s french, I’m helping him via the chat.

Never mind, apparently the guy that was told to make the changes only did it for one of our sites and not all seven. sorry for wasting your guys’ time.

This issue is resolved now.

@Wayne-Workman HI Wayne, thanks for this. I’ve upgraded to latest trunk and can confirm this now works as expected. Please mark call as resolved.

regards Kiweegie.

@Tom-Elliott Thanks - I updated after posting and it solved the issues, I’m on 5734 and all is working fine.

@Wayne-Workman you’re absolutely correct. 2094 is the svn rev at which we made the tag of 1.2.0. But if you’re pulling the tag instead of trunk, the rev will display the current rev of the repository, not the rev of the tagged released

Remoted in, and found that he is using a 32 bit OS. The value I was using to do the math was a function called intval which cannot do math beyond 32 bit scope (if the OS is 32 bit).

To fix, I just removed the intval function around the free/used space.

@arainero Thanks for reporting back so quickly! Great to hear that I was on the right track and this seams to be fixed for you. Please do not upgrade (run the installer again) yet as we are still waiting for others to report back if their (closely related) issues are fixed as well. Tom won’t update the init files till we hear back from them. So your issue would come back if you’d upgrade just now. Feel free to ask about upgrading here in this thread by the end of next week again. Hopefully we know more from the others by then and have updated the inits as well.

@JasonW said:

all used and unused space must be read by the FOG client.

Depends on the image type. Resizeable images resize the partitions first, so that only used space is captured.

When deploying an image, unused space is recognized in the image file and is much smaller than the size of the full hard drive. The compressed image is written to the FOG server very quickly.

Again, it depends on the image type. But generally image deployment is a lot faster than image capture.

Here’s a great article on the subject: https://wiki.fogproject.org/wiki/index.php/Image_Compression_Tests

@Sebastian-Roth said:

What on earth has subnetting to do with speed?

That’s what I thought. But if it’s fixed it’s fixed.

We have some Lenovos that are weird.

Pull the power cable and patch cable, hit the power button a few times, plug everything back up and auto-magically those weird ones start working…

@Sebastian-Roth
Sure, I’ll do it asap

@Jbob I confirm the problem has been resolved! Thnx a lot for the fix, keep up the good work!

@Tom-Elliott to further iterate and give some more specific information.

Unicast worked because while the order was not “proper” it pulled the partition number from the iterated item. Example /dev/sda1 would look for file d1p1.img. /dev/sda10 would actually look for and use d1p10.img.

In multicast this iteration happens but the data is sent by the server.

It did not scan for a particular file.

So in your case the commands were sent in expected order.

udp-sender would send in order
d1p1.img, d1p2, d1p10

It sent the commands in that specific order. The partition receiving the file was not matching the file it was receiving. /dev/sda1 would get d1p1.img properly but /dev/sda10 was getting d1p2.img. Hopefully that helps make sense of the problem.

Got this solved.

I removed both the CA and ssl directories totally, and then reran the installer with the recreate ca and ssl keys arguments, reinstalled the client once more and one reboot later, it’s working.

rm -rf /opt/fog/snapins/CA
rm -rf /opt/fog/snapins/ssl
./installfog.sh -yCK

@Developers I wonder if the installer properly removes the old stuff when the -CK arguments are used?

Got it fixed.

The Storage Management password was goof’d.

Corrected it to match, and it completed the TFTP upload.

Okay, it’s fixed but I’m still scratching my head about it.

I was having an additional issue where occasionally upon rebooting the server, MySql died and I had to manually restart it.
I fixed it by following these instructions (The part under “Ubuntu 13.04 14.04 15.04 and higher with FOG 1.2.0”).
I really can’t see how that fixed it but it’s somehow working now…

So consider the problem solved. Thank you for your time.

@monasmith529 said:

Yes it is a vm single nic vmxnet 3. No bridging.

No bridging??? Wouldn’t work I guess. Could you please explain a little more about your setup when asking a question next time. We cannot properly help you otherwise.

I added code last night to find out data and always failback to my suggested default in case it isn’t set.