Understand how the DriverPack works

the Base program will create your PE plugin for you both for xp and 2003.
no need for you to do anything except include them in your builds.

the lines i believe are self explanatory.

Please see the bartpe tutorial in my signature

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!

The DriverPacks, the DP_Base program, and Support Forum are FREE!.

Hi,
what do the lines mean?
http://forum.driverpacks.net/viewtopic.php?id=2461

Hello there. I'm new to your forums--I just found your site. Not sure why it took so long!

I've been using BartPE for ages and also the UBCD plugins. I believe I saw something else in the forums about UBCD and driverpacks, but not within the context of BartPE. Hence, I've posted this reply. Please move this if in the wrong place.

The "Administrator's" tutorials were helpful, but still leave a few unanswered questions. Perhaps these questions are similar to what others might ask:

1) I use BartPE and UBCD plugins to provide driver support for many varieties of hardware. I would really like to understand how to "cleanup" my plugins configuration so I am using a consistent method to load all the drivers I can. Right now, I run all of the UBCD and I even have a "raid" plug-in, but it's not active. I don't think it ever worked. Likewise, I think I have other "driver" plugins in order to add things like Dell wireless drivers, etc. How should I configure PEBuilder to use your drivers and should I continue with the UBCD plugins?

2) I ran the Base program and chose the BartPE configuration as described in your tutorial. It takes the mass storage drivers as indicated, but it doesn't do anything with the other driver packs. For these, is the proper method to slipstream them into my XP/2003 distribution instead of having them get "loaded on the fly" as the UBCD drivers do?

3) Is there any chance I could just stick an updated DriverPacks 7Z file and place it into the UBCD plugin folder and it would pick up the new drivers?

Thanks in advance for your help on these. I would be very happy to contribute to your effort as well as I spend a fair amount of time updating the 7z UBCD files to include the latest Intel drivers. We are mostly a Dell shop but have clients who rent a lot of various other brands and we spend too much time trying to keep it all up to date. Having a single, coherent driver loading system with PEBbuilder would be a dream come true.

If there is an easy way I could post my plug-in configuration to make it easier to explain my environment, I would be happy to do so.

Thanks!

So, forgive me for asking, but I guess the general answer is for the BartPE world, you can use DriverPacks for MassStorage (which, mind you, if you do what I do for a living, is  a HUGE win to have others helping out with this!) and then, for the other stuff, use UBCD4Win and their driverpacks (not to be confused with driverpacks.net, I gather), therefore NOT enabling the mass storage driver packs from UBCD4Win during the BartPE plugin controls.

That sound about right?

Time to check out the UBCD4Win group again, as I was under the impression that they weren't updating their driver packs any more.

And, if you're up to it, if UBCD IS updating their mass storage pack, why wouldn't you guys want to somehow work together so you could use a single .7z file and repurpose some of your efforts? It's almost sounding like if UBCD4Win is still updating, I might as well just use UBCD or is there still some added value with the the driverpacks.net driver packages?

I have to believe I'm missing something. Perhaps you don't work completely with BartPE (yet) but how else would you use the driver packs now, if you wanted to use them? Is there really life after BartPE (or PE Builder) :-)?

-Ken

Now I'm feeling MUCH better!

Last question, since I bet anyone reading this thread (now or later) would want to know...

"If we are mostly interested in BartPE building, should we use the UBCD4win Mass Storage plugin, or just use UBCD4Win if we're already using UBCD4Win for all the other driver packs?"

And yes, of course, I'd be happy to test your RC. I need to find the pointer to that download so I can help join the effort.

Cheers,
-Ken

I finally had a chance to dig deeper into this so I could completely understand your reply. For anyone reading this thread, I hope you will finally understand it as I do now.

You see, I started with BartPE and loved the idea behind the whole project. And UBCD came out and was the leader in the drivers "collection" plugin because it was stupid for the odd one of us to add "dell wireless", or "HP-servers" or what have you. The UBCD_drivers_full was the bomb. It just didn't get updated after a while. It also required Autobuild, which was cool in-and-of-itself, but I believe was part of the reason why I was confused on how to use the current DriverPacks with a stock BartPE build.

So what was confusing me, was how DriverPacks.Net and UBCD were connected.

UBCD4Win clearly took off. They weren't just going to stop at drivers and they wanted to add everything into their "disk" including the kitchen sink. This, for some is way-cool, but for us Tech Repair folks, just having a customizable builder, with EVERY MASS STORAGE driver, and possibly every wireless and LAN driver is a small step short of heaven.

What I found, is roughly the same that the UBCD4Win folks found, and that's some nasty interactions between either the BartPE builder and the MS drivers, or something that's way over my head. And that is, adding EVERY driverpacks.net driver pack to your BartPE build, whether using a "clean 3.10a" or the 3.22 UBCD4Win build, you just can't get it to fully work properly. My issue is I can't get the mouse to load, and sometimes the shell won't load either. The UBCD4Win folks suggest using only the MassStorage driverpack, but I've found good success using the WLAN and LAN driver packs too. So, I know the problem is somewhere in the Video, CPU or Chipset driverpacks. The Video one is obvious on what it can bring to the experience, the other two less so.

But, if you're reading this thread. My suggestion is to start with a clean 3.22 build of UBCD4Win and then add additional driverpacks.net drivers incrementally. The way you do that is by copying the .7z file into the same directory (the UBCD4Win\plugin) where the BASE driverpack is located, and then re-run the BASE plugin using CONFIG Plugin. Then, to customize your bootdisk, just add/remove plugins that are there from the UBCD4Win installation.

Still confusing to me is the "Bâshrat the Sneaky DriverPacks". I still really don't know what they are, but I'm assuming they are the Driverpacks.net drivers, only with an old name. The Bâshrat the Sneaky driverpacks are what the UBCD4Win folks refer to and they don't really mention the Driverpacks.net plugin unless you do a log of digging.

As for the 809RC1, I never found much success in that one because I was trying to include the whole set of driverpacks (other than sound) and ran into the missing mouse problem. I think I've since tracked it down to a USB mouse problem, while PS/2 may work. As for an 8110RC1 image, I would be happy to try that. It's just important for testers to understand the best/intended way to use it. If you start with the UBCD4Win collection and then just add driverpacks, you probably aren't testing much of the 8.x slipstreaming features, if any. Since I practically owe my business to driverpacks, I am more than happy to test what you have available in order to keep this effort alive.

Cheers,
-Ken

So well put. Bâshrat the Sneaky. Gotta love it. Lol.

Wim, you are my hero as well.

On a different note, perhaps someone could create an "RC" thread and peg it to the top of the list so more of us willing to help test could find it.

And on a yet another note, I was so joyful the other day when I booted a UCBD4Win variant, with Mass Storage, WLAN and LAN driver packs, from a USB stick, on my server and it worked beautfilly. Made my week.

-Ken

I looked at your tutorials before I made a reply to you in this thread.

I've (personally) ALWAYS had a 'production grade' disk as well as a "beta" version. And since I don't RUN any of MY computers on these disks anyway, I can assure you that I wouldn't run some nightly on anyone else's PC. Let me be perfectly clear--my time is precious, and since I work on other folks computers all day, I rarely have time to do anything on MY computers. Of utmost importance is the ability to access a problem computer's hard drive using a another boot disk and as that stands right now, the UBCD/Driverpacks.Net (aka Bâshrat the Sneaky driverpacks:-)) the current disk I hav pretty much hits the mark. So, why, you might ask, would I be interested in testing?

I used to write code for a living and I know the value of a GOOD testing group. There are always folks who want to get an "alpha copy" of the code, just to check it out, but then provide no useful feedback. My feedback might be limited too. The way I see it, I used to have a REALLY NICE repair disk but was growing tired of updating the drivers on it, especially for those pesky INTEL storage matrix drivers, so I cracked open my build config and tried all the new code. And guess what, it works, but only sometimes.

Where I can help is documenting what works (or should) and what doesn't.

And, with the new config, I suspect I will spend the next month or two trimming down and merging in the plugins that I want/need and those that I could care less about. I certainly don't need four different defraggers.  And during that time, I will end up making a LOT of builds, and each one of those could be built with beta/nightly code if you are interested in my feedback.

In the "early days" the whole BartPE project seemed almost "cult-ish" in that only serious techies could understand how to make it work, or could really appreciate the usefulness of the end result. At some point, the project had some decent documentation written for it that made it understandable to the above-average-noob and that's when the "UBCD-like" copies exploded on the net. It seemed the project had hit the critical mass and the general public could all benefit from it. But it didn't really happen. Not sure why. I was almost expecting the better software companies to begin building the plugin inf code for their product and including a BartPE installer as part of their InstallShield installer config. How simple was that? But it never happened. Sometimes I think the original developers (perhaps not Bart himself) didn't want that level of success. I really don't know. But what I do think is that this turned into another one of those projects that starts out with a great idea but lands one step shy of mass acceptance and use. And it won't be the last project to do this, nor is it the first. I used to work in Digital/Compaq corporate research and I know all too well what happens with projects like this.

So where I'm going with this diatribe, is just that I really don't want this project to stall, get boring, or only be used by techies. Sometimes, all it takes is a little polish or some guide that paves the way to increased adoption of a project. And the more folks who can make use of this project, the better off they will be. Anyway, my offer to test is there.

BartPE is both: a windows installation and a running windows.
Let's call this a running windows installation.

Basic hardware is detected at textmode part. This is part of regular windows installation.
This includes chipset. Without basic chipset support, no OS does run.
Example: pci.sys supports PCI bus. A current machine dosn't boot without pci.sys.
Txtsetup.sif [HardwareIsDatabase] *PNP0A03 defines PCI bus driver pci.sys. 

Basic chipset drivers are loaded, running and active at BartPE.
They are not nicely documented at device manager.
Simple solution: ignore chipset at device manager.

There is limited PNP at GUI mode.
A example:
USB controller was loaded again.
Attached devices lost connection, USB mouse is not available anymore. USB mouse dosn't work anymore.
USB mouse requires addional PNP. This is not part of default BartPE, can be added.

DP_Chipset_*.7z contains *.inf files without *.sys files mostly.
*.inf does load windows default *.sys drivers. Read there is no driver file *.sys added, just *.inf add a nice entry to device manager.
Importand windows default *.sys drivers are loaded at BartPE anyway. Remember that's part of textmode setup.

Contrary there are some *.sys files at DP_Chipset. This may make a difference.
Full conditions are not tested yet.

Current advise: do NOT add chipset drivers to BartPE

To make it more complex, windows support another PNP: CriticalDeviceDatabase.
Regular windows use this. BartPE support this too.
Thay way you may add hotplug USB keyboard and mouse, nice at a KVM.
http://www.911cd.net/forums//index.php?showtopic=20987