Issue with download on Dell R200 Server

[Dave Wolf]

Hi all,

I am experiencing an issue with loading our Dell R200 servers with a Windows XP Embedded image that FOG has uploaded just fine. The R200 has an 80GB SATA drive, and I also have a pfSense image that loads on it with no issues. The process errors when restoring the image to /dev/sda1 with an “error exit” and the system reboots. I fired up a debug download so I could take a look at the partition during the process. Here is a screen shot at the first stopping point of the debug after running a “gdisk -l /dev/sda”:
[ATTACH]1316[/ATTACH]

I ran fixparts /dev/sda and let it fix the partition (or so I thought), but it would finish with the same error again. So, I used fdisk to delete the partition (see the following screen shot):
[ATTACH]1317[/ATTACH]

Here is what it looks like stepping through the debug download after deleting the partition:
[ATTACH]1318[/ATTACH]

and then typing “fog” to continue, here is the error:
[ATTACH]1319[/ATTACH]

Any ideas what else I can try? The initial Windows XP Embedded image that is on the disk was put there by Ghost (we’re trying to eliminate Ghost here and soley run FOG for our test lab).

Thanks!
Dave Wolf

[url=“/_imported_xf_attachments/1/1316_IMG_20140826_125614.png?:”]IMG_20140826_125614.png[/url][url=“/_imported_xf_attachments/1/1317_IMG_20140826_125645.png?:”]IMG_20140826_125645.png[/url][url=“/_imported_xf_attachments/1/1318_IMG_20140826_125711.png?:”]IMG_20140826_125711.png[/url][url=“/_imported_xf_attachments/1/1319_IMG_20140826_125737.png?:”]IMG_20140826_125737.png[/url]

[Dave Wolf]

Forgot to mention, FOG version 1.2.0 on Debian 7.6…

[need2]

Is there any other data on the disk that needs to be retained? If not I would suggest doing a disk wipe.

[Dave Wolf]

Hmmm, does that do anything different from manually deleting the partition using fdisk in a debug download? Just curious.

Thanks!
Dave.

[Junkhacker]

i’m not certain that fdisk will wipe out the content of the first sectors of the disk, this is where fog checks for MBR vs GPT partition information. even if new MBR partitions are created, GPT partition information can be left in the space after sector 63, which can cause fog to fail

[Tom Elliott]

That’s part of why I’ve included fixparts in the init.xz/init_32.xz files. If something doesn’t seem to work properly, boot into a debug task, preferably upload, and run fixparts. It should find and fix any partition data that is supposed to be mbr but still has residue of GPT within it. This has been a common issue and I just don’t have a better means to fix this. I don’t know if you’re intending to maintain GPT or go pure MBR and if I start trying to make guesses as to what you’re attempting to do, it may cause more problems down the road.