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

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.