@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 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!
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 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.
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.
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
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
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
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