No image file(s) found that would match the partition(s) to be restored (preform Restore)

[knichols]

[Tom Elliott]

This really sounds like the images haven’t moved to their respective locations, or at least not properly.

What’s the output of ls -l /images/KenTestImage from the server?

[knichols]

Thank you for your replay.

Here is the output:
<username>@fog-server:/images/KenTestImage$ ls -l /images/KenTestImage/
total 11291024
-rwxrwxrwx 1 root root 1048576 Mar 27 15:07 d1.mbr
-rwxrwxrwx 1 root root 1342424 Mar 27 15:07 d1p1.img
-rwxrwxrwx 1 root root 12772323 Mar 27 15:07 d1p2.img
-rwxrwxrwx 1 root root 11454954 Mar 27 15:10 d1p3.img
-rwxrwxrwx 1 root root 11535373904 Mar 27 15:10 d1p4.img
-rwxrwxrwx 1 root root 860 Mar 27 15:07 d1.partitions

[Tom Elliott]

@knichols As this image is not a “resizable” type, would you mind switching it out to non-resizable and try again?

[knichols]

The image Type is already set to “Multiple Partition Image - Single disk (Not Resizable) - 2”
Is that what you meant?

[Tom Elliott]

Mind trying from “resizable”?

[knichols]

Making that change did fix deploying issue so it now images. However, the computer is not bootable after deploying the image.
Also, I am now unable to upload images. Below is the screen shot.

Thank you for your continued help.

[Tom Elliott]

@knichols As this is windows, you probably want to follow the information it’s presenting.

Most often, this is because Windows 10 maintains the disk in a kind of “hibernate” state. This allows the device to boot faster but also makes imaging difficult for exactly the reasons you’re seeing.

[Wayne Workman]

@knichols Here’s a helpful article for solving this: https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit

[knichols]

Hey Guys,
Thank you both for the information and help with this issue. Thank you also for the link.

However, if I make the changes you are asking I will have to remake all my images and I am not quite willing to do that yet.

I did find something else odd though.
I was able to find a Backup of the Fog VM from when everything still worked. I loaded that VM and tested. I have the same issue.

I replaced the Hard drive and had the same issue. I got another machine of the same model (optiplex 990 SFF) and had the same issue. I also changed the images to a production image and that image also revieved the error.

I pulled two machines (Optiplex AIO 9030 and Optiplex 790 Micro) and they both imaged correctly without issue!

Is there a reason that 1 computer model (Optiplex 790 SFF) will not image?

[george1421]

@knichols

What is your legacy FOG server version?

On the system that doesn’t image, can we get a screen shot of the image files on the FOG server? These would be in /images/<image_name> directory. We are trying to compile a list of imaging issues with FOG 1.3.5. We need to collect some background information on the existing disk structures.

[knichols]

@george1421 I have Tried Fog servers 1.3.5-RC1, 1.3.5, 1.4.0-RC1.

Here are the two images that are for this model of computer (1 is production and 1 is for Testing- neither work) :

root@fog-server:/images/KenTestImage# ls -l /images/KenTestImage
total 11291028
-rwxrwxrwx 1 root root 1048576 Mar 29 09:42 d1.mbr
-rwxrwxrwx 1 root root 1342424 Mar 29 09:42 d1p1.img
-rwxrwxrwx 1 root root 12772323 Mar 29 09:42 d1p2.img
-rwxrwxrwx 1 root root 11454954 Mar 29 09:46 d1p3.img
-rwxrwxrwx 1 root root 11535373904 Mar 29 09:46 d1p4.img
-rwxrwxrwx 1 root root 860 Mar 29 09:42 d1.partitions
root@fog-server:/images/KenTestImage# ls -l /images/PVOptiplex990/
total 20610920
-rwxrwxrwx 1 fog root 1048576 Mar 23 16:21 d1.mbr
-rwxrwxrwx 1 fog root 1001811 Mar 23 16:21 d1p1.img
-rwxrwxrwx 1 fog root 12770930 Mar 23 16:21 d1p2.img
-rwxrwxrwx 1 fog root 4506990 Mar 23 16:26 d1p3.img
-rwxrwxrwx 1 fog root 21086238649 Mar 23 16:26 d1p4.img
-rwxrwxrwx 1 fog root 860 Mar 23 16:21 d1.partitions

[knichols]

I have a correction. the Model having the imaging issue is an Optiplex 990 SFF (not 790 DFF)

[knichols]

@Tom-Elliott After more testing I believe I found the issue. The Issue seems to be with Machines that use UEFI. I get the error while trying to restore a “Not resizable Image” to a System that has UEFI.

I followed your advise and set the image to “resizable” and the deploy image does work. I was able to fix the Upload error I received earlier by running sys-prep before uploading the image.

However, I seem to have ran into 1 final issue using “Resizable” type with a UEFI computer. It appears that if I apply image made on Computer A to Computer B, the computer will not boot. I have to preform a one time boot menu, choose the UEFI option and that seems to fix the boot issue. the computer can reboot and it remembers the Boot option.

1. What is the best method of imaging when dealing with UEFI Computers?
2. Did anything change in Version 1.3.5+ that changes the way Fog handles UEFI computers?
   Thanks for all your help!

[knichols]

Hey Guys,
Looks like switching to Single Disk resizable fixed the Imaging issue. And updating to 1.4-RC4 seemed to fixed the UEFI Boot Issue I mentioned earlier. Thanks for the help guys.
Ken

[AshiOni]

For the record, I had exactly the same issue. All of your screenshots could have come from my experience. What I found is the original hard drive was larger than the hard drive being imaged to. Even with the “resizing” of the partition during the capture it wouldn’t redeploy to any drive smaller than the original. I fixed this by booting up PartedMagic and doing a manual RESIZE & MOVE of the partitions. It then would work.

Issue:
Win10 will not redeploy
During redeployment the following error is given: No image file(s) found that would match the partition(s) to be restored

Resolution:
Manually resize the drive using PartedMagic or similar tool. Then move the blank / white space left on the drive to the end of all the partitions and save. Capture the image using pxe / fog & redeploy as needed.

Hope that helps.

[george1421]

@ashioni Thank you for providing input on this matter.

Also if you are still running FOG version before 1.4.1 then you will continue to have this issue. The problem should have been resolved in 1.4.4, so its recommended that you upgrade to the latest stable release of 1.4.4.

[AshiOni]

@george1421

I’m on 1.4.4 currently.

It’s an easy enough work around to manually fix. Took up most of my day to identify, but it is resolvable.

[knichols]

Hey Guys,
Thank you for your replies. The issues I stated here was because of the UEFI being enabled. UEFI Didn’t like the fixed partition sizes. As the FOG Developers stated, changing the images to “Resize partition” fixed the issue for UEFI Machines. Using this method, I was able to make an image on a 500gb HDD and deploy it to a 256 SSD without issue.
In regards to the “not booting after successful restore from UEFI”, that issue was limited to older Dell modals that have never booted to UEFI before. Once i selected the boot device the computer booted fine every time after that. They booted even after subsequent re-images.
I am currently running version 1.5. RCx.

Thanks for all the help.