One specific laptop either freezes or crawls in image deploy or capture
-
Hello Fogworld,
I have been using Fog for 10 years at a school that was using it before I arrived. In 10 years, I have imaged close to 1,000 desktops and laptops and I have come across a unique problem with one single laptop. In both deploying and capturing a Fog image, the transfer is either glacially slow or just stops. For example, my latest failed attempt is running now and at the 30-minute mark, it is at 0.63% of the main partition. Often, it just comes to a complete stop, sometimes even in the first small partition.
Details:
Dell Latitude 5430, a very typical laptop for us. There is nothing exceptional about it. It’s sister laptop has worked perfectly fine for a year.If I install Windows and build out the machine, it works fine. All networking seems up to speed. The machine functions without error. It is only during Fog processes that it has an issue. That makes it close to useless to me.
I have imaged more than 100 computers since we bought this machine and they are all running fine, so can it really be a Fog issue?
I swapped hard drives with a known good drive and it still acted the same way, so it is not a writing to the HD issue, nor would that explain an issue with the image capture phase.
All drivers and Windows updates are in place.
Has anyone ever come across a similar issue? Any suggestions? Is there some process or device that Fog uses for imaging that would not affect other operations of a Windows computer? What am I missing?
I will try to get Dell Support on it, but frankly, I haven’t even figured out what to complain about. This seems very specific, and the machine works fine otherwise. I will be careful in my wording with them, but I am curious if anyone has experienced such an issue.
Thanks for reading,
Dave
-
@sweeperdave Over the years of using FOG, I have encountered situations that are similar to this. You can image several computers that are the same model but one or maybe a few will image slower than other machines.
When this happens I usually start by inspecting the ethernet port on the computer. Several times I’ve found the pins to be bent or damaged. The next thing I check is if the fan is running during the imaging process. If it’s suspiciously quiet, I then run tests to see if the fan is working at all. In a few cases, replacing the fan resolved the issue. If the fan seems fine, I usually just give up. I image another device of the same model, then swap the imaged drive into the computer that won’t image. Inconvenient, but it allows you to still use the device and move on. It’s very rare that I ever have to resort to doing this. I’ve always chalked it up to hardware issues on the computer.
-
@sweeperdave So a machine of the same make model (and roll out) works perfectly fine, but this one machine has an issue?
(Not in windows of course, but just trying to understand the issue.) I see @fogcloud has written, and I apologize for missing this sooner.
I suppose “details” are what we need to potentially be able to help.
If suddenly ALL of the same make model (equipment roll out) are acting up, I would have to ask:
“Did you update kernels recently?” but if that’s not the case we are pretty sure it’s limited to this one machine.
At that point, I would say take a known working system, look at the bios configuration and see if there’s anything different in this strangly acting system. (If I had to guess it’s related to VTx technology enabled or something like that on this machine vs the other machines.)
Be cognizant of BIOS/Hardware Firmware versions and what not as well as those can also play a role in the overall operation of the device. Since replacing the drive and testing the same machine produces the same problem I’m leaning more specifically to the BIOS itself here.
This is just my experience.
If everythign else is effectively 1:1 from another, then this could just really be a faulty machine that only presents itself in the imaging process.