Deploy problem - error loading operating system
-
[quote=“Adam Croft, post: 193, member: 54”]How can it be Windows related if the operating system hasn’t even loaded, Blackout?[/quote]
Because FOG has done it’s job of cloning the data successfully.
FOG doesn’t care what the data is, it will just clone the data… problems and all.You are now at the stage of the OS booting, it then fails to boot. Thus a windows related problem.
Chuck hinted at this above by asking you to look at MBR issues.
[quote=“Adam Croft, post: 136, member: 54”]I also tried building a really basic image from scratch and then uploading it. Deploying that basic image works. Any other suggestions?[/quote]
This tells me there is something wrong with that image. With the data inside of that image.
Remember FOG does not care, verify, or even look at the data in your image.Maybe with the MBR of that image? These types of messages normally hint at an MBR issue.
First thing i would be doing is running [B]chkdsk /x c:[/B] on the master (non syspreped) version of your image.
If that brings no joy, you need to narrow down WHY windows is failing to boot.
Can you manually fix the problem (maybe using ‘fixmbr’) and get the image working?After it’s fixed on the Master, re-sysprep and take the image up.
-
I’ve got some more information that may help narrow down the problem. We tried switching the image type to multiple partition and it works…not what we want, though. We must have the ability to resize the partition to utilize the entire disk and as I understand that only works with single partition. I’m certain there is only one partition. To verify I plugged in a sysprepped drive into a working computer and ran diskpart to show the partition information. I show one partition about 38gb in size with a 1024kb offset. After uploading that image to FOG and then deploying it back to the same disk I run into problems. Diskpart still shows one partition but with a 31kb offset. Plus, when I plug in the disk imaged by fog Windows shows the partition as raw data. I built the source disk this time using WinPE with the following commands to prepare the disk:
select disk 0
clean
create partition primary
select partition 1
format quick fs=ntfs label=“Windows”
assign letter=C
active
exitThis process works perfectly and we end up with a bootable disk. I’ve taken that disk and sysprepped it, then uploaded it to fog. It’s only when we deploy the image from FOG that problems are introduced.
If FOG just copies the data, problems and all, then I should have a working disk after deploy. What else do you suggest to resolve the problem?
-
When i said “just clones the data” i was being very simplistic. Of course there is a lot happening, even more when it starts resizing partitions.
The Multi-partition image does not resize, i want to see if this is causing the problem.
Walk through this process: [url]http://fogproject.org/forum/threads/wiki-troubleshooting-an-image-deploy.20/[/url]
Test to see if the image boots just after step 7.
Repeat the process and test if it boots after step 8.Report any errors or interesting output here.
Feel free to post the [I]entire[/I] output of[B] fdisk -l[/B] before and after the FOG upload so i can see the differences.
Have you ran any partition repair tools before and after the upload to detect any partition problems? The same for MBR issues.
-
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.