We now return to “As the Ghost Solution Suite Turns”
Last time, we learned that WinPE 2.0 was replaced by its evil twin, WinPE3.1!
(https://www-secure.symantec.com/connect/articles/creating-and-using-winpe31-image-gss-251)
You may be yelling at your TV right now “don’t, it’s a trap! Everyone will know you are the evil twin when you still can’t load the driver I need!”
GSS can “load” any network or storage driver you want. I say “load” in quotes because it just checks for info in a manifest, and if the info is there, it lets the process continue. Go back to your COMMON folder under ProgramData\Symantec\Ghost\Template\COMMON and find your new PE3 folder again. Inside of it you will see the following 2 files
1. Drivers.manifest.txt
2. Pci.manifest.txt
Make copies of both of them and add “ – Original” to the names so you have the working ones
Open drivers.manifest.txt. you will see a lot of entries that look like this:
"Intel I217" = {
class = network,
selected = 0x1,
drivers = ({
path = "Broadcom.DGE-500SX\\NETDGE.INF",
os = ("VISTA")
})
},
You know what is interesting about the one I just listed? It says Intel 217, but points to a Broadcom driver. Its because I made it up and inserted it into the file as a dummy entry to help GSS think it has a driver. “class = “ can be either NETWORK or STORAGE. Selected is whether it thinks the box is selected. Drivers is where the file is (steal a different one you already added), and OS is the OS boxes that would be checked, separated by spaces (if you care [“VISTA” “2008”]).
Put in some placeholder like I did, and save it. We now move on to the other one.
Open pci.manifest.txt. This one is a little more fun. If you have tried to run the PE3.1 image from the last article and got a missing driver error in the “To Virtual Partition” step, this is where the magic happens. You will get the info for the missing driver. Pay extra attention to the following info it lists. It will give you a name, “PCI Vendor: 0x”, “PCI Device 0x”and “PCI Subsystem 0x”. Look at the items in your PCI.manifest.txt. Entries in this file look like this:
} {
0x8086 = {
0x2682 = (0xb0031458 0x31fe103c 0x898015d9 0x888015d9 0x848015d9 0x838015d9 0x818015d9 0x808015d9 0x31fe1014 0x2dd1014 0x3321014 0xb0031458 0x31fe103c 0x898015d9 0x888015d9 0x848015d9 0x838015d9 0x818015d9 0x808015d9 0x31fe1014 0x2dd1014 0x3321014),
0x27c3 = (0x798015d9 0x918015d9 0x778015d9 0x2fc1014 0x2fd1014 0x2fe1014 0x3206103c 0x798015d9 0x918015d9 0x778015d9 0x2fc1014 0x2fd1014 0x2fe1014 0x3206103c)
}
} {
Can you find a set that matches the 0x vendor code? You may have more than one! Each driver set you added adds its own entry in this table. You will see lots of 0x8086, because that is Intel. If you found one, piggy back into it (I recommend in the middle, its easier to make sure the stuff is correct). Copy a line from inside of it and paste it in. Change the deviceID on your pasted line to the PCI Device it gave you in the failure. Change the numbers inside the parenthesis to match the Subsystem ID. Put a comma at the very end if your line is in the middle of the entry set.
You should have ended up with a line that looks like this
0x153a = (0x1998103c),
In the middle of that set. Save your file. When you restore with that the next time you should not get an error. If you get the error “failed to load the driver manifest”, you probably missed a comma. Good thing you kept the originals! Try it again. Those braces and commas are everywhere