Fog 1.2 deploy/download task finishes without actually imaging on Dell 790s HELP?
-
Greetings all,
Fog .32 server bit the dust, so we installed Fog 1.2 on Xubuntu 13.10. This is using a proxy DHCP server. After some troubleshooting, the server will upload, download, and multicast to our Optiplex 7010s.
Our Optiplex 790s are another matter. I have successfully uploaded a 790 image, but am unable to actually download/deploy it. The BIOS has been updated to A18. I’ve tested many of the available kernels (some hang at points, some loop after init.xz, some kernel panic) but 3.16.x,3.17.x,3.18.x all seem to boot fine with no errors. Could there be a kernel argument needed, or something else? The problem is that the imaging process “completes” immediately. There are no error messages displayed and the usual “task completed, updating database, etc…” messages display before the system reboots. I know SOMETHING is being written, because when the download is run on a functioning Windows 7 machine, after the task the machine will not boot back into Windows. It seems like the MBR is getting wiped but nothing is actually being written. Pulling my hair out (if I had any) because all is well on the 7010s. I have several labs to image by the 19th and any help is greatly appreciated.
Thanks,
Glenn Wilson
Austin Community College -
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