Image deployment stuck in loop on certain computers FOG 1.2.0
-
I have an image that I use for Dell Latitude E5520’s and E5530’s on FOG 1.2.0 (Ubuntu Server 14.10). The image deploys fine on E5530’s, but it doesn’t work on E5520’s. I either select “Full host registration and inventory” or “quick image” if it’s already been inventoried (I’ve tried both). After putting in the required passwords and input, it goes down for a restart like it should. But when it boots back into FOG, instead of downloading the image like it should, it just boots to the normal FOG menu.
I’ve also tried setting up a download task for it. When that happens, it goes through and sends its inventory, restarts, and boots into the FOG menu.
-
There is known instability with 1.2.0 and ubuntu 14.04 and higher.
However - I don’t think that this is your problem.
Can you check “Task Management” and verify that a task is actually being made?
If so, is the task disappearing or staying?
-
The task is created, then disappears. When I look in the FOG imaging log, every time I’ve tried to image it appears. They all last for 4 or 5 seconds. Only one out of the 10 events actually has the host name (the other 9 or so have blank hostnames).
-
@cg2916 This is a very strange issue. I would think that something about the data in your DB is causing this to happen, and I don’t think it’s anything with the PCs you’re imaging - but something about their names or the data that the registration is pulling.
I would recommend enabling remote access to MySQL and using HeidiSQL to view your fog database. There are some instructions here that will guide you in the right direction for enabling remote access: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL
Once connected, take a long, hard, and close look at the data in the hosts table and - if it’s there - the hostMAC table. Delete anything that looks obviously wrong. Pay special attention to the E5520 entries, but also look at the other entries too.
-
Did that, same problem. I did find out that during the imaging attempt, the entire “processing partition step” is skipped as shown here.
-
Solved it!
I captured an image from the 5530 which has a ~325 GB hard drive. The 5520 has a 250 GB hard drive. So fog was writing a partition table to the 5520 that was too big, so it wouldn’t recognize the partitions, so it wouldn’t image them. I’m gonna create a separate image for the 5520’s.
-
@cg2916 Why not just use “resizeable” image types? This image type was developed specifically for the problem you have. And if resizeable works, there’s absolutely no reason to not use it.
