Images not being Deployed



  • Fog Server Details:

    • Ubuntu 12.04
    • FOG Git 4980

    The Issue:
    When I go to deploy an image I receive this:
    FOG Error.bmp

    Everything looks alright but the image isn’t actually being brought down.
    It erases my partitions and then the task is complete.
    I’ve tried different images and different machines.

    Any help is appreciated!


  • Moderator

    I guess I should clarify. We use MDT to create our reference image on a VM with a 40GB disk. During the MDT deploy task we apply all of the windows updates. If we are making a fat image then we install the additional software at that time (using a fat image task sequence in MDT). When we have the image the way we want it, then we sysprep it and capture the image. At this capture point we still only have a 40GB disk. So we deploy that 40GB disk to the target computer and then once on the target computer we extend the disk with diskpart.

    We do it this way because we rebuild the golden image each quarter. If you have everything setup to create your reference image automatically, the actual hands on time is very small. What takes the most time from start to finish is windows updates. So far with the WIndows 7 updates it takes overnight to apply them all (~14 hrs).

    While I got a bit off point, the key is to deploy a smaller image to your client computers than their smallest disk size then extend their logical disk to the physical size during the cleanup process.



  • @george1421 said:

    @jquilli1 said:

    I was told to use “Multiple Partition Image - Single Disk (Non-resizable)” if I’m capturing an image that’s Windows 7 or above. Have I been mistaken this whole time?

    While I quickly scanned this thread, I didn’t see what client OS you are deploying. I can say that we deploy “Multiple Partition Image - Single Disk (Non-resizable)” to all of our Win7 and Win8.x (and soon Win10) systems (MBR only). The one thing that we DO is create our reference image on a VM with a small hard drive (40GB) that way we are sure it will deploy correctly to any hardware we might have in the future. 40GB is sufficient for windows+updates+core applications. When we deploy that 40GB image to a computer with a 128GB (or larger) drive, initially the logical hard drive will be 40GB. In the SetupComplete.cmd file we launch a command script to window’s diskpart.exe utility to extend the logical drive to the size of the physical disk. While we haven’t had to do that with linux there are commands to do that too.

    To date we’ve deployed several hundred systems using this method, with FOG and a few other deployment tools.

    I basically do a hybrid of that. I create the initial image in a VM with 40GB hdd and then deploy it to our workstation. From there I need to add a bunch of other software, drivers, etc… During that first deploy in the unattend file I have it set to extend partitions so it allocates the rest of the free space. After I have the system how I want I then sys-prep and recapture to deploy to the lab.


  • Moderator

    @jquilli1 said:

    I was told to use “Multiple Partition Image - Single Disk (Non-resizable)” if I’m capturing an image that’s Windows 7 or above. Have I been mistaken this whole time?

    While I quickly scanned this thread, I didn’t see what client OS you are deploying. I can say that we deploy “Multiple Partition Image - Single Disk (Non-resizable)” to all of our Win7 and Win8.x (and soon Win10) systems (MBR only). The one thing that we DO is create our reference image on a VM with a small hard drive (40GB) that way we are sure it will deploy correctly to any hardware we might have in the future. 40GB is sufficient for windows+updates+core applications. When we deploy that 40GB image to a computer with a 128GB (or larger) drive, initially the logical hard drive will be 40GB. In the SetupComplete.cmd file we launch a command script to window’s diskpart.exe utility to extend the logical drive to the size of the physical disk. While we haven’t had to do that with linux there are commands to do that too.

    To date we’ve deployed several hundred systems using this method, with FOG and a few other deployment tools.


  • Moderator

    @jquilli1 Well, just try. See what happens. Fog trunk has made great advancements in this area. Maybe 1.2.0 has quirks… I know it has quirks with manufacturer MBRs and recovery partitions.

    I’ve uploaded resizeable images for Win7 MBR, Win7 GPT, Win8.1 MBR and Win8.1 GPT with zero problems. I’ve also uploaded resizable images of Fedora 21 & 22 Workstation, CentOS 7, and Ubuntu 15.04. When uploading resizeable Linux images, you just need to build the image using Ext4 for everything but the swap partition.

    I’ve also uploaded a resizable XP image once! lol

    But, I make my images from scratch, I format and Delete all existing partitions, and make my images from scratch. I vehemently resist the bloatware and poor configuration that manufacturer images ship with.



  • @Wayne-Workman said:

    @jquilli1 You know a very simple solution is just to use re-sizable image types… I find there is almost never a reason not use them.

    I was told to use “Multiple Partition Image - Single Disk (Non-resizable)” if I’m capturing an image that’s Windows 7 or above. Have I been mistaken this whole time?


  • Moderator

    @jquilli1 You know a very simple solution is just to use re-sizable image types… I find there is almost never a reason not use them.



  • @Uncle-Frank said:

    @jquilli1 Not weird but pretty simple: 80GB is not always exactly 80GB with all vendors! Only a few more or less sectors make a difference. You might be able to make things work when using the Seagate (probably a little smaller) as your master disk. If you are really keen you can boot PC with the two different disk type in FOG debug mode and run fdisk to see the exact sector count:

    fdisk -l /dev/sda
    
    Disk /dev/sda: 80 GB, ....... bytes
    255 heads, .... XXXXXX sectors
    ...
    

    Compare the numbers of sectors and/or bytes

    I figured that was the case as I know not 80GB isn’t really 80 sometimes. I’ll give that a shot and see what I can find. So far it seems like that was the issue but will report back with actual results!


  • Developer

    @jquilli1 Not weird but pretty simple: 80GB is not always exactly 80GB with all vendors! Only a few more or less sectors make a difference. You might be able to make things work when using the Seagate (probably a little smaller) as your master disk. If you are really keen you can boot PC with the two different disk type in FOG debug mode and run fdisk to see the exact sector count:

    fdisk -l /dev/sda
    
    Disk /dev/sda: 80 GB, ....... bytes
    255 heads, .... XXXXXX sectors
    ...
    

    Compare the numbers of sectors and/or bytes



  • So I decided to look at the hdd brands just out of curiosity. The computers are all the same model except the hdds. Everyone with a Western Digital took the image but not Seagates. The computer that uploaded the image was using a WD drive. Going to make an image on a Seagate and see if I can push that.

    Weird…



  • @Uncle-Frank said:

    The issue here was that the client which was meant to be deployed had a smaller disk than the client pulling the image from. Is this the case for you too? I doubt because this cannot be fixed by re-uploading and deploying to the same machine again.

    Probably best if you open a new thread and tell us all about your situation. FOG version, OS version, error messages you see, steps you took…

    I am having this issue again. I created a VM image and deployed it to a computer. Made changes and added software and then uploaded that image. I then went to deploy that image to a lab, but most of the machines gave the error and now are unable to boot as it erased the partitions. Some machines did take the image. I checked the HDD size of both computer that uploaded the image and the computers that gave the error and they are all 80GB hard drives. I doubt brand would have anything to do with it?


  • Developer

    The issue here was that the client which was meant to be deployed had a smaller disk than the client pulling the image from. Is this the case for you too? I doubt because this cannot be fixed by re-uploading and deploying to the same machine again.

    Probably best if you open a new thread and tell us all about your situation. FOG version, OS version, error messages you see, steps you took…



  • I am currently doing PoC of FOG for image deployment at my company… testing currently with VMs prior to imaging laptops. I’ve run into this issue presented by OP twice now, once with a Windows 10 and then a Windows 8.1 captured image. Both times I fixed by blowing away the captured image, deleting the computer, re-registering and re-capturing. Not sure what the cause is… will try to recreate the problem.


  • Moderator

    @jquilli1 said:

    the disk I created the image from was 80GB and the destination disk I’m deploying to is 80GB. I’ll report back if I run into anything else.

    Are the two HDDs identical? Absolutely identical? Same model and everything?

    Just a few KB smaller or a few sectors less will make a difference.



  • @Uncle-Frank said:

    What image type do you use? Is the source disk bigger than the destination?

    @Wayne-Workman said:

    I’m linking this thread with this since I think the problems are the same: https://forums.fogproject.org/topic/5967/fog-server-4956-won-t-deploy-image-to-host

    Looks like it might have been the image size being bigger than the destination disk. As of right now it’s working but it doesn’t make any sense because the disk I created the image from was 80GB and the destination disk I’m deploying to is 80GB. I’ll report back if I run into anything else.

    Thanks for all of the help!


  • Moderator

    I’m linking this thread with this since I think the problems are the same: https://forums.fogproject.org/topic/5967/fog-server-4956-won-t-deploy-image-to-host


  • Developer

    Please boot the machine you want to deploy to in debug mode again (as Wayne described) and run this command fogpartinfo --list-parts /dev/sda


  • Developer

    What image type do you use? Is the source disk bigger than the destination?



  • Same issue :/ everything finished with “done”

    debug.bmp


  • Moderator

    @jquilli1 It should be created like this:
    upload-d64f25c0-cd7a-489c-8de0-8383bf913ca8


Log in to reply
 

426
Online

39.3k
Users

11.0k
Topics

104.4k
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.