Fog 1.2 deploy/download task finishes without actually imaging on Dell 790s HELP?
-
Try reuploading the image under debug modes and make this debug mode run fixparts <devicename> and correct the gpt bits that are left over.
-
Thanks for the lightning-fast reply, Tom. Would that be doing the fixparts /dev/sda1 and then writing the MBR with ‘w’?
-
i think you just do the device so:
/dev/sda (not a particular partition), but yes you would write the MBR back to the disk. Then all GPT info will be removed allowing the disk to receive the new layout properly.
-
First time I tried, it didn’t work. Did fixparts /dev/sda and wrote the new MBR. Uploaded image fine, but deployment did not work. Same issue as before with the task “completing” with no errors.
Going to try again and see if it works this time.
-
Still no luck. After defragging, running chkdisk, running fixparts, and re-uploading, the image still won’t deploy. Any ideas on where to look next?
-
Is deploy still doing the task completed far too soon?
-
It was still doing the task completed too soon. This morning, just for fun, I deployed a 7010 image (these are working fine) to a 790. It is currently imaging as expected. This points to something wrong with the original 790 image. I’m not sure what to do to rectify this. The 790 image was created by doing a fresh install of Win 7 which wiped the partitions and formatted the disk before installation. What do you suggest?
-
Update:
I prepped and uploaded an image from another 790 after defragging and doing fixparts. This image is currently deploying to 790. Issue may be solved.
-
Glenn, I am experiencing similar issues with a ThinkPad T420. Did you resolve this issue?
-
I have also had this issue with imaging. This may not be the case but if you upload a non resizable image and the destination drive is at all smaller than the one you uploaded from, you will get this error. Often times without any error that is visible. Partclone will spit out an error that lasts less than 1 second. Often times we receive refurbished devices with varying hardware, i.e. different size drives. When imaging 7 with FOG prior to 1.2.0 we had to do single disk multiple partitions. Now to circumvent the hard drive size issues we use single disk resizable and choose to upload everything. Again this is an old thread but saw it on the boards and thought I would offer my 2 cents
-
@tnunn
In my own experience, the image process completing without doing anything happened due to a weird MBR size that is made custom for some brands…
Can you tell us what the output is of these commands:
cat /images/<image name here>/d1.fixed_size_partitions cat /images/<image name here>/d1.minimum.partitions
