Deploy problem - error loading operating system
-
Hi Adam,
I think I will have to agree with you. I had been pushing this in our Government dept with 5000 users and over 2000 PC’s. I made a presentation to management explaining how good FOG is and how we should support it and give it a goI built all our images on small hard drives so the image wouldn’t be too big, and used “virgin” HDD’s to build with - no extra hidden partitions, etc.
We are now stuck with over 10 images on 40 and 80 GB sizes when all our gear now comes with minimum 250G drives.
I will be removing FOG and looking at other options now. (wonder if we can get our donation back) -
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.
-
Our’s is a newish build of FOG on CentOS 5.7
Before we installed FOG, we ran a system Yum update. I’m wondering if an update somewhere may have caused the issue?
Our builds are ‘winnt.sif’ builds then modded a bit, then sys prep’ed. Uploaded after sys prep and before next power on.
As mentioned previously, we built all our images on smallish HDD’s to reduce the size of the image.
Fixed size works a treat, but not a “NTFS, resize” style image.
Ours also appear to be taken and deployed in RAW format.Maybe someone has an idea at some stage…?
-
Here’s a bit more from my playing around this afternoon.
[LIST]
[]Brand new hard drive in Dell Optiplex 755 (latest bios)
[]Ran Yum update on CentOS Fog Server
[]Tried 3 different kernel’s
[]defrag and chkdsk after build
[]deleted image from Fog server
[]Created new image and confirmed that entry in MQSQL is correct for DDImage type “0”
[]setup tak to upload image
[]upload starts and gets flagged as RAW not NTFS
[*]And here starts the problem
[/LIST]
Anybody got any idea on how to manually do an image upload via the debug option? -
Try [URL=‘http://www.fogproject.org/wiki/index.php?title=Troubleshooting_an_image_upload’]this[/URL].
-
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.
-
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…
-
After alot of trail and error I had success last night
I did anohter fresh ‘build’ of our image and let it finish and set itself up.
(BTW our images are built in house via winnt.sif scripting then handed over to Dell to their factory where they massage them for the different hardware)
So, did the image and nothing else, and for nothing more than running out of options, I loaded up Partition Commander (or similar) and let it find the partitions. As soon as it started up it detected an issue with the block allocations and asked if it wanted to fix it.
I said yes please, let it do its thing then reboot. Checked it again and no errors reported.
I then tasked FOG to upload a fresh NTFS resizeable image…
IT WORKED ! FOG picked up the partition as NTFS.
Now I haven’t been able to test any other of our images as yet, as I finished up after midnight.
Will be testing a few over next 2 days and will report back here of results.
Looks like FOG is back in the game -
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.
-
Has anyone found an easy fix for this? I’m having the same issue with an image that IBM provided my company that used ImageX to create the partition/initial image and I’m trying to upload it to fog. Running into the same exact errors described here. I’ve tried using pmagic and some other tools to fix but have been unsuccessful. Thanks!
-
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.
-
I was able to fix the problem with one of my images! Here’s how:
- Applied the bad raw file system image from fog and got the no operating system message
- Booted from Hiren’s Bootcd and went into mini xp
- Started Disk Genius and search/recovered the ntfs partition and then saved the partition table.
It should recover the partition just the size of the used data. - Loaded up Partition Wizard Home Edition
- Copied the partition and deleted the original. And then resized the partition to fill the disk.
- Use fog normally after this and I saw ntfs file system on the upload instead of raw.
I think the way it creates the partition when it copies is different than how imageX creates it. At least that’s the only explanation I can come up with.
-
@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.
-
This post is deleted! -
Hi guys, I’m finding that this is also the case, I’m deploying Windows XP to older machines, and after attempting to WRITE an image that was previously resized, the image process fails, and then leaves the disk in a corrupted state. I am ONLY able to do full disk imaging with any success. Don’t know if this is relevant, but I’m using older machines, with PATA hard disks (still).
-
I know what the issue is and have fixed it in svn if you’d be willing to upgrade.
