How to identify or check the integrity of an image?

[jlouie.smart]

I recently Captured an updated image of a machine, (done this about a dozen times before without issue). This time, however, the image does not restore, I get a No image file(s) found that would match the partition(s) to be restored (perform Restore)

How would I diagnose the issue to recover the image?
Is there a way to get the exact settings the image was made with?

Here are the details…

• Windows 10 machine.
• Machine the image was taken off of now no longer boots, (cannot find a boot device). From a failed Deploy???
• The image logs on the fogserver says the Capture was “Completed”
• I checked the directory and I was able to gunzip the image file without issue, (so I assume the Capture completed).
• There is a possibility when unsetting / setting the image from and to Protected I might have fat fingered another setting, (I am currently cycling other Image Types and Compression values to try to use the image).

Image structure is as follows:

-rwxrwxrwx 1 root root     1048576 Nov 13 13:50 d1.mbr
-rwxrwxrwx 1 root root 16582559265 Nov 13 14:02 d1p1.img
-rwxrwxrwx 1 root root         249 Nov 13 13:50 d1.partitions

[Sebastian Roth]

@jlouie-smart Which version of FOG is this? Have updated recently? Just asking as you say it worked before. What image settings you have set? Post a picture of the web UI image settings of this host’s image. As well post the contents of d1.partitions here in the forum.

[jlouie.smart]

We upgrade in July/Aug to 1.4.3. Images were updated as recently as last week.

label: dos
label-id: 0xa67d6c3f
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=   111908864, type=7, bootable
/dev/sda2 : start=   111910912, size=      921600, type=27
/dev/sda3 : start=   112834560, size=   121604096, type=7

[Sebastian Roth]

@jlouie-smart Hmmmmm, in that partition table we see three partitions. But in your image directory there is only one d1pX.img file. This makes FOG bail out as it thinks there is something really wrong with the image. Are you sure the capture process went fine? I somehow doubt this is the case. Maybe schedule another debug capture task and slowly step though it reading all the messages on screen and keeping your eyes open for “errors”!?

[jlouie.smart]

@Sebastian-Roth

Found out the issue. The problem was that the drive was wiped on the machine, (some bad page navigation triggered the link ?node=host&sub=deploy&id=32&type=19 instead of ?node=host&sub=deploy&id=32&type=1 which is a full disk wipe. Note: Even though the Wipe Full Disk wasn’t visible, it was a callable and listed link on the Basic Task page.

So the error presented was due to the partition on the computer being zeroed out and not of the image.

The capture was successful, (only listed Partition 1 to be captured), as I would expect.

Some things to improve the process.

A remote wipe of the disk seems to easy to do, especially when the image Captured is only of one partition.

The error message presented can be less cryptic… maybe a listing of the expected partition table and the existing partition table and a suggestion on where and what to check would help, (currently we only dump the command used and expect the user to figure out what to do next).

I would like to see an ability to check the image integrity, (some checks to indicate if the image is corrupt or not). Not helpful in my case but prevents people from spinning their wheels.

Overall, @Sebastian-Roth thanks for your quick reply and assistance.

[Sebastian Roth]

@jlouie-smart We don’t actually support versions older than the current stable 1.4.4. Although we would like to it’s just too much to handle for us on a voluntarily basis. That said I kind of get the idea that what you describe would be valid for FOG 1.4.4 as well so I’ll still try to give you an answer.

My fault. In a rush I must have overlooked the image being set to “Partition 1 only”. So that makes partly sense. Don’t think setting “Image Type” to “Multiple Partition Image - All Disks” should hurt I really wonder why you have this set.

some bad page navigation triggered the link… Note: Even though the Wipe Full Disk wasn’t visible, it was a callable and listed link on the Basic Task page.

Maybe I am on the wrong track with this but to me this sounds like you have been using some kind of web automation tool (e.g. Selenium) to schedule the task. Other than that I couldn’t think of why you’d hit WIPE when meaning to do a normal DEPLOY. Sure the link to schedule a wipe task is on that same page further down in “Advanced Tasks”. But usually no one goes there if he only wants to deploy. So I don’t get what’s wrong.

The error message presented can be less cryptic… maybe a listing of the expected partition table and the existing partition table and a suggestion on where and what to check would help, (currently we only dump the command used and expect the user to figure out what to do next).
I would like to see an ability to check the image integrity, (some checks to indicate if the image is corrupt or not). Not helpful in my case but prevents people from spinning their wheels.

This is open source. Feel free to help implementing those things if you like to see those being added to FOG. We encourage people to get involved and work on FOG to improve and extend its functionality.

[jlouie.smart]

@sebastian-roth: yes, we have a web automation tool that deploys the images nightly.

As for contributing, I am not sure the depth of my knowledge of the project is enough to contribute as of yet. Thanks, I will contribute what I feel I can. You guys are doing great work.