Search options (Page 196 of 213)

Read the "read before you post" in my sig and perhaps you will figure out why you got no response. ;-)

especially numbers 4 and 5

since you have the packs that work you can proceed without waiting
just use the packs from the old cd to create a new uwxp cd
or just use the old cd.

Yes you can edit the mass storage pack yourself and some help is available in the docs folder of base.
however this is not easy. since you have added drivers to bartpe yourself in the past this may be within your ability.
Jaak is quite good at adding drivers and usually turns out test packs in no time. so it may just be easier to wait a few hours on him to do it for you/us.

i looked at the current and previous versions of mass storage and could not find a specific match for these hwid's
PCI\VEN_1106&DEV_5337&SUBSYS_81CF1043
PCI\VEN_8086&DEV_24D1&SUBSYS_80A61043

was driverpacks detecting these controllers before?
i dont think these hwids are now nor were they previously included.

if you never had this working then provide a link to the drivers that do work and add [REQ] to the title of this post.

BartPE is not like sysprep.
Windows will use its normal algorithims to choose the best driver.
HWIDS can be duplicated in some cases.
The problem with Bartpe is you may not have duplicate file names.
so it is sort of the opposite of what you are familiar with.

since in BartPE we copy the files to their destination folders during the build.
(IE sys files get copied to system32/drivers)
this will cause issues with drivers that have hardcoded file names like nvidia.
the last file copied wins. in jaaks example above each of the folders copies the file name fdco1ins.dll
the file name fdco1ins.dll that is actually in the destination folder on the build is the last fdco1ins.dll copied.

now if all the drivers use the same version of the file this will work. however if they are actually different versions of the file (and have the same name) and the drivers are file version dependent then only the driver in the last folder will work.

but still they guys have managed to get a big chunk of the LAN pack integrated without much trouble.
If we were to officialy release this it would be a support nightmare.
because only the last file copied of each file name will actually exist on the bartpe build / disk.
(IE there can only be one file named driver.sys in sytem32/drivers so the last file named driver.sys copied during the build process is the one that will be burned to the PE disk)

when i code this we will have to pick and choose in the pack INF file much as we now do for mass storage.

did this explanation make sense ?

here you go (this will ony be valid for a short time)

removed

don't put that type of info out in the open please. I edited your post.

yes the method itself is still very much alive although it has evolved over time.

the addon is based on the original Pyron code and may see a facelift if you were to point it out to the author.
it may also be worth noting in that thread that it may not be used with the driverpacks in its current form.
although with a little tweaking it might be able to coexist... however the driverpacks are quite complete and i would like to think that if we were missing some drivers they would show up here and request them (we like that).

I can see how this tool would be very useful if you intended to make a disk only to be used on a specific type of PC.

Thanks for your input. it was enlightening for me as well.

well ther is no wonder you are haveing trouble...

the instructions you were useing were written Dec 21 2003, 08:38 AM  those are no longer useful except as a historical (or was that hysterical) review of where we started. Much has changed since 2003. Heck much has changed since 2007.

Please only use the directions you recieve here and you wont be led down the wrong path.

where in the heck did you get ENU_Addons_M2OEM-Drivers_v150907.rar ?

Glad you were able to remove the "meat virus" from your ISO.

Welcome to Driverpacks - We are glad your here!

@Tiger his "HOST" OS is winXP sp3 - however his source is SP2 so that will not affect him...

WatchDriverSigningPolicy.exe is not a driverpacks file... ?
What PYRON instructions are you refering to?
the OEM folder is an exclusively DriverPacks folder so you must be making changes after you run DriverPacks

you must be doing somthing with nLite or manually to cause this.
the best advise i can give you is make sure you are running driverpacks LAST in your disk creation process.

To reiterate you cannot make ANY changes after you run driverpacks if you do it will most likely fail to operate correctly.
Run driverpacks base followed imediately by creating the ISO image.

Thanks for including your logs it makes it much easier to help you!

PS please use code tags...

@mr_smartepants
Could you post more about your issues with SP2 and the beta in the SP3 thread?
I haven't seen this myself and there should not have been any changes to that part of the base code.
I just added a few lines to recognize sp3 and send it to the same subroutine SP2 uses
Not a single letter was changed in the original subroutine for adding the HDA patches. 
if i have some details perhaps i can figure it out.

There is no reference to no longer needing a serial, anywhere, except in his post...
the PIDgen copy is a great piece of advise for everyone... thanks and Merry Christmas!