Windows7 restarts at bootup when it reaches classpnp.sys after being imaged with FOG
-
I’m testing out FOG. So I setup a server and have now uploaded a Win7 image to the server using the following setting:
- Windows 7 Multiple Partition Image - Single Disk (Not Resizable)
After this I download the image to the same system and drive. Everything completes successfully but I cannot get the system booted.
I have tried the following:
- Windows start-up repair
- Windows EasyRecovery CD
- I’ve tried fixparts and then ‘w’
- I’ve tried adjusting the BIOS from AHCI to IDE (also legacy)
Nothing seems to work.
I thought it might only be that specific machine. But, I’ve replicated the issue across two other machines with different drives and hardware. I’ve also tried restoring to a larger disk.
What am I doing wrong here?
PS: I’m now trying the ‘Single Disk - Resizable’ option.
Thanks,
MrsPotter.
-
I would make sure to rule out issues with your reference image before focusing on FOG. I can say that I deploy Win7 using FOG without issue.
We capture using single disk not resizable but then expand the disk to consume the entire disk post deployment using diskpart in the unattend.xml or via the setupcomplete.cmd. Either way works well.
I can also say that when we build the reference image we use a VM client to capture a hardware neutral reference image.
From a deployment standpoint I would ensure that the reference systems and target systems (hardware) are setup properly. It sounds like you’ve ruled out the hardware since you are building your reference image and then deploying to the same hardware.
While this takes time I would build a reference image, sysprep it, and instead of capturing at this point just reboot the reference image to ensure that it builds correctly on the same hardware. This will make it clear that FOG is at issue. You should use the exact same process just don’t capture and deploy using FOG.
Based on your error I would say there is a driver issue with your deployed system.
-
I’m getting the same result with ‘Single Disk - Resizable’ option.
-
Thanks for replying.
In my application I would like to image a machine before making major changes to the software setup. Basically, put a version of it in the deep freeze for just in case. Or you could see it as a restore point of sorts. I used to do this with Clonezilla with reasonable success. Thus, I’m not too keen on going the ‘sysprep’ route. I basically want to restore a prior working configuration to the same hardware.
I gathered it might be a driver issue of sorts, but Google doesn’t bring up too many useful ideas.
I don’t want to abandon FOG yet as it seems it might just be something stupid.
-
Ok that’s a bit clearer, you are using FOG for / as a deep freeze system to archive the image not deploy a master image to many machines.
So for this I would use single disk multiple partitions not resizeable (since you are copying from and restoring to the same machine every time).
While this is an obvious statement, this (FOG) should work no problem. Its just using partclone to copy the hard drive to an image and then using the same to take the image and put it back on the client.
You say that its getting to classpnp.sys and freezes. Are there any warning messages at all?
You did make reference to ACHI and legacy, so I can assume that this hardware/disk is not in UEFI mode at all??
-
Exactly.
No, I get no warnings: It boots, I see the little Win7 icon moving. It freezes and then reboots. If I then boot using ‘debug’ mode, I can see that it stalls at ‘classpnp.sys’. That’s it.
No it is not in UEFI mode.
-
I guess I’ll have to leave this for FOG support. Because what you’ve done thus far is exactly what I would have done.
FOG should copy and put back the same image to the same hardware no problem.
-
I think we need to know more details.
It seems, this is not a direct FOG issue, but maybe the image uploaded has this problem? This would explain the problem showing up on multiple machines, that the uploading system had some issue with it. Do you still have this reference system and does it boot with no issue?
Is the image Sysprepped? If it is Sysprepped, is there possibly software installed causing the problem? Is the unattend.xml file operational?
-
I tend to think that something went wrong with the upload process.
How many partitions does the image supposed to have? Can you look inside of /images/<image name> and see the correct number of partitions?Did you watch the entire upload process? No errors?
-
Yes the upload completes without error (as far as I can tell).
I’m not doing sysprep as I want to clone the machine as is. And, then later restore it to the same machine.
It is a standard Win7 installation. So there are two partitions /dev/sda1 (a 100MB boot) and /dev/sda2 (number of GBytes).
I’m thinking the same as george1421: it is essentially an automated partclone. So, it should put the clones image right back.
I tried “Multiple Partition Image - Single Disk (Not Resizable)” and “Single Disk - Resizable”. I tried it on two different machines. But, it produced the same ‘classpnp.sys’ results.
-
And yes the /images directory contains 3x files: 1x MBR and 2x IMG files.
This corresponds with the expected number of partitions.
-
Does clonezilla work correctly for this task? (just trying to contrast and compare). FOG uses partclone where clonezilla, well uses clonezilla to copy the image.
-
Yes I’ve been using Clonezilla for some time and it works. Sometimes one has to run Windows startup repair to get it to boot.
If I’m not mistaken Clonezilla also uses Partclone. At least the FOG and Clonzilla cloning screens look identical i.e. Partclone.
-
Well I guess I’m a bit red faced. I though clonezilla was its own thing. I guess I need to download a copy and see if the versions of partclone are the same. While I’m not with the FOG project (so this is only a guess), I could understand how the version of partclone could be newer/different with clonezilla than with a traditional linux OS, because the traditional OS version is dependent on the OS packager to update the version. Clonezilla is its own linux OS variant where the developer has control over the precise version used in the distribution.
Understand I’m not saying this is the issue, but I would wonder why if using the same cloning engine you would get different results.
-
@MrsPotter Anything special about the HDD? Is it mechanical? SSD? Hybrid?
-
@MrsPotter Are you trying to deploy to the exact same disk? Maybe see here: https://social.technet.microsoft.com/Forums/windows/en-US/120d39f1-1bbd-4207-af8a-50410e31f83b/restored-disk-image-wont-start-hangs-on-classpnpsys-restored-from-multiboot-to-singleboot?forum=w7itprogeneral
And here is another interesting post: http://answers.microsoft.com/en-us/windows/forum/all/windows-7-boot-stalls-at-classpnpsys/60391978-7fba-4afa-8c6b-c2dd8fc316d9
Interesting. Did some more digging. Turns out that while everyone seems to think the boot is stalling at classpnp.sys, it is in fact stalling at the NEXT file in the boot sequence, which is cdrom.sys (in my case, anyway). That makes a bit of sense. In my case, there was a DVD drive while I installed and configured.
-
@george1421 Clonezilla SE (server edition) is actually very similar to FOG. It is a BOOTP server that can boot any image you want via TFTP. If you boot the Clonezilla image you get the familiar Clonezilla menus (this could be automated) which ultimately uses Partclone to clone your image to the server. FOG’s web GUI is a little nicer though. FOG also took the deploy to many idea much further with all the plug-ins etc. As far as I can tell Clonezilla only has a single developer.
-
@Wayne-Workman Nothing special. I’ve tried imaging:
- an ordinary 3.5" 7200RPM ACHI to a larger 3.5" 7200RPM AHCI
- an SSD to a larger 3.5" 7200RPM AHCI
I’ve tried both “Multiple Partition Image - Single Disk (Not Resizable)” as well as “Single Disk - Resizable”.
I’ve tried the re-imaged drive in the same PC as well as several others to see if it gets stuck at the same spot. All get stuck at classpnp.sys.
-
@Uncle-Frank I’m going to try and get a Windows boot log out of one of these machines. It would be very interesting to know if it is the classpnp.sys or the cdrom.sys which is causing the problem.
What I have done thus far though is to try and disable peripheral I could find in the BIOS to see if that would make a difference. I also tried booting with the CD-ROM plugged in and and plugged out.
I’m going to have a look at my FOG settings and see if there is something that might cause the problem (or could be changed for that matter).
-
The important FOG settings are as follow:
- Version: 1.2.0
- All plugins & services are disabled
- FOG_PIGZ_COMP = 9
- FOG_UPLOADRESIZEPCT = 5
- FOG_UPLOADIGNOREPAGEHIBER = 1
- FOG_DISABLE_CHKDSK = 1
Perhaps I should try it with FOG_DISABLE_CHKDSK = 0?
