You are not logged in. Please login or register.
DriverPacks.net Forum » Posts by Galapo
Thanks for that.
I'd figured out it was uncompressed despite the name. So that left the options whether it was intentional or unintentional. I was getting problems since the .INF referenced .cap and not .ca_, so needed to ask. Thanks for helping!
Regards,
Galapo.
Hi
Under D\G\A1\B_68405 we find the file: ativvaxx.ca_. I'm curious as to why this file has this extension rather than ativvaxx.cap as referenced in CX_68569.inf.
Please forgive this question if it is straight-forward: I'm usually only dealing with the mass storage pack.
Thanks,
Galapo.
Currently for OfflineSysPrep and the mass storage script of LiveXP I'm using a "hotfix" solution: if "nvgts" exists in the driver's name, then the PnpInterface registry entry is added.
Regards,
Galapo.
Thanks Overflow!
Looks like Lancelot beat me to posting!
Let me explain a little more fully:
Driver Import PE is a program which runs under a PE environment -- BartPE, UBCD4Win, LiveXP, etc. It's intention is to install drivers to the PE so as to get functioning devices be they networking, mass storage, sound, graphics, etc. Drivers may be installed to the PE system from:
- host OS (ie, the offline system residing on the computer if one exists)
- OEM drivers from specified location (harddisk, usb, network, etc.)
- DriverPacks .7z archives
Note: PE must have writable %SystemDrive% which may be achieved by adding FBWF (for CD-based PE) or SDI (for ram-image-based PE).
BartPE plugin may be downloaded from here and WinBuilder script may be download here.
Now your PE can still get working devices even if the PE is built without the necessary drivers!
Thank you again Kare for your hard work in developing Driver Import PE -- it is a real breakthrough!
Regards,
Galapo.
having your app check for and remove that line when discovered is certainly the best option.
Yep, I agree. Knowing what we know from the example of this thread, Driver Import PE should simply ignore/skip the "reboot" line if encountered. That is, don't take for granted that a "reboot" is essential for PE environment to actually get a working device.
As always, thanks for testing, Lancelot!
Regards,
Galapo.
Well, if there's no help or feedback when it's needed, then that isn't helping the exceedingly useful project that DriverPacks is. Just my thoughts.
Thanks for your work, too!
Regards,
Galapo.
Understood now. I can add something on that too.
Regards,
Galapo.
OK, will do. I'm sure there's others who will benefit from being made aware of this.
But what do you mean about me having a sticky?
Regards,
Galapo.
A thought: could Driver Import PE choose to reject the need for a reboot and attempt the installation anyway?
Lancelot, what happens if you modify DP JRAID_I.inf [JM] section to that of the OEM [JM] section given above?
Regards,
Galapo.
Interesting:
DP JRAID_I.inf [JM] section has:
CopyFiles=JRAID.Copy
RebootOEM jraid_f.inf [JM] section has:
CopyFiles=JRAID.Copy
Addreg=Inst.AddRegCould that be the issue?
Driver Import PE is a fantastic tool for PE -- and getting even better! It allows for installation of drivers -- even mass storage drivers -- into a PE so as to get functioning devices. Drivers may be installed from the host OS or other supplied location. It is very useful and supplements DriverPacks well.
Regards,
Galapo.
Thank you. I'll leave it up to you and your expertise to decide which driver to update to.
Regards,
Galapo.
HWID PCI\VEN_1095&DEV_3132&SUBSYS_71321095
As reported here, the driver in the mass storage pack is quite an old one. This older driver isn't quite suitable: http://www.boot-land.net/forums/index.p … mp;p=47699
New drivers exist: http://www.siliconimage.com/docs/3132r5 … 0_logo.zip and http://www.siliconimage.com/docs/3132r5 … 0_logo.zip. Both are tested and working for the above HWID. My suggestion would be to include one of these newer drivers in the mass storage pack.
Thanks,
Galapo.
RE: HWID PCI\VEN_1095&DEV_3132&SUBSYS_71321095
The driver currently in the mass storage pack is 1.2.3.1. This creates problems for the above HWID: http://www.boot-land.net/forums/index.p … topic=6047
Newer drivers are available, which work:
http://www.siliconimage.com/docs/3132r5 … 0_logo.zip
http://www.siliconimage.com/docs/3132r5 … 0_logo.zip
Strange issue remains: Drives are assigned a drive letter (usable in explorer), but don't appear with a driver letter with diskmanagement: http://www.boot-land.net/forums/index.p … mp;p=47957.
Any ideas? Is it worthwhile updating the pack to a newer driver?
Thanks,
Galapo.
I'm miles from there in Australia...
I just tried to download the Graphics B pack again and got the error. Another click and it was downloading.
Regards,
Galapo.
This is a much bigger issue than 1% or a faulty DNS or ISP. This is 100% down for 100% of the people from my perspective.
It's not 100% as I tried just now to see if I could download and it was fine first try.
Regards,
Galapo.
Riddle: Do you know how you can tell if a farmer is good one, even from a distance?
Having grown up on a farm, I would have said: If you can't see weeds in his paddocks (our neighbours were atrocious, and we even had to go and pull or spray THEIR weeds sometimes!).
Regards,
Galapo.
He means read the link: http://forum.driverpacks.net/viewtopic.php?pid=4#p4
Regards,
Galapo.
I'm not Overflow, but I for one would agree with that.
Regards,
Galapo.
Thanks Galapo! We make a great team
Glad to be of help!
By the way, I assume the change I made to the latest OfflineSysPrep allows you to use sysprep.inf without having to run SysprepInfEditor beforehand?
Regards,
Galapo.
Intel HWID 'VEN_8086&DEV_2929&CC_0106' confirmed working with latest test pack (809D): http://www.boot-land.net/forums/index.p … topic=5746
Regards,
Galapo.
The hwids for your device in question may be determined by running the tool in his signature. Without this, we're only guessing at what's happening.
Regards,
Galapo.
and is why i belive the mass INI should be the source for your sysprep output...
this is in effect the same as stealing the bartpe code...
which is a path for me to explore for createing the sysprep output.
a slight mod to the bartpe code might not be that tough of a row to hoe...
Based on my experience coding OfflineSysPrep etc. for injection of drivers into an offline xp/2003 system, my opinion is that this would be the way to go as it guarantees the generation of unique driver names, hwids, etc.
Regards,
Galapo.
OUCH.
Now, here is a subtle difference between DriverPacks BASE enhanced and Microsoft's setup.
For LOADING TXTmode, we do not use OEM at all, we use our mass storage.INI
(I know, the INI MIGHT be based on OEM, but most often, it is based on an INFs, or, in some cases a combination of filtered HWIDS strings found in drivers of same version inf files.)
Which is exactly why I chose to "pinch" this data for use with OfflineSysPrep, i.e. build a database from an outputted BartPE plugin for injection into an offline system.
Regards,
Galapo.
what am trying to DO is integrate common SATA into GHOST SP3 Image to avoid Crash and blue screen
and then use it with various MB's
If you know your specific drivers, I'd say integrate your drivers before building your image. Usual way is with sysprep.inf, as you should know.
PS. we talk only about Masstorage problem !
If you want to discuss OfflineSysPrep, your request is impossible: OfflineSysPrep was primarily developed to run in PE environment.
Regards,
Galapo.
DriverPacks.net Forum » Posts by Galapo
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.
[ Generated in 0.018 seconds, 8 queries executed ]
