You are not logged in. Please login or register.
DriverPacks.net Forum » Posts by mr_smartepants
Just as an FYI, when DriverPacks are integrated, the DPbase backs up key files in your windows source (winnt.sif, dosnet.inf, txtsetup.sif, etc.)
These files are renamed with a *.org before modifying them (.org is for 'original').
When these *.org files are NOT found, this is logged as the DriverPacks being installed into source where none were before.
Don't worry, this is by design. 
I use DriverPacks with runonceex with WPI and have zero problems. You WILL have a problem if you select DriverPacks to run at GUIrunonce because both guirunonce and runonceex execute at the same time (weird I know).
The DriverPacks runonceex defaults are fine with WPI, I do it all the time.
mr_smartepants wrote:DPBase integrations are successful for 99% of users. You guys are the 1% with issues.
I must say that I didn't have any problem with the 2 desktop graphics cards I tested the drivers with, I had problems only with 4 mobile graphics cards.
THAT is the prime indication that "Driver-signing" is screwed up somehow on your install. I can confirm that it works perfectly fine on my testbeds.
Thanks for your report.
We are working on a solution to the 'corrupted DriverPacks' problem.
If we find a solution, it will be included in DPBase 8.07 or 8.08.
For now, we recommend checking all downloaded DriverPacks archives for errors with 7zip or winrar.
You should also double-check the MD5 signatures of all DriverPacks with the repository.
Whoa, OK. That's odd.
\D\ directory shouldn't be tagged as read-only. Do you change/delete users through nlite?
Welcome to DriverPacks.net!
http://forum.driverpacks.net/viewtopic.php?id=4
We need that. 
There should be no difference between Retail vs OEM vs VLK installs where drivers are concerned.
*Edit,
Oops, I missed the part where you mentioned Dell. Dell and other OEMs sometimes bundle drivers in their install CDs for their own machines.
The finisher loaded two reg entries to delete those items:
2008-07-10 23:28:44 : <CLNP> Added new value to the RunOnce key in the registry: the cleanup of the "C:\D" directory will be retried (through CLI, not through the Finisher) after a reboot.
;
2008-07-10 23:28:44 : <CLNP> Added new value to the RunOnce key in the registry: the DriverPacks Finisher itself will get deleted after the next reboot.If you had done nothing but reboot, that directory would have been deleted automatically.
Welcome to DriverPacks!
Well, looking at the HP website, you should be fine downloading the following:
Chipset
CPU
Graphics_A
LAN
Sound A
Sound B (I have no idea what audio chip you have, so grab both DriverPacks)
WLAN
Also grab the Modem dp from here.
Be sure to report back with any problems, AFTER you've read the "Read before you post" section here.
Have a nice day.
*Edit
Overflow beat me to the punch by 50 seconds! ;P
I have always integrated the DriverPacks last with DPBase. Do I have to add those entries you mentioned to the file created by DPBase?
No, DPBase takes care of that for you.
How is that bug possible if the signing policy is already disabled bye DP Base ?
It's possible that another entry is required to ignore the driver-signing policy that is overlooked, and not added by Base. I don't know. More research is needed.
DPBase integrations are successful for 99% of users. You guys are the 1% with issues.
Welcome back Jaak!
The file can be found in your %XPsource%\i386\winnt.sif
If you use DPBase to integrate the DriverPacks, the file is created and edited for you.
If you use an unsupported method to integrate the DriverPacks, you're on your own. 
Nlite will make the file for you, but it won't add those entries by default.
This is exactly why we always recommend you integrate DriverPacks LAST, and just before building the ISO.
Thanks Woody22!
You just answered the question I was just about to ask.
To answer your question, yes, the drivers are WHQL, but that doesn't affect driver signing.
The drivers in 806G are signed ONLY for desktop cards. Mobile cards are NOT DIGITALLY SIGNED, and in order to use them correctly driver-signing must be disabled in XP.
That's the root cause of the yellow exclamation point in the device manager or the dreaded "Code 10-device cannot start" error.
Now we need to get samlab and krige to retest with driver-signing disabled in the winnt.sif file:
[Unattended]
DriverSigningPolicy=Ignore
NonDriverSigningPolicy=IgnoreWell, I think we'll stick with 175.19 for the time-being.
I'm not sure what's going on with the yellow exclamation point. I'll have to go through the .inf looking for errors. In each case, it's a card supported by our third-party .inf.
Yes, it is always sad for us to see our hard work go to waste on warez!
But Kal is doing good work here.
OK, I'm at a loss.
I have a feeling the problem is in the nv4_go.inf file. My card is supported by the factory .inf so installation goes without a hitch. The mobile cards are supported by the _go.inf which is made by a 3rd party.
I'll see if I can narrow down the problem.
Well that sux!
Tell me Kal, do you use sysprep? Or BartPE? Or a normal integration?
what if the new folder was G_Com (Common) and contained the main files...
then if ati mobile or GA was selected then G_Com would automaticaly be selected?
Sure, I suppose. You could put the common items (control panels etc.) in G_Com and have the finisher take care of the rest. The drivers on the other hand would need dedicated folder structure since some of the .infs are looking for specific folder names (that we cannot change due to driver signing). It's an interesting concept. Hmmm.
Well there's your problem right there. Stay away from illegal warez downloads...you never know what you're going to get!
You should always start with a fresh source when doing your integrations.
SP3 v3311 isn't current anyway. v3311 never included the HDAudio fix.
Isn't SP3 up to v.5321 or something now?
Because the ATI/nvidia mainstream drivers are shared between their desktop/mobile counterparts, there's going to be a size hit by splitting the DriverPacks because of the overlap. We'll have to have multiple copies of control panels etc. to make each DriverPacks standalone. Unless you use a dependency (G_C depends on ATICCP from G_A) in which case you're not saving any space.
One option is to increase the number of graphics DriverPacks but split them into sub groups (G_A-a ATI, G_A-n nVidia, G_B-i Intel, etc.) since this would make it easier to update and release DriverPacks and lessen the server load since you wouldn't have to download a huge monolithic DriverPacks to get a single update. But this would require the dpbase to be recoded with the new naming schema.
Yes, please try the latest nightly. G_A 8.06G has been working great for me.
175.16 vs 175.19: full review http://benchmarkreviews.com/index.php?o … ;Itemid=47
Well WTF!
What is nvidia trying to pull?
OK, so NONE of their drivers are release worthy?
Sigh...
UPDATE 06/27/08: Only one day after this article was published, NVIDIA has pulled the Forceware 175.19 driver from its website and re-published the version 175.16 driver. Benchmark Reviews agrees with their decision, as the Forceware 175.16 worked considerably well in all of our tests.
Which is the most STABLE & RELIABLE under the majority of cards?
175.16 (still listed as current for US english)
175.19 (still listed as current for all other lang)
177.41 (listed as current for newest 200 series cards)
Opinions...
I am not sure how this would be possible as most ATI drivers I have seen reference the mobile drivers
Actually, the official ATI mobile drivers only reference about a dozen chipsets or so. The other hundred (I exaggerate) are added by the mobility.inf which is NOT digitally signed and we add/subtract from that .inf whenever possible to avoid breaking the driver-signing.
Well, G_A 806G works great on my two platforms. ATI 9600Pro Mobile, and Nvidia 8800GTS 512.
Thanks SamLab, G_B is next on my to-do list.
The ATI inf files reference the X300 (the mobility.inf does not - as someone commented out the X300 entry. -I think they should add it back in and fix the hardware id of ati2mtag_M22, PCI\VEN_1002&DEV_5461 to 5460 instead of the x200's 5461 - which is why I think it is commented out.)
I originally commented out the HWID in mobility.inf because it conflicted with the standard .inf from the mobile catalyst drivers. Now there's a new mobility.inf, this is a non-issue.
Hi,
I still think we'll have to consider a real split.
DriverPack Graphics A / b /c and dpgM for the Mobile drivers (because they share common silicon and code, but fight about how it gets used.)
This is definitely possible. I'm not sure if the DPBase is coded with hard paths to ATICCC/ATICCP. It is much easier to let the DPFinisher to do all the work with exceptions.
The downside is increased filesize since we need to make all DriverPacks standalone.
Just DO NOT switch modes with an OS already installed, that is guaranteed to screw things up beyond all reckognition.
That's exactly what I did. But it only took me about 15 minutes to fix.
806G deleted from nightlies folder
And now uploaded 806G...
Heh, sorry about that. Had a power failure mid-upload. So I deleted the partial file, then re-uploaded when I had a chance.
806G online. See first post.
Reverted nvidia from 177.41 to 175.19 per SamLab request.
I didn't even get a chance to test yet.
806F was working fine for me on 8800GTS
DriverPacks.net Forum » Posts by mr_smartepants
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.
[ Generated in 0.115 seconds, 5 queries executed ]