FOG And New Hard Drives

If you have had a hard drive crash, you most probably have gone out and bought a brand new one.

Now, when you try to deploy your FOG image to the new hard drive, everything seems to finish way too quickly. You don’t even see the blue screen where FOG is uploading/deploying the image. If you are lucky enough to spot FOG actually state “Task Complete”, that would be misleading, to say the least.

This is a known problem even with FOG 0.29 and unpartitioned drives. The simple solution is to manually make a partition on that drive, so that FOG can properly see it and use it.

I don’t know why this is a problem, but any partition tool can be used, just to be clear.

This entry was posted in FOG, Linux and tagged , , , , , , . Bookmark the permalink.

8 Responses to FOG And New Hard Drives

  1. Tim Plummer says:

    What do you mean by “manually make a partition”? Does it want a second partition? Is a hard-drive not partitioned by default? When Windows in installed, there is an option to either install to the current partition or delete the partition and create a new one(s).

    To clarify, I am imaging a lab of computers. I can upload the image fine but when I go to deploy, I get the situation you specify in your post. There’s not error, so it’s not like I know where to start.

    Help me random internet tech guy. You’re my only hope.

  2. Tim Plummer says:

    For anyone interested in this topic, you will also get this error in FOG 0.29 when attempting to deploy an image that was created using “Multiple Partition Image – All Disks” to a workstation that requires “Multiple Partition Image – Single Disk”. The difference between the two? No idea. I would think that “All-Disks” option would be a redundancy of “Single Disk” and would just image what was there, not crap out if there was only one disk. An error notice at least telling you this would be great, not just a brief blip that says, “Task Complete!”

    More reference on image types can be found on the FOG Wiki, but it doesn’t really explain a whole lot.

  3. CyberKenny says:

    New standalone drives normally does not come pre-partitioned unless they are part of an external cabinet or so. They are also uninitialized, which means another turn of disk operations has to be done, FOG apparently have problems with this.

    I wrote that one should make a partition on new drives because then you also would have to go through initializing them first, just to be sure. The way to manually initialize such problematic drives is either through another working machine or perhaps by using a linux boot cd.

    The Single Disk vs All Disks issue is certainly interesting. I always went with All Disks and although this did happen a few times, I haven’t had much of a problem with it. I’m thinking of switching my habits to use the Single Disk image type because of this.

    Our computers at work are mostly HP and I must say that FOG has been invaluable in the cloning process for us!

    BTW, have you tried this with the new FOG 0.30?

  4. Tim Plummer says:

    I have it downloaded but not implemented. I’ve read some great things about it. I’m trying to complete a project before load it just in case it were to mess something up. But then again, every time my boss seems to touch the FOG server, something seems to go wrong. I’m beginning to think he’s bad luck. Or trying to keep me busy.

    I’m also curious on how FOG handles Boot Partitions. I just deployed an image to a bunch of Netbooks that were fresh out of the box and had not had Windows fully installed yet and after the image processed, when they boot back up they act like Windows7 is booting up for the first time and then immediately shut off and are stuck in this loop until you shut them off. So I don’t know if either the image process experienced an error and the image didn’t process all the way or if it’s a problem with a boot partition.

  5. Tim Plummer says:

    Booted up PartedMagic on a USB drive, deleted all partitions, created a new NTFS partition, tried to image and got the same outcome as listed above. I’m guessing this has something to do with Fog 0.29 and Win7. I deployed the same image on hundreds of netbooks with Fog0.28 and had minimal problems, specifically I never had this error happen.

    I ran FogPrep and am now re-uploading a new image. Luckily the Netbooks had DeepFreeze running on them so there should not be too much user data bogging it down.

    I find the initial problem you were having strange because when I deleted the old partition and created a new one, FOG still resized this to match the old size when the image was deployed. I’d be really upset if I had payed for this software, but for being 100% free, I’m still impressed with what it can do.

  6. Dave C says:

    I’ve the same problem unfortunately, but using fog 0.30. I’m maintaining a windows 7 reference build in a virtual machine (VMWare ESXi 4.0), I made it a single partition installation (no system reserved). Tried various kernels in fog but no joy, uploads just flash by way too quickly and completes without any errors.

    I was about to try fog 0.29 but luckily found your site, guess this will be an issue.

  7. Dave C says:

    Been trawling through the fog forum and a few posts mentioned having problems imaging disks that were less then 60GB and increasing resolved. I’m having difficulty increasing my disk as it’s a VM under ESXi but it’s something you guys can try out and let us know.

  8. Patrick says:

    Just found this article helpful. On Lenovo M73 desktops with RMA drives arriving, they don’t have a partition. Fog 1.2.0 didn’t like that. Ended up using mini tool partition wizard bootable (free) to get a partition on it. Parted Magic costs money!

Leave a Reply

Your email address will not be published. Required fields are marked *