Deploy problem - error loading operating system
-
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 bytesDevice Boot Start End Blocks Id System
/dev/sda1 * 1 4866 39079936 7 HPFS/NTFSAfter 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 bytesDevice 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. -
The start and end blocks have changed… hmmmm.
After the deploy, can you some how manually fix it and get the image bootable?
If you can do that, you will find the problem in the process.When you see “RAW”, are you sure its not referring to what type of File system FOG found?
If FOG is finding your NTFS partition as a RAW partition, that will definitely cause problems.Try using:
[LIST]
[]Parted Magic - [url]http://www.partedmagic.com/[/url] - start gparted and run a ‘check’ on the partition
[]MBRWiz - [url]http://www.firesage.com/[/url] - check the ‘/Repair’ and ‘/Sort’ options
[/LIST]
Apart from that i will need to do some testing and (try to) replicate the problem. -
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.
-
If the partition has been uploaded as a Single Partition image, then the resizing has already occured. (it resizes the partition before taking it up)
Can you try deleting all partitions, making a fresh Windows install, take it up as Multi-Partition Single Disk, then redeploy to test.
This is the only way to rule out resizing.
-
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. -
Anyone got suggestions? What could be causing ntfsresize to fail?
-
Hi, we have run into the same issues here… Does it seem that no one else seems to have the issue?? Dell Optiplex and Latitude’s… Single partition and trying to use all the HDD. Same error, drives are sysprep’ed and “problem loading operating system”
WE are now forced to run fixed sized images - not good…
Any ideas? -
Move on and try something else like Clonezilla. It seems like the developers aren’t particularly interested in solving this problem.
-
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.