Posts made by Adam Croft

Try [URL=‘http://www.fogproject.org/wiki/index.php?title=Troubleshooting_an_image_upload’]this[/URL].

Move on and try something else like Clonezilla. It seems like the developers aren’t particularly interested in solving this problem.

Anyone got suggestions? What could be causing ntfsresize to fail?

Blackout, I’ve had some time to readdress this problem. I have deleted all the partitions, done a fresh install of Windows, and uploaded with single and multi-partition (without running sysprep). Both work as advertised. I’m still having trouble with our existing images. I’ve been through the upload troubleshooting document and I believe the problem lies with ntfsresize. I have simply tried resizing the partition from one of our existing image disks following the instructions [URL=‘http://crashrecovery.org/CrashRecoveryKit/iso/2.4.21/HOWTO.ntfs.html’]here[/URL]. With the existing image disk ntfsresize reports the operation was successful but I cannot mount the partition following resize nor will it boot. Running fdisk -l shows the partition as starting on the 1st cylinder like the original, flagged as bootable, and type NTFS. Running the same steps on a disk with a fresh Windows install DOES work. I’ve tried to rule out problems with the partition by running chkdsk /x like you suggested before and defragging the drive. I don’t know what else to do to troubleshoot this.

I followed the troubleshooting guide and tried deploying at step 7, did not boot. So we can rule out the partition resize issue, correct? So far I have not been able to manually fix an image deploy so that it boots. As for the question about the file system type, the FOG upload display shows “RAW” as the detected file system. That seems to fit with the problems I’ve been experiencing. For example, when I run the repair console off a XP install disc, it does not detect a windows installation. I will try parted magic and mbrwiz and let you know what happens.

Something I didn’t notice yesterday that I saw when going through the troubleshooting steps you provided was that FOG detects the partition type as raw on upload. That seems a likely cause of the problem, no? Following is the output from fdisk you asked for. No, I haven’t ran any partition repair tools and I’ve used fixmbr before and after upload.

Straight from the disk duplicator before uploading to FOG:

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 4866 39079936 7 HPFS/NTFS

After uploading to FOG and then deploying back to the same disk:

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 19457 156288321 7 HPFS/NTFS
I’ve gone back and deleted my image and made sure I’m selecting single partition and not raw.

I’ve got some more information that may help narrow down the problem. We tried switching the image type to multiple partition and it works…not what we want, though. We must have the ability to resize the partition to utilize the entire disk and as I understand that only works with single partition. I’m certain there is only one partition. To verify I plugged in a sysprepped drive into a working computer and ran diskpart to show the partition information. I show one partition about 38gb in size with a 1024kb offset. After uploading that image to FOG and then deploying it back to the same disk I run into problems. Diskpart still shows one partition but with a 31kb offset. Plus, when I plug in the disk imaged by fog Windows shows the partition as raw data. I built the source disk this time using WinPE with the following commands to prepare the disk:

select disk 0
clean
create partition primary
select partition 1
format quick fs=ntfs label=“Windows”
assign letter=C
active
exit

This process works perfectly and we end up with a bootable disk. I’ve taken that disk and sysprepped it, then uploaded it to fog. It’s only when we deploy the image from FOG that problems are introduced.

If FOG just copies the data, problems and all, then I should have a working disk after deploy. What else do you suggest to resolve the problem?

Is there any way to make FOG use the entire available space on a disk for single partition? If the target disk is larger than the image partition I want FOG to expand the partition so I can use the remaining disk space. Any way to do that?

How can it be Windows related if the operating system hasn’t even loaded, Blackout? I have to assume FOG is somehow damaging the partition information causing it not to boot correctly. The same disk that was used to upload boots right up into mini-setup but pulling the same image down via FOG doesn’t work. I even see some mention in the web interface help information for single partition that FOG may complete the deploy task without error but still leave the system unable to boot. Today we tried uploading as multiple partition and the deploy worked successfully. I still only show one partition in Client System Information. Why doesn’t single partition upload work?

Chuck, I checked the partition information and I only have one partition. I tried letting the mini-setup running again and then running sysprep again before uploading. Same scenario as before. I also tried building a really basic image from scratch and then uploading it. Deploying that basic image works. Any other suggestions?

[quote=“Chuck Syperski, post: 107, member: 4”]Hmm, before uploading an image can you take a look at your hard drive and confirm that you don’t have any other partitions present that may be confusing the MBR? To do this, boot up in ‘Client System Information’ from the boot menu (I think that is the title). Then select the option to display the partition information. Confirm that you only have a single partition.[/quote]

Thanks for the suggestion. I’ll check that tomorrow morning when I’m back at work.

I have recently set up a fog server at my workplace to take over our current imaging process. So far the software is working as expected, however, I’m running into a problem deploying images. Each time I deploy an image I get an “error loading operating system” message on boot.

Currently we have several sysprepped hdd’s that we use with a disk duplicator for routine imaging. I’m using one of these disks to upload an image. I pre-register the computer with fog and start an upload task for the host. Then I pxe-boot the host with the sysprepped disk and the image is uploaded successfully.

Now, if I leave the disk in the computer and let it boot like normal the mini-setup proceeds and I wind up with a successfully imaged computer. To confirm the image will work I turn around and start another task to deploy the new image back to the same computer. I pxe-boot again and the image is deployed.

On reboot I get the “error loading operating system” message. I’ve tried setting the hdd mode to LBA as suggested by researching the problem but it doesn’t work.

We are running the most recent version of fog on Ubuntu 10.4. I have the image setup for XP, single partition. What am I doing wrong? What other information would be helpful to troubleshoot?