Images not being Deployed
-
- Upgraded to Ubuntu 14.04
- Uninstalled FOG
- Reinstalled FOG using GIT instead of upgrading from 1.2.0
- Now receiving DateTimeZone::__construct(): Unknown or bad timezone ()
-
-
@Jbob said:
Thanks for the fix, back to the same issue of not being able to deploy.
-
@jquilli1 Can you run a Debug Deploy and make sure everything is working?
When you’re at the CLI (after hitting enter a few times), issue the
fogcommand. Then just slowly press enter for each step.I want you to pay special attention to the NFS Mounting parts.
-
Assuming I did this right. I ran an advanced task “debug” and then did this:
-
@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?
