With the extended partition, when I go to restore, it simply fails. Running through debug it said something about the partition table in the image being no good.

With no extended partition, it worked a treat- that’s what I used today. It re-sized the partitions a bit funny, but I got over it.

I love when it’s just one after another…

these machines have to be on a plane Monday so I just did the unthinkable and multicasted them without the extended partitions (multicast worked like a charm!) and then went to each one and created the partitions and added the data. Yuck!
It’s done, anyway.

Onto the next project…

@Wayne-Workman That appears to be a dhcp issue- what I’m seeing is something along the lines of the thing booting network just fine, but it finds the partition table to be corrupt if there’s an extended partition, and refuses to download the image.

I built a base win7 and imaged it- worked fine. Ran all the updates and imaged it, worked fine.

Created my D partition, worked fine.

As soon as I created an extended partition, the download failed- even though the upload still runs flawlessly.

I suspect that it’s related to SDA4 (the extended partition that SDA5 exists inside of) touching the end of the disk. I’ve seen odd problems with images in the past where shrinking a partition by just a few megs would make a difference.
Of course, windows won’t let me do that…

I’ve not had any success since moving away from 1.2.0 so I feel like I’m missing something.

I created a new image, type 4 (raw dd) and set partition to “everything” with compression set to 1 hoping it’d not store the 300 some odd gigs of 0’s that way.

I then assigned the image to my source machine and scheduled an upload task. Booting the source machine to the network brought me to the clone process, which took about two hours. (Expected for a dd)

Then I assigned my target host that same source, and scheduled a download task (in debug mode, because I expected it not to work). Booted the target machine to the network and it started fine. Started the fog process and went through it at each step.

Variable dump:
osid=5
osname=Windows7
mbrfile=/usr/share/fog/mbr/win7.mbr
type=down
storage=ip.addr:/images/
img=Source4
imgType=dd
imgFormat=
imgPartitionType=all
hd=/dev/sda
part=/dev/sda1

typed in ‘fog’ enter
attempting to send inventory, done
checking in, done
mounting filesystem, done
checking filesystem, done

starting image push
using image Source4
looking for hard disks, done

wiping /dev/sda partition info
erasing mbr/gpt, done

creating disk with new label, done
initializing /dev/sda with ntfs, done

processing partition /dev/sda ()
partition file missing /images/Source4/d1p.img
stopping fog status reporter, done
changing hostname, done

database updated
task completed

So, it would appear it can’t find the image file…?

I went on the server and looked in /imgages/Source4, there’s only one file- Source4 with a size of 187GB

I just spoke to the guy wanting these and the requirement has changed- I also need a small (100mb) partition for the lab, so that’ll be six partitions in all.
I’m testing a RAW image clone right now, I can’t think of a reason it wouldn’t work if FOG manages to initiate the copy on the destination…

Thanks- Caught me off guard is all, I use randomly generated passwords whenever possible so you never know what might come up

I just generated a different one that didn’t involve the $ character as a workaround on my end.

1. the windows 100mb boot partition
2. C drive
3. D drive (required for this purpose)
4. extended for 5
5. backup partition with image of C for on the road re-imaging (also required…)

I might be able to get away with keeping the image on partition 3 as a file, but TPTB want it on its own partition.

update:

after the failed deployment, the size listed under image management changed to 0.00iB. Odd.

New image appears to have created correctly, and shows up in image from the web UI with a size- but the restore back to another box had the same results.