@Astrocreep, that is good news. Nice job. Unfortunately for us, I have no desire to have my folks load Hiren’s Bootcd and Partition Wizard or any other tools to create a working FOG image of our nodes or to fix the imageX FOG’d raw image… ImageX has become our main tool for deployment now, and doesn’t play with FOG well. We have used FOG one time since switching from our old deployment methodology to imageX.

We still have the problem with images that were working fine with FOG, but then taken with imageX as wim files and redeployed. When attempting to backup these redeployed images to our FOG server, they are sent as RAW images instead of NTFS. The only solution we have found is to use multiple partitions, single disk (We are using XP) and it to works. This doubles the time it takes for us to grab an image, and redeploy it, but it does work. It also limits us to using drives of the same size or larger, which is where it creates a problem for us. I tried everything I could think of to try to fix it, with no headway.

We switched our initial deployment tool to MDT2012 when our problem surfaced and I was taking a look at how it does DISKPART. Since we are deploying XP images, I notice there is a reference to [url]http://support.microsoft.com/kb/931760[/url]. It sets the offsets properly in the registry for XP deployments. This appears it might be the root cause of the problem, but I have to much other work to do to root cause it right now.

It’s killing us for our IA update process since we were using FOG to grab images of everything, scan, patch and test… because with FOG and ntfsresize we could grab our images in <10minutes and redeploy just as fast… and the images had a small footprint on my /images partition.

Well no fix. However, it is working just fine with another machine that was not deployed using imageX. It is pretty obvious that when we are grabbing the image from a working XP install that was imaged/deployed with imageX, it is detecting the partition as RAW versus NTFS. I need to figure out what is causing this so I can correct…

In our case it has nothing to do with updating the server. It hasn’t been updated in a while as I was on travel, and it still works just fine with “other” winxp images. What I did find interesting… I took a look at the partitioning on the drives that are being imaged and being detected as RAW vice NTFS, also tried setting the OS to WIN7 when taking the image (but it still reverted to RAW). Anyways, looking @ the partitioning of the drive after they were setup using imageX, there is 7.34mb unallocated in front and behind the single NTFS partition on the drive. We are in the middle of final scans etc on these nodes, but once done, I plan on resizing the NTFS partition to span the drive and give it another go with FOG. WE LOVE FOG, mostly because of the web interface and SPEED uploading and pushing images!!! I need this to work.

WE NOW have this problem. We have been using FOG in a lab environment uploading and downloading successfully, using Single Partition, resizable. Just this week, our images are pushed to the new machine and we get a error loading operating system. Loaded Win PE and used DISK PART to take a look at the image. It is of type RAW instead of NTFS. Well that isn’t gonna work. So we verified that it was setup correctly when it was uploaded. It appears to be. Something is definitely not right now…

Any ideas???

EDIT: When fogging the machine (as we redid it and wanted to monitor it), it is detecting the partition as RAW instead of NTFS. These particular machines were built/imaged using imageX to push the original images to them.

[quote=“Kevin, post: 1665, member: 3”]the 3.2.4 kernel should support the EXT4 filesystem. All the other changes for version .33 of FOG are listed in the first post of this thread.[/quote]
Upgraded to 3.2.4 kernel and can in fact image my linux box with ext4 now, though because it is multiple partitions, it takes a long time to do it.

Looking fwd to .33 to work/play with!

Hmmm. No answer. So I will just use Windows backup… not the best solution, but it will have to suffice.

Is there a way to get fakeRaid to work with FOG? I have been using FOG in our lab for a few months without problems, however, one of our 2008R2 laptops is setup on RAID0 (Dell M6400). I am hoping to FOG this, but get a Fatal Error: Hard Drive not found error when trying to upload an image to my FOG server. I tried the default kernel with .32 and the latest 3.2.4.core kernel with same errors.

I noticed I can load latest gparted and it sees the raid and I can manipulate the partitions from within gparted, and have successfully (I had removed the hidden system partition and was expanding C:\ back over it) … So I am assuming I can get somewhere with a custom kernel? Any help or ideas? OR is it just not possible?

Thanks in advance!