You are not logged in. Please login or register.
Active topics Unanswered topics
Search options (Page 41 of 159)
DriverPacks.net Forum » Posts by mr_smartepants
mindwarper wrote:- Is it necessary to inject the drivers into install.wim after integrating them into boot.wim? or is that double the work, I am not sure...
The two .wim files do completely different things. The boot.wim is the PE environment and is ONLY used to detect the drives and extract the install.wim to the primary partition.
After restart, the boot.wim doesn't do anything because the system has booted from the primary partition.
So, really, the only pack that needs to be integrated into boot.wim is the dpms. DriverPack Chipset is only needed if you're trying to boot from a USB3 device or something else covered by the Chipset pack.
Here you go mr. impatient! 
link removed
Like I said, it's a big mess! 
Good luck! {runs away to minimum safe distance...}
DriverPack Chipset x64 is done. I'll upload the RC to mediafire for you to test.
Here's the changelog for the current build:
Changelog:
11.08 Aug 2011
Added:
- Nvidia\4 NVIDIA SMU
DriverVer= 03/22/2010,5.1.2600.0208 (newer than Nvidia\3 but with fewer HWIDs)
- USB\Prolific Prolific USB-to-Serial Comm Port
DriverVer=04/29/2011,3.3.17.203
Updated:
- Intel\1 Intel inf package (includes netbook Poulsbo Vista driver)
DriverVer= 9.2.2.1029 (6/23/2011)
- Intel\MEI\3 Intel Management Engine Interface (Intel 3-Series Chipsets)
DriverVer=09/18/2009,3.2.20.1046 (from MEI_v3.2.50.1059 package)
- Nvidia\2 NVIDIA SMBus (from 15.57-nforce-winvista-win7-64bit-international-whql package, supports Win7 now)
DriverVer= 03/22/2010, 4.7.9
- USB\Intel\1 Renesas Electronics USB 3.0 Root Hub
DriverVer=06/10/2011,2.1.19.0 (from Intel USB3_allOS_2.1.19.0_PV.exe package)
Known errors:
x64\C\Intel\1\cdvcore.inf (no .cat file)
x64\C\Intel\1\DH89xxCC-ahci.inf (no .cat file)
x64\C\Intel\1\DH89xxCC-cor.inf (no .cat file)
x64\C\Intel\1\DH89xxCC-id2.inf (no .cat file)
x64\C\Intel\1\DH89xxCC-ide.inf (no .cat file)
x64\C\Intel\1\DH89xxCC-smb.inf (no .cat file)
x64\C\Intel\1\DH89xxCC-usb.inf (no .cat file)
x64\C\Intel\1\NehalMEX.inf (incorrect SHA-1 hash in .cat file)
x64\C\Intel\1\patahci.inf (no .cat file)
x64\C\Intel\1\patcore.inf (no .cat file)
x64\C\Intel\1\patid2.inf (no .cat file)
x64\C\Intel\1\patide.inf (no .cat file)
x64\C\Intel\1\patsmb.inf (no .cat file)
x64\C\Intel\1\patusb.inf (no .cat file)
x64\C\Intel\1\SNB2009.inf (incorrect SHA-1 hash in .cat file)
x64\C\Intel\1\Tcreek.inf (incorrect SHA-1 hash in .cat file)
Error - The driver package contains x64 boot-critical drivers, but the drivers are not properly signed.
Use the /forceunsigned option to install the drivers.
The driver-signing errors are purely Intel's fault, and have been for a while now. The have v9.2.3* in testing, but the beta build I grabbed still doesn't fix the above errors. Again, this is Intel's fault.
Not unless they fix their installer so I can extract the drivers without having to install them. 
Implemented in 11.08 (not yet released)
Yup, when Realtek's WHQL key was compromised, M$ issued a hotfix that would render any driver using that certificate as "malware" and remove it. That's the only documented case of driver-level hacking that I'm aware of, and it hasn't happened again...so far.
Maintaining driver-signing whenever possible is one of our core values.
For driver signing, only the OEM can fix that. The current Intel chipset drivers are v9.2.2.1029 from here:
I will use these to update the Chipset DriverPacks but the driver date/version have not changed for those unsigned drivers.
The /forceunsigned flag is generally not recommended but will not cause problems unless the driver files have been tampered with, then you will have a compromised install source. If you are 100% certain of the unsigned driver source, then use the flag.
The only other way to "fix" the error is to delete the unsigned .inf from the packs.
If all you want to do is integrate drivers into the boot.wim, you'll need to remark/comment or delete the lines in the batch file that integrate into the install.wim.
You don't need chipset drivers in the boot wim unless you're trying to boot from a USB3 device.
OK, well now we're making progress. Having no drives detected is much better than a BSOD. The BSOD must be caused by something you're doing to the install process, not DriverPacks.
Hopefully I'll get some time to work out a solution (next week) if someone else doesn't beat me to it.
Well, DriverPacks Finisher doesn't yet work with NT6 builds (or should I say it's not tested yet), so the script doesn't extract DriverPacks Finisher when the target OS is NT6 (vista/win7).
What OS is the target?
There are no nightly NT6 builds at the moment. We just test in DISM and if there are no build errors we release.
The current release dpms is 11.05.1
I'm working on a 11.08 release but I'm on vacation so I'll release it when I get a chance.
As a reminder, the Third Party DriverPacks are "community-built" packs. So people like you can update them and repost them for others.
The DriverPacks Team will periodically "finalize" them and upload to the main distribution server every 6-12 months.
It's not up to the Main Team to update all the Third Party DriverPacks. I only update the few that I use (HID, Misc, WebCam) and only when I have spare time (rarely).
As a reminder, the Third Party DriverPacks are "community-built" packs. So people like you can update them and repost them for others.
The DriverPacks Team will periodically "finalize" them and upload to the main distribution server every 6-12 months.
It's not up to the Main Team to update all the Third Party DriverPacks. I only update the few that I use (HID, Misc, WebCam) and only when I have spare time (rarely).
As a reminder, the Third Party DriverPacks are "community-built" packs. So people like you can update them and repost them for others.
The DriverPacks Team will periodically "finalize" them and upload to the main distribution server every 6-12 months.
It's not up to the Main Team to update all the Third Party DriverPacks. I only update the few that I use (HID, Misc, WebCam) and only when I have spare time (rarely).
Yes, the WebCam Third Party DriverPack needs aggressive folder shortening. I just don't have the time.
If you eliminate the WebCam pack from that lineup, I'll bet that your install will work fine.
As a reminder, the Third Party DriverPacks are "community-built" packs. So people like you can update them and repost them for others.
The DriverPacks Team will periodically "finalize" them and upload to the main distribution server every 6-12 months.
It's not up to the Main Team to update all the Third Party DriverPacks. I only update the few that I use (HID, Misc, WebCam) and only when I have spare time (rarely).
That sounds like a convoluted install to me. You might be better off with an image-based install by using Offline-sysprep.
So, just to eliminate your method from the equation, can you try a traditional disc-based install? Just use a standard 2003 disc, copy to a folder on the desktop, integrate dpms via DriverPacks BASE using the defaults (check dpms and txtmode), then build the .iso and burn to cdrw or dvd-rw and try that. I just want to ensure that dpms works on your hardware and not being fouled by your install method.
Ooh, nice find. I missed that one!
TechDud wrote:Would a DP_CardReaders_nt5 be a good candidate for a first project?
No, the cardreaders pack was merged into the misc Third Party DriverPack a while ago. The Monitors Third Party DriverPack needs a refresh and it's folder structure is appalling.
As an example;
DP_Monitor_wnt5_x86-32_1005.7z\D\3\MON\ACR\AF715\
should be;
DP_Monitor_wnt5_x86-32_1005.7z\D\3\MO\A\A1\
...a reduction of 7 characters. Compound that by a minimum of at least 50 other folder infractions like that and you could potentially save over 400 characters from the 4096 limit.
Third Party DriverPack webcam is another that I just finished that could have it's folders aggressively renamed to shave precious characters. I just don't have the time.
TechDud wrote:would it be best that Win2k, 2k3, & XP_64 drivers be included where possible? 
Not XP-64, we will never support that monster. For NT5-based OS, we only support 32-bit.
kesh wrote:i don´t want to press any button. I´m so lazy
Me too!
Just delete the "pause" from the script and there will be no "press any key to continue"
Yep, as I suspected. As a general rule you should only include the Third Party DriverPacks that are "required" by the main DriverPacks (ie. Graphics Languages, Runtimes & PhysX) and MAYBE one other.
All others should be installed using SAD or SAD2 post install. SAD2 is not limited by the file/folder path length bug, so ALL DriverPacks can be installed via SAD2 (only a few graphics/sound drivers have problems with the utility).
Long gone are the days we could just include every pack on the disc and call it good.
Marking as "Solved".
11.07 is now on the torrent server.
11.06 has serious filepath issues that are mitigated in 11.07 but not eliminated. Further folder pruning is in order but I just don't have the time to fix it properly.
I already have the ENE section updated.
TechDud wrote:I would like to know what others think of my involvement.
I think maybe you should start by updating/maintaining the Third Party DriverPacks.
I can't do it all by myself.
Hmmm, I'm not sure what to do with these. The file dates are newer but the versions are older. Odd mismatch. 
Posts found [ 1,001 to 1,025 of 3,963 ]
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.091 seconds, 6 queries executed ]
