Images not being Deployed
-
@jquilli1 It should be created like this:
-
Same issue
everything finished with “done”
-
What image type do you use? Is the source disk bigger than the destination?
-
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 -
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
-
@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!
-
@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.
-
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.
-
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…
-
@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?
-
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…
-
@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
fdiskto 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
-
@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
fdiskto 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!
-
@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.
-
@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?
-
@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.
-
@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.
-
@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.
-
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.
