No image file(s) found that would match the partition(s) to be restored (preform Restore)
- FOG Version: v1.3.5, v140-RC-1
- OS: Windows 10
- Service Version:
I just finished the migrating my fog server from an old server to a new second server (both VM).
As part of the migration, I updated both servers to 1.3.5 (RC-1 I think). following the documentation on the Wiki, the migration worked great. I am able to capture images and the database works fine. However, I have found I cannot deploy images. I get the below screen.
I have tried everything I can think of and I have search through the forums without success. I thought it was an issue with the new server then I found it was also happening on the old server too. (possibly with the version upgrade?)
Here are the steps I have taken:
-Delete image files from new server and recopy the files from the old server.
-upload and deploy new image on the new server.
-reset all the settings for the test image in the Fog Web interface.
-Upgrade to Fog version v1.4.0-RC-1.
-Tried Several several different kernals.
-Spin up completely new VM, install fog server (v1.3.5) from Scratch, boot test machine and register it, create new image, upload testmachine image to test VM (this test machine is the only image and host in the fog server).
I found one other thread about this but it hasn’t been touched since Janurary.
As of now, my entire Fog imaging solution is not working and I need to get it back up.
There are no storage nodes. Any help would be greatly appreciated. Here is a screen shot of the error.
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.
@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.
- What is the best method of imaging when dealing with UEFI Computers?
- Did anything change in Version 1.3.5+ that changes the way Fog handles UEFI computers?
Thanks for all your help!
I have a correction. the Model having the imaging issue is an Optiplex 990 SFF (not 790 DFF)
@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
-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/
-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
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.
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?
@knichols Here’s a helpful article for solving this: https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit
@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.
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.
Mind trying from “resizable”?
The image Type is already set to "Multiple Partition Image - Single disk (Not Resizable) - 2"
Is that what you meant?
@knichols As this image is not a “resizable” type, would you mind switching it out to non-resizable and try again?
Thank you for your replay.
Here is the output:
<username>@fog-server:/images/KenTestImage$ ls -l /images/KenTestImage/
-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
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/KenTestImagefrom the server?