Deploy stops after restoring MBR
-
I’m running Fog v1.0.1 on Fedora 20 on a physical Dell laptop. I have imaged a Windows 7 physical computer and have it saved with no problems. Multiple Partition Image, Single Disk. When I try to download/push/deploy this image, to the same computer or to a different system, the same thing happens: It goes through the initial steps and gets to “Restoring MBR,” and then reboots. It never switches to the blue status bar screen, it never actually pushes the image. After the reboot the task is no longer active in Fog, and the PC boots to “No operating system found.” Any thoughts on what I might be doing wrong?
-
Update to this issue. I just wiped the fog server, installed Fog 1.0.1 on 14.04 and pulled another computer image. Then I pushed it to the next PC and the same thing happened. See attached image. After this happens, the computer reboots. There is no transfer of the image file. So far I have changed everything except the hardware I’m running the Fog server from, which appears to be working fine. Has anyone gotten this to work on v1.0.1?
[url=“/_imported_xf_attachments/0/817_20140522_185047.jpg?:”]20140522_185047.jpg[/url]
-
I’m getting the same issue. The image uploaded to the image folder in 3 files as I would expect but when pushing the image back to the same unit, it writes the MBR and ditches.
Using a Dell 4310, 3 ntfs partitions (restore, system and OS)
-
This is the behavior I was seeing, when my disk image used extended/logical partitions. If you are using logical partitions, then that could be the problem. You can check if logical partitions were captured by looking in the /images/IMAGENAME folder. There are files in there named d1p?.img. If you have any images with 5 or higher after the p, then you have logical partitions.
I’ve made a work around if you want to rebuild the init.xz file. If not, reinstall your source system with only primary partitions.
-
Fractal, I rebuilt the init’s in svn with these changes to them.
-
[quote=“fractal13, post: 28081, member: 24300”]This is the behavior I was seeing, when my disk image used extended/logical partitions. If you are using logical partitions, then that could be the problem. You can check if logical partitions were captured by looking in the /images/IMAGENAME folder. There are files in there named d1p?.img. If you have any images with 5 or higher after the p, then you have logical partitions.
I’ve made a work around if you want to rebuild the init.xz file. If not, reinstall your source system with only primary partitions.[/quote]
The systems that I tested as with all images I create are indeed primary partitions. 300mb System, 8gb Recovery and whatever else for the OS.
Upload takes the time I would expect from a FOG capture, but the deployment takes 1-2 minutes when it should be around 45 minutes (using a 100mb unmanaged switch for testing new FOG).
Peace
Stephen -
If these systems are Windows 7 and you’re trying to do resizable images that will not work. You will need to use multi partition image type to image them.
-
My source computers are Windows 7 using primary partitions only. And I have only used the “Multiple Partition Image - Single Disk (Not Resizable) - (2)” image type when creating the images. Any other thoughts, or techniques I can use to troubleshoot where it breaks?
-
So I did a Normal Wipe on my source system, reinstalled Windows and some software, uploaded it to the same image container, and everything works fine now. I’m not sure what the several systems I was trying to image had wrong with them, but apparently wiping the drive before installing Windows did the trick. Thanks for the help, everybody!
-
My guess is your disk was formatted and partitioned using GPT, but the image was in MBR format. These two don’t like playing with each other. I’m sorry, but happy to hear this worked fo ryou.
