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

Should be fixed in current. I’m no longer flushing all the output.

Registration works fine now - We’ve pointed the separate buildings DHCP 66 and 67 to the main fog server. Works.

@Tom-Elliott said:

What VM is FOG in? I may need to remote in once I get back from my appointment to see your issue. Right now, Wayne’s issue is not related to fog in any way. It is because he’s running a hyper-v VM and the systemd-udev is using all the cpu trying to set a file it can’t access.

Our two FOG servers are both physical boxes.

https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

If the filesize a are the same this would explain why they where in defunct status. The commands run but have no work to perform. I believe the defuncts you’re seeing are simply because of this. If you’re daring you could delete one of the images from the annex node and restart the replicator on the master. Then check your bandwidth and see if things are happening.

Remoted in and fixed.

Issue is ubuntu had docroot of /var/www/ but really the files existed in /var/www/html. So the current was placed in /var/www/fog, but web was looking at /var/www/html/fog.

Fixed by removing /var/www/html/fog, moving /var/www/fog /var/www/html/fog, and creating a link from /var/www/html/fog to /var/www/fog.

Seeing as the problem of getting the boot menu was the problem of this posting, I’m solving this thread.

Please create a separate issue in regards to the registration problem. You can link back to this thread too so you don’t have to rewrite all the details. Just give the new posting a title that says (Using /dev/sda) Host Registration Hung or something like that.

Thanks as always Tom for the quick fix - all good now, this can be marked as solved.

Ref the Apache and php files error - think that was an additional symptom of the sed missing character.

Well… if we didn’t hear from him this morning, that probably means the FOG server stayed up all week. Thread solved.

not yet, been on the road will test when I get back on Monday

Hopefully things will be better, though I don’t have a good way to test. Please let me know. I changed up the logic a bit and made the taskqueue class use a try/catch statement too.

@Mark-Buteyn What is your internet connection speed (up and down)?

(Just trying to draw a connection here) Do you have known intermittent internet access issues? I’m pretty sure they are still using wget to pickup the kernels and inits. I wonder if we added a longer wait time for wget that would resolve (or at least mask) the issue.

@Wayne-Workman Thanks, I needed to change the time under General Settings. Thanks again! I think I’m golden now.

Peace!