@Tom-Elliott Looks like there was something wrong with yum. I did a basic yum clean all and that seemed to solve my issues with connecting to the mirrors. I’m progressing through the installation now. Thanks again for all of your help everyone!

@Tom-Elliott said:

@Mats-Nilsson said:

Problem solved. I installed a complementary Java Based Offline Proxy Server… [url]http://www.proxy-offline-browser.com/[/url]
(Java was bundled in Ubuntu) proxy ip 127.0.0.1 and port 8080 in Fog configuration and Firefox settings
I consider Fog to complex to be modified according to my wishes. It is clearly built to be online. To much work

Problem solved as stated.

However, your information is correct. I just wanted to know why the revival, are you having the issue?

I was having the issue, hence the reason I ended up on this page. I prefer the original method mentioned earlier in the page for an earlier version of fog without needing to download additional software. A question was raised regarding the newer version of fog, one to which an answer would have saved me some time. Upon finding the solution, I posted the results for anyone that comes upon this page to save time of their own. I honestly didn’t want to bring up a discussion, rather, just an FYI note for future viewers. The information I provided is valid and would be quite useless in a new thread.

@Wayne-Workman, @Kiweegie this should all be fixed now. Well a while ago but I’m just now updating lol.

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.