Posts made by jquilli1

@Wayne-Workman

Looking at the last 20 lines didn’t seem like it would be helpful. Here’s the whole log (sorry to be that guy)

http://pastebin.com/q9ZuwmY9

Ubuntu 14.04
Not sure my fog version because it’s down

Having an issue trying to upgrade FOG to the newest GIT version and am having the issue in the picture. I’ve tried removing and re-installing libapache2-mod-php5 with no luck.

Any help is appreciated!

@Wayne-Workman

@Sebastian-Roth

Looks like I can capture an image now with the latest update done to FOG. Do you two still want info from the incident?

“sfdisk: failed to dump partition table: Success”

FOG Version GIT 5459
Ubuntu 12.04

FOG is not capturing our images. When creating a capture task this happens:

And then the machine restarts along with the task being marked as completed.
This has been tested with multiple machines and multiple images.
Any help is appreciated!

@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.

@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?

@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!

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?

@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!

Same issue everything finished with “done”

Assuming I did this right. I ran an advanced task “debug” and then did this:

@Jbob said:

https://forums.fogproject.org/topic/5963/unknown-response-datetimezone-__construct-unknown-or-bad-timezone

Thanks for the fix, back to the same issue of not being able to deploy.

• 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 ()

d1.mbr

Sorry for the late reply again. File has been uploaded.

Yep! Images are still there.

Images are stored in /images on the FOG server.

The device itself has been imaged before with no issues. I’ve tried it on a physical desktop and also a VM. Both are doing the same thing.

Fog Server Details:

• Ubuntu 12.04
• FOG Git 4980

The Issue:
When I go to deploy an image I receive this:

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!