To Virtual Partion Failed - Drivers are added correctly!
Occassionally we have a PC that shows up a bunch of malware and we opt to reimage the workstation for obvious reasons. A problem occurs sometimes on said machines where we execute the reimage task and the machine instantly reboots back into windows without trying to boot to the WINPE environment at all. The task failes with "To Virtual Partition: Failed to reboot client to recovery partition"
We have the appropriate drivers added to WINPE (and yes, I have seen the errors that indicate a missing driver) and use these tasks to reimage many machines of the same model successfully on a daily basis.
We have tried manually removing and reinstalling the client.
There is one bootable partition on the workstation.
There is a single physical drive in the workstation.
There is a single NIC in the workstation.
The model is Dell Optiplex 745.
What is causing this to fail?
Comments 19 Comments • Jump to latest comment
Corrupting the Master Boot Record somehow.
Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.
Connect Etiquette: "Mark as Solution" posts that fix your problem, thumbs up for useful
I don't know if you have the same DOS model on your side, anyway we have also some optiplex GX745 and our ghost console determined a default "Broadcom BCM57xx" DOS model.
I doesn't really matter since we're also using WinPE to reimage. Just a wild guess actually....
The PC will boot to Windows just fine, so I don't think that the MBR would be corrupt.
Yes, our Ghost console states that the detected driver would be the "Broadcom BCM57xx" DOS model. I have tried setting the Virtual Partition PreOS to "PCDOS" and it still fails on "To Virtual Partition".
I have also tried running a "Create Image" task which failed:
- Updating PreOS files
- To Virtual Partition (Failed)
Is there any way to get some more advanced logging? I read about inserting a DWORD "TraceMode" into the registry, but it appears to no longer work. We are using Windows 7 64-bit clients. I placed the TraceMode reg key into "HKEY_LOCAL_MACHINE\Software\Symantec\Symantec Ghost\TraceMode” as well as into the "HKEY_LOCAL_MACHINE\Software\Syswow64\Symantec\Symantec Ghost\TraceMode” key.
I just executed an advanced task with a log file and here are the results (IP address removed):
Log Level All
258494234 GhostSrv 11.5.1.2266
Wed Jul 11 08:20:10 2012
Initialising RML
258494250 rml_get_local_interfaces found these IP addresses:
x.x.x.x
RML Initialised
RML socket send buffer size set to 1831680
Setting UDP socket receive buffer size to 60102
UDP socket receive buffer size set to 60102
RML socket receive buffer size set to 57240
258494265 Throttle value:0 mb/min
Length of tick in seconds:0.001000
Ticks per throttle bucket:15
Throttle byte count limit[0] = 0
Throttle byte count limit[1] = 0
Throttle byte count limit[2] = 0
Throttle byte count limit[3] = 0
Throttle byte count limit[4] = 0
Throttle byte count limit[5] = 0
Throttle byte count limit[6] = 0
Throttle byte count limit[7] = 0
Throttle value:0 mb/min
Length of tick in seconds:0.001000
Ticks per throttle bucket:15
Throttle byte count limit[0] = 0
Throttle byte count limit[1] = 0
Throttle byte count limit[2] = 0
Throttle byte count limit[3] = 0
Throttle byte count limit[4] = 0
Throttle byte count limit[5] = 0
Throttle byte count limit[6] = 0
Throttle byte count limit[7] = 0
RML socket send buffer size set to 4194304
Server multicast address set to 224.77.7.32
Throttle value:700 mb/min
Length of tick in seconds:0.001000
Ticks per throttle bucket:15
Throttle byte count limit[0] = 364156
Throttle byte count limit[1] = 546234
Throttle byte count limit[2] = 910391
Throttle byte count limit[3] = 1638704
Throttle byte count limit[4] = 3095331
Throttle byte count limit[5] = 6008584
Throttle byte count limit[6] = 11835090
Throttle byte count limit[7] = 23488102
Bound RML socket to 0.0.0.0:1037
Setting multicast scope to 16
State was 0, now 1
Bound TCP socket to 0.0.0.0:1038
Bound UDP socket to 0.0.0.0:6666
Interface x.x.x.x (0) ws2AddMembership succeeded
258637343 RML Statistics
End RML Statistics
Shutting down RML
RML shutdown
Log Level None
Any other suggestions?
Try setting the bios boot order so that the boot from NIC option is first. It certainly sounds like the malware is interfering with the boot process in some way (not unusual) so forcing a boot from NIC by setting it as the first boot device may help. Otherwise, as a test, try unhooking the hard disk and see if it then PXE boots correctly.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
We are not using PXE boot. We have our NIC set to "enabled" in the bios, but not "enabled with PXE boot".
As stated before, this configuration works on most other Optiplex 745s as well.
Brad,
Create one click vitual partition using Ghost Boot Wizard and execute it on Optiplex 745s machine which is creating problem. Let me know whether it boots into winpe.
Also try using Universal Packet Driver v2.0 [irqcfg] template.
I have same model in my setup and I used to get same error which you received on your machine but problem gets resolve when I select Universal Packet Driver v2.0 [irqcfg] template.
Let me know your results.
Regards,
Nitin
If you feel your issue has been addressed to, please use the "Mark as Solution" link for the relevant thread
I created the one click partition but it was unsuccessful. The workstation just rebooted back into Windows. Is there a log for this process somewhere?
I also tried the Universal Packet Driver v2.0 [irqcfg] template with no luck. Everything I try from ghost console results in a "Failed to reboot client to virtual partition"
Brad,
Try refreshing Winpe and Winpe512 boot package from Ghost Boot Wizard and execute the task again. I suspect the boot package seems to be corrupted (since you mentioned VP is working fine). Re-building the boot package might solve your problem. Please give it a try and let me know.
Regards,
Nitin
If you feel your issue has been addressed to, please use the "Mark as Solution" link for the relevant thread
No luck.
Maybe you should save your time by using a USB Stick or other boot media to boot your PC locally and then restore the image from a locally connected USB hard drive. Unless there is an access problem to the affected PC, you could waste a lot more time and not get anywhere. There could also be a hardware fault so doing things locally rather than over a network is going to remove a few variables from your situation.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
I understand that booting from a USB stick or CD would save time, but the problem is this client is at a remote site where we don't staff IT.
As this happens occasionally, I would like to know what is causing it.
Is there any additional logging that I can invoke on the client or server side? What about this "tracemode" key - does it no longer apply or am I missing something?
If you want to get to the bottom of this problem then to me the logical way forward is to replace the failed PC with a good unit then bring it back to your lab and work through the issues until a cause is identified. Hardware failure cannot be ignored as a possible cause and you cannot fix that remotely.
What you may wish to consider provisioning for remote sites is a boot device such as one of the larger USB keys, that boots into WinPE and offers the user a menu of machine rebuild options (HTA can be used to write nice graphical menus for WinPE). This can be used locally by a member of staff if this situation arises to restore a standard image and if that fails then you know you most likely have a hardware problem.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Thanks, I will be traveling to this location next week to replace the unit. I will post up when I get it back here.
We retrieved the problem machine and placed the hard drive in another identical Dell Optiplex 745 unit. Upon booting we are still NOT able to reimage this machine via ghost console. I receive the the same message as before.
This rules out the possibility of a hardware failure in my mind.
Any suggestions?
If I understand you correctly,. you took the hard disk from the problem machine and placed it in another identical DELL machine, and then tried, and failed, to reimage the disk from the problem machine using the identical DELL? If so, then I would conclude that the hard disk is the common point of failure.
Try a full wipe and reformat of the hard disk as a secondary drive in another system, and then run chkdsk on it. A problem with one of the early sectors of the hard disk would prevent successful imaging. Alternatively, hang a drive from a known good identical DELL in your problem machine and then try imaging it.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
I took a copy of our problem drive using a ghost boot CD - just to have a backup if I need it for further testing.
I did notice a warning when the cd booted:
"Ghost has detected an inconsistency between the volumes detected on disk and the OS volumes. On Vista this could lead to write failures. Rebooting should fix this problem. Do you wish to continue?"
Rebooting does not make this warning go away.
I ran chkdsk and tried reimaging with Ghost console again - no luck. I'm pretty sure that if I reimage with a CD and then try the ghost console again it will work because it will overwrite the disk... Would there be anything else to check before doing this?
There could be a number of reasons for this. Perhaps the original vendor configuration of the hard disk has hidden or non standard maintenance partitions which are not visible to the operating system. The boot sector may also be non standard to support a vendor specific boot manager.
If you are able to boot to a WinPE command prompt, you could run DISKPART and examine the actual disk structure
LIS DIS will show all the visible disks
SEL DIS x will select a specific disk number
LIS PAR will display the partitions on the selected disk
EXIT will close DISKPART.
There are other options which you can read about on Google or by typing ? at the diskpart command prompt.
If you wipe the hard disk completely you may indeed find that imaging works, but make absolutely sure you have a good backup of the drive if you need access to the data at a later point in time.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Ok, I get this a lot with the Dells I use. Just because they say they are Broadcom BCM57xx, doesn't mean the Ghost pre packaged driver works. What you have to do is download the driver package for the network card for that machine using the Service Tag on Dell's site. The firmware is probably different from the other devices you use, and that is the issue.
Extract the NDIS2 drivers from the package you downloaded, create a new folder on the Ghost server in C:\Documents and Settings (Or users for 2008)\All USers\Application Data\Symantec\Ghost\Templates such as Broadcom BMC57xx - Optiplex 745, and put everything in the original BCM57xx template in that folder, then copy your NDIS2 drivers in there also. Overwrite anything it prompts you for.
Next, change the machine settings in the Ghost console. Open the machine and select Client. Go to Manually Selected Template and select the template that matches the folder name you created. Try the image again.
Followed your instructions exactly but the results are the same.
Would you like to reply?
Login or Register to post your comment.