@zpoling DHCP handshake looks good in the latest PCAP but as you said we won’t find out what was going on when it failed. More often than not those kinds of issues keep coming back until you really find and fix them. Make sure to capture the traffic when you see it happening next time.

Marking this as solved for now.

@Sebastian-Roth I’ve opened another thread about it. I ran a program that scans for DHCP traffic because I’m not too familiar with wireshark, but it does the same thing I imagine. After three hours, the only traffic showing up was our one and only DHCP server.

https://forums.fogproject.org/topic/12615/tftp-only-working-with-certain-vlans/2

@george1421 Fog has been working, but I haven’t had any machines to test a multicast on since we last spoke. I am going to attempt to image a classroom today and will report back.

Before this thread dies, I just want to mention how much better the newest Fog Client has been. The version offered with v1.4.4 always gave us issues of not restarting the computers correctly after imaging, resulting in needing a few manual restarts. Sometimes it wouldn’t join the domain or change the hostname properly either. v11.15 has been not shown any of these issues and has worked flawlessly for us so far!

@zpoling said in Error capturing image after increasing drive size:

So if I ever encounter an error, should I go to the Wiki first and not the forums?

All of the standard troubleshooting we recommend for standard problems is usually documented in the wiki as best as we can.
This list has all of our troubleshooting articles:
https://wiki.fogproject.org/wiki/index.php?title=Installation#Troubleshooting

But there are of course nuggets spread all over the wiki.

@sebastian-roth

Not to ignore you, but when I came in this morning, me and my boss had a conversation. He was messing around with another VM that was also having speed issues. He turned off VMQ under the Hardware Acceleration for the VM’s NIC on Hyper-V. His file transfer speed issue immediately went away. Naturally, I tried this for the FOG VM. When I booted up a machine, PXE boot ran as expected. I never saw the TFTP spinning, and both bzimage and init loaded instantly. However, I turned VMQ back on and tried again and the speed issue was still gone, so I don’t know if this was a problematic setting or not.

If the speed issue comes back, I will go ahead and do the tcpdump, unless you’d like me to do it now anyways just for sake of gaining info. FOG is running on the latest Ubuntu Server OS.

@Wayne-Workman I just wanted to update you on what I saw as I got it working.

In the multicast log, it was showing 0 tasks to be cleaned, but 3 tasks were found. Always. Every way I’ve seen here on the forums to destroy any udp casting tasks did not change the log continuing to show those 3 tasks. On two of the laptops I just happened to be trying to multicast that day, I took all source of power away and held the power button for 10 seconds. I then started a multicast task for those two, and they worked. Keep in mind that I haven’t been able to multicast for a few weeks now. I find it odd that that’s all I had to do, and on two random laptops at that.

Also with the timezone issue, the services not starting was happening before I even tried to set the timezone prefrences. I tried to set the timezone purely because my multicast log was showing dates four-five hours away. I don’t know the exact time, because the log is now reporting the dates correctly.

Thanks, Wayne!

@Wayne-Workman Good to know that the new client works smoother.
I just upgraded to trunk a few days ago and didn’t have the time to test yet.