After Network Issues and Reboot, New Image Attempts Are "0.00 iB" and "Invalid date"
-
I have just inherited this FOG server after the previous admin left the company. I’ve not worked with FOG before and It’s been a grand total of three days since I logged onto this box for the first time.
The server is Ubuntu 16.04.7 LTS, running FOG Version: 1.5.7. It is a VM running inside VSphere.
We had a networking issue and VSphere had to be rebooted. A number of VMs had to be restarted afterward, this FOG server included. The other VMs are fine, but since then the FOG server shows “0.00iB” and “Invalid date” for any new images our FOG admin tries to make. Old images appear to be fine, just an issue making new ones.
Needless to say, I’m crash-coursing the online FOG docs and been reading through this forum. Per some of the other topic listings herein, I found and corrected an issue with the timezone (reference ‘timedatectl’). Now the FOG logs are no longer showing time stamps that are +6 hours ahead of the server time. I also restarted FOGImageSize.service per some of the other topic entries I’ve found. Unfortunately nothing I’ve found seems to be a fix for this issue.
I would appreciate some guidance in trouble-shooting this issue. I’m also hoping that, having been looking at FOG for only three days so far, folks here might not slam me too hard for not having a clue and not knowing what info to post. : -p
-
@tmikecurry said in After Network Issues and Reboot, New Image Attempts Are "0.00 iB" and "Invalid date":
I’m also hoping that, having been looking at FOG for only three days so far, folks here might not slam me too hard for not having a clue and not knowing what info to post. : -p
Welcome to the forums. You’ve done a pretty good job describing the issue and the situation.
First I am wondering if it’s just a cosmetical issue of image size showing 0.00 in the web UI or if uploading/capturing new images is actually failing. Please login to the server via SSH, run the following commands and post output here:
ls -alR /images/#imagename# ls -alR /images/dev exportfs -v tail /var/log/fog/fogimagesize.log -
Thank you! Thank you!
.
Here is the first line’s output…$ ls -alR /images/E5591_12-1-22_W1022H2 ls: cannot access '/images/E5591_12-1-22_W1022H2': No such file or directory -
Second line output (kinda long)…
$ ls -alR /images/dev /images/dev: total 10 drwxrwxrwx 8 fogproject root 9 Dec 1 16:54 . drwxrwxrwx 17 fogproject root 19 Dec 1 16:54 .. drwxrwxrwx 2 fogproject root 12 Jun 11 2019 204747b05a36 drwxrwxrwx 2 fogproject root 2 Jul 13 2015 34e6d75da5c8 drwxrwxrwx 2 fogproject root 5 Jul 16 2015 34e6d75dace3 drwxrwxrwx 2 fogproject root 2 Mar 4 2019 c8f75029ca15 drwxrwxrwx 2 fogproject root 8 Mar 14 2019 c8f75029ca42 -rwxrwxrwx 1 fogproject root 0 Sep 14 2012 .mntcheck drwxrwxrwx 2 fogproject root 3 Apr 6 2017 postinitscripts /images/dev/204747b05a36: total 20379 drwxrwxrwx 2 fogproject root 12 Jun 11 2019 . drwxrwxrwx 8 fogproject root 9 Dec 1 16:54 .. -rwxrwxrwx 1 fogproject root 19 Jun 11 2019 d1.fixed_size_partitions -rwxrwxrwx 1 fogproject root 1048576 Jun 11 2019 d1.mbr -rwxrwxrwx 1 fogproject root 1032 Jun 11 2019 d1.minimum.partitions -rwxrwxrwx 1 fogproject root 15 Jun 11 2019 d1.original.fstypes -rwxrwxrwx 1 fogproject root 0 Jun 11 2019 d1.original.swapuuids -rwxrwxrwx 1 fogproject root 163199 Jun 11 2019 d1p1.img -rwxrwxrwx 1 fogproject root 13699602 Jun 11 2019 d1p2.img -rwxrwxrwx 1 fogproject root 5761513 Jun 11 2019 d1p3.img -rwxrwxrwx 1 fogproject root 0 Jun 11 2019 d1p4.img.000 -rwxrwxrwx 1 fogproject root 1032 Jun 11 2019 d1.partitions /images/dev/34e6d75da5c8: total 2 drwxrwxrwx 2 fogproject root 2 Jul 13 2015 . drwxrwxrwx 8 fogproject root 9 Dec 1 16:54 .. /images/dev/34e6d75dace3: total 5575117 drwxrwxrwx 2 fogproject root 5 Jul 16 2015 . drwxrwxrwx 8 fogproject root 9 Dec 1 16:54 .. -rwxrwxrwx 1 fogproject root 512 Jul 16 2015 d1.mbr -rwxrwxrwx 1 fogproject root 8419188 Jul 16 2015 d1p1.img -rwxrwxrwx 1 fogproject root 5696483482 Jul 16 2015 d1p2.img /images/dev/c8f75029ca15: total 2 drwxrwxrwx 2 fogproject root 2 Mar 4 2019 . drwxrwxrwx 8 fogproject root 9 Dec 1 16:54 .. /images/dev/c8f75029ca42: total 9852721 drwxrwxrwx 2 fogproject root 8 Mar 14 2019 . drwxrwxrwx 8 fogproject root 9 Dec 1 16:54 .. -rwxrwxrwx 1 fogproject root 1048576 Mar 14 2019 d1.mbr -rwxrwxrwx 1 fogproject root 302 Mar 14 2019 d1.original.uuids -rwxrwxrwx 1 fogproject root 36041977 Mar 14 2019 d1p1.img -rwxrwxrwx 1 fogproject root 2152091 Mar 14 2019 d1p2.img -rwxrwxrwx 1 fogproject root 10488225792 Mar 14 2019 d1p3.img.000 -rwxrwxrwx 1 fogproject root 857 Mar 14 2019 d1.partitions /images/dev/postinitscripts: total 3 drwxrwxrwx 2 fogproject root 3 Apr 6 2017 . drwxrwxrwx 8 fogproject root 9 Dec 1 16:54 .. -rwxrwxrwx 1 fogproject root 249 Apr 6 2017 fog.postinit -
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 -
@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
exportfslooks 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.
-
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.
-
@TMikeCurry Hmmm, I just wondered if this could be a simple disk space issue. Run
df -hon your FOG server console and post output here. -
@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.
-
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.)
-
@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.
-
@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 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.)
-
@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.