After Network Issues and Reboot, New Image Attempts Are "0.00 iB" and "Invalid date"

[TMikeCurry]

And the third and fourth output, plus a note of what I noticed…

$ sudo exportfs -v
/images         <world>(ro,insecure,no_root_squash,no_subtree_check,insecure_locks,fsid=0,sec=sys,ro,no_root_squash,no_all_squash)
/images/dev     <world>(rw,async,insecure,no_root_squash,no_subtree_check,fsid=1,sec=sys,rw,no_root_squash,no_all_squash)


$ tail /var/log/fog/fogimagesize.log
[12-06-22 3:45:36 pm]  * Trying image size for: E5591_8-2-22_W1021H2, ID: 76
[12-06-22 3:45:36 pm]  * Getting image size for: E5591_8-2-22_W1021H2.
[12-06-22 3:45:36 pm]  | Size: 34626453640
[12-06-22 3:45:36 pm]  * Trying image size for: E7450-W10Entx64_7-31-2019, ID: 67
[12-06-22 3:45:36 pm]  * Getting image size for: E7450-W10Entx64_7-31-2019.
[12-06-22 3:45:36 pm]  | Size: 26900243077
[12-06-22 3:45:36 pm]  * Trying image size for: E7480_10-11-2018_W10-1803, ID: 51
[12-06-22 3:45:36 pm]  * Getting image size for: E7480_10-11-2018_W10-1803.
[12-06-22 3:45:36 pm]  | Size: 14882700956
[12-06-22 3:45:36 pm]  * Completed.


# Noting in FOG wui it says "E5591_12-1-22_W1022H2 - 81"
# fogimagesize.log lines which refer to "81" are:
[12-06-22 3:45:36 pm]  * Trying image size for: E5591_12-1-22_W1022H2, ID: 81
[12-06-22 3:45:36 pm] | E5591_12-1-22_W1022H2: Path is unavailable

[Sebastian Roth]

@TMikeCurry Ok, so from the first output we see the image really does not exist. While the last output is showing the FOGImageSize service to operate just fine. So it’s definitely not just a size issue.

The output generated by exportfs looks perfectly fine.

The file listing of /images/dev/ shows some “stale” uploads/captures but all of them are pretty old (see the timestamps). Images being captured are stored in /images/dev/#macaddress#/ and will be moved to /images/#imagename#/ when uploading is finished. If something goes wrong with the image capture you should see a directory in /images/dev/ with a more recent timestamp really.

So my guess is the capture fails way earlier and never gets to the point where /images/dev/#macaddress#/ is being created. You can try cleaning up that directory just to make sure. But I don’t think this will fix anything: rm -rf /images/dev/[23c]* (do this on your own risk)

Beside that you need to talk to the people doing the image capture and make them take a picture of any error seen on the screen. Post that picture here and I am sure we’ll figure it out.

[TMikeCurry]

I’ve removed the stale uploads/captures from /images/dev/ that are dated prior to 2019. So far it doesn’t look like anything on the server or in FOG got upset by my doing that.

I contacted the person doing the image captures and she said she’ll re-run one and capture any messages or warnings that pop up. Then I’ll post them here.

Thank you again. Your responses are very appreciated.

[Sebastian Roth]

@TMikeCurry Hmmm, I just wondered if this could be a simple disk space issue. Run df -h on your FOG server console and post output here.

[TMikeCurry]

@sebastian-roth That was an issue to start with (before I posted here). I had already added another 500gig to the disk that /images/ is on. It has 570gig free. The image they are trying to take is similar to the previous one and should only be about 540gig in size.

[TMikeCurry]

The FOG admin has tried making another image. We noticed that the image name they gave it – E5591_12-13-22_W1022H2 – was not the image name displayed when the task finished (and failed).

The name displayed at the end of the process was E5591_8-2-22_W1021H2. This was the name of the previous image they made months ago.

Addendum: They are imaging the same laptop that was used for the “…8-2-22…” image. The laptop was updated and now they want to take a new image. (I don’t know if this makes any difference or is useful info, though.)

[Sebastian Roth]

@tmikecurry said in After Network Issues and Reboot, New Image Attempts Are "0.00 iB" and "Invalid date":

The name displayed at the end of the process was E5591_8-2-22_W1021H2.

Then the old image is still associated with the host object I suppose!? Please check the hosts’s settings in the web UI to make sure which image is associated to it.

[TMikeCurry]

@sebastian-roth Yes! That looks to have been the issue.

Our FOG admin then had FOG re-inventory the hardware on the source laptop.

After that, she was able to complete the image successfully from the source laptop. Then she used that image for a brand-new target laptop. It works!

Thank you, thank you!

[TMikeCurry]

@tmikecurry So now, for my edification…

…did this occur because we needed to re-inventory the hardware on the source laptop? (So it would stop associating it with the earlier image?)

…or did this more likely occur from some complication of the networking issues we had a while back?

(At this point I’m thinking this was because we needed to re-inventory the hardware… networking issue and reboot wasn’t part of the problem.)

[Sebastian Roth]

@tmikecurry said in After Network Issues and Reboot, New Image Attempts Are "0.00 iB" and "Invalid date":

…did this occur because we needed to re-inventory the hardware on the source laptop? (So it would stop associating it with the earlier image?)

In FOG the inventory has no association with imaging directly as far as I can tell. So I think setting the correct image in the host object was actually the solution.