1 Reply by deadbug

(4 replies, posted in Feedback and Support - DriverPacks Base)

@cdob:

"Approach is hard link friendly."

Thanks. Yes, this is all stemming from the topic over at MSFN.

@OverFlow:

"in most situations you can let your ISO creator do this for you"

True. I use CDIMAGE which does do this (which is just as well, otherwise it would be a 12GB DVD!).

But if I use hardlinks to avoid copies in some places it looks like it speeds things up.

My current workflow for XP Pro is something like:

1. Have a source SP3 directory available
2. Apply RyanVM to SP3 to produce SP3
3. Apply WMP11 (via boooggy) and IE7 (via nLite) to SPR
4. Apply DriverPacks to SPR to produce SPD.

Step (1) involves building SP3 in my DVD from a stable SP3 in a source tree and
using hardlinks shaves a few minutes off.

In step (2) I get RyanVM's integrator to do the heavy lifting from SP3 to SPR - but the slow
part here is the processing and compression etc. No hardlinks involved.

Step (3) only touches SPR (which is not hardlinked).

Step (4) needs an SPD to start with, and using hardlinks again shaves a few minutes
(and now appears to be safe to do).

I also need to build boot folders for SP3, SPR and SPD (I want all of them on the
DVD) and hardlinks should help here too.

So it looks like I'm good to go!

Many thanks both of you for your input.

-- deadbug

Go to forum: Feedback and Support - DriverPacks Base

2 Topic by deadbug

(4 replies, posted in Feedback and Support - DriverPacks Base)

I'm looking at cutting down on the amount of disk space consumed by my various AIO-DVDs and also (hopefully) speeding up it's generation slightly.

It seems that one way of achieving this might be to use hardlinks. The idea would be to have a source (say \SRC\XP\SP3). Rather than copying that to \AIO\XP\SP3 and applying DriverPacks, I would create a bunch of hardlinks in \AIO\XP\SP3 back to \SRC\XP\SP3. This will obviously save space and should be quicker too since no data needs to be copied.

This scheme will fall apart if the tools that I then use to process \AIO\XP\SP3 patch or rewrite files in situ rather than removing them and replacing them, since the hardlinks would then mean that \SRC\XP\SP3 would be altered too.

I cannot see DriverPacks altering any files (except WINNT.SIF) but that might just be a lucky coincidence with my setup. Or I might simply have missed something.

So does DriverPacks currently rewrite any files?

Thanks

-- deadbug

Go to forum: Feedback and Support - DriverPacks Base

3 Reply by deadbug

(17 replies, posted in Installation Platforms)

OverFlow wrote:

look in the docs folder wink

Ah - that's actually quite helpful. As it so happens, I changed last night to using the tag and that produced a working build.
The only problem is that a bunch of stuff was left lying around after the install, so it looks like the finisher didn't get called.
But that's a minor issue - the AIO-DVD install seems to have worked (I've yet to try it on real hardware but VirtualBox is quite happy).

OverFlow wrote:

And Try this amazing new feature that we just invented it is called 'search' wink

I did - how else would I find this thread here :-)

Like all v1.0 features it has a few implementation deficiencies: I cannot search all the forums in one go and it's by no means clear exactly which forum I should look in.

The thing you won't fix in v1.1 is that I'm not sure what I should search for ... multiboot might do ... I've tried ms_1_tag in a few of the forums before posting and it came up blank.

OverFlow wrote:

Also we invented another really cool thing called 'Frequently Asked Questions'.

Hopefully if a few other people ask, then it will crop up in there - if it's there now it's well hidden!

OverFlow wrote:

look in the docs folder wink
we are hoping these innovative new ideas catch on tongue

we are here to help, not baby sit...

They've not caught on anywhere else, but I admire your boundless optimism anyway :-)

My AIO-DVD and I are grateful for the baby-sitting.

Cheers,

-- deadbug

Go to forum: Installation Platforms

4 Reply by deadbug

(17 replies, posted in Installation Platforms)

OverFlow wrote:

RE "DP must know which files it has updated and altered in txtsetup.sif"

we call that file DriverPack_MassStorage_wnt5_x86-32.ini (it is in the pack) wink

That's lucky (for me!).

I've modified the script to use that file as input. The first attempt failed so I had to look a bit more closely.

A typical entry looks like this:

ms_count=1
ms_1_deviceName="AMCC 3ware 9000/9500 SATA RAID"
ms_1_tag="3wareDrv"
ms_1_sysFile="3wareDrv.SYS"
ms_1_hwids="PCI\VEN_13C1&DEV_1002&SUBSYS_100213C1,PCI\VEN_13C1&DEV_1003&SUBSYS_100313C1,PCI\VEN_13C1&DEV_1004&SUBSYS_100413C1,PCI\VEN_13C1&DEV_1004&SUBSYS_100513C1"
ms_1_isBusExtender=false

So I assumed that this bit
  ms_1_sysFile="3wareDrv.SYS"
tells me which .SY_ file to look for in I386.

I soon realised that ms_(\d)_sysFile (i.e. any number) is a better match.

But then I hit a missing masdell.sys in the boot process. That should come from here:

ms_count=2
ms_1_deviceName="Dell PERC 5i/6i (W2K)"
ms_1_tag="msasdell"
ms_1_sysFile="megasas.sys"
ms_1_hwids="PCI\VEN_1028&DEV_0015&SUBSYS_1F011028,PCI\VEN_1028&DEV_0015&SUBSYS_1F021028,PCI\VEN_1028&DEV_0015&SUBSYS_1F031028,PCI\VEN_1000&DEV_0060&SUBSYS_1F0A1028,PCI\VEN_1000&DEV_0060&SUBSYS_1F0B1028,PCI\VEN_1000&DEV_0060&SUBSYS_1F0C1028,PCI\VEN_1000&DEV_0060&SUBSYS_1F0D1028,PCI\VEN_1000&DEV_0060&SUBSYS_1F111028"
ms_1_isBusExtender=false
ms_1_exc_skipIfOS="w2k3"

So now I'm wondering whether I'm interpreting the file properly.

Is there something that describes it? (I did look briefly, but not exhaustively).

Is it possible that ms_1_tag is the name of the .SY_ file I should look at in I386? In which case, what does ms_1_sysFile mean?

I might as well describe the processing (just in case I'm still getting something wrong once the above is cleared up):
  - build a list of drivers that might need to be copied from I386 to the relevant  boot directory
  - for each driver (if it exists in I386):
       if there is no driver of the same name in the boot directory or (the contents have changed AND the I386 version is newer) copy it across

Is that close?

Many thanks,

-- deadbug

Go to forum: Installation Platforms

5 Reply by deadbug

(17 replies, posted in Installation Platforms)

7yler wrote:

Multiboot can be very frustrating to setup, make sure you read through the threads over at MSFN.

I prefer to think of it as a challenge rather than frustrating :-)

7yler wrote:

make sure you read through the threads over at MSFN.

http://www.msfn.org/board/index.php?showforum=82

Indeed. It's MSFN that started me off on this trek some years ago ...

7yler wrote:

flyakite’s guide is good, but it very old now.

It is old, but the later methods either add to it (e.g. by slipstreaming more stuff) or try to automate much of it.

I try to do as much of it myself, so that when it goes wrong (and it does go wrong!) I have more of an idea about where to look. Or at least I can ask an almost sensible question :-)

7yler wrote:

Drivepacks need to be integrated into your full i386 source, and wont work on the PRAR folder. The PRAR folder needs to be created from you i386 (after Driverpack intergration).

To create the PRAR folder, check out this thread:

http://www.msfn.org/board/index.php?showtopic=58446

Good luck wink

The main tool is a .exe that looks like it goes and creates the full AIO-DVD tree - but it doesn't look like there's much customization possible. My AIO-DVD has grown organically, so - for example - I've left the SP0,SP1,SP2,SP3 directories lying around for Home & Pro rather than cleaning them up. (And I'm loathe to wipe them now since I found a machine last year which wouldn't install with SP3 but would install with SP1 and then accept an upgrade to SP3 ... ). There are also  a few scripts lying around in that thread. I may have to sit down and give it a go sometime.

So if that tool works with DriverPacks, then that's great but - unless I can pull it apart and find out how it updates PRAR etc. - then I'm going to have to plough a different furrow.

For now I've knocked up a dirty ruby script that reads the I386 txtsetup.sif and txtsetup.org and looks for added .SYS lines, making a list of updated drivers as it goes. It then tries to catch drivers that have been updated (but already existed) by checking .SY_ files in PRAR that are have a different MD5 hash to those in I386 and adds those to the list of updated drivers. Then it runs through and writes the required copy (and sometime sattrib) command to the output, but only if the I386 file is newer that the PRAR file. A batch file wrapped around that handles the six cases I care about (regular, unattended, unattended+apps, each for Home + Pro).

Perhaps I should add a feature request: DP must know which files it has updated and altered in txtsetup.sif - if it could log those in some convenient way (even a tagged line in the log - "TXT-SETUP-CHANGE: amdide.sys" - or similar) then I could post-process that easily with a script and copy across the required files.

Anyway, thanks for the input. I have a working solution now and I'll see how it goes.

-- deadbug

Go to forum: Installation Platforms

6 Reply by deadbug

(17 replies, posted in Installation Platforms)

OverFlow wrote:

you should also slipstream the third folder set... prar

dont do it manualy

Thanks for the reply.

But I'm not sure how to do this.

\PRAR contains ~100 .dl_ and .sy_ files, txtsetup.sif, setupldr.bin and \system32 directory.

When I fire up DPs_BASE.exe I go through the following screens:

Start
Settings
Select location of platform
    - Here I select type Disc and browse to \AIO-DVD\PRAR.
      At the top it says "OS: NA"

The next available screen is Update Checker. There's no "Select the DriverPacks to slipstream"

If I try to slipstream here it tells me "There are not yet any slipstream modules available for the selected platform!". If instead I move along I hit the "About" panel.

If I choose Multiboot Disc and \PRAR, then it wants the settings files. But for multiboot I should be specifying the root directory.

Go to forum: Installation Platforms

7 Reply by deadbug

(17 replies, posted in Installation Platforms)

OverFlow wrote:

I am going to say the files got corrupted... start with a clean source and try again...

I had a "Manifest Parse Error" just a few weeks ago. It happens to me _only_ in VirtualPC: VMWare and VirtualBox never hit the problem. Rebuilding the DVD from clean sources didn't help.

OverFlow wrote:

(if you cant say anything nice wink)

He did say something nice: his is the only post I've found with reasonably explicit instructions for multiboot-disk mode :-).

Now I seem to have finally got it to work (at least in a virtual machine) but I'm not convinced that I'm doing exactly the expected steps.

So here's what I've done and I would appreciate it if someone could point out where I'm going wrong.

I have what I think is a standard flyakite AIO-DVD with a bunch of OSes, the relevant ones here being Windows XP Pro and Home.

I have SP3 of each of those in a directory (e.g. \SETUP\XP\Pro\SP3) and I've copied that to e.g. \SETUP\XP\Pro\SPR
and then slipstreamed RyanVMs post-sp3 pack, slipstreamed WMP11 using boooggy's slipstreamer and finally slipstreamed IE7 using nLite.

At this stage things still work.

Now I want to add DriverPacks to both Pro and Home SPR.

So I run DPs_BASE.exe in disk mode, select \SETUP\XP\Pro\SPR, select all driver packs and export xp-pro.ini
Now I run DPs_BASE.exe in disk mode, select \SETUP\XP\Home\SPR, select all driver packs and export xp-home.ini
Finally I run DPs_BASE.exe in multiboot disk mode, add xp-pro.ini and xp-home.ini and specify the AIO root directory.
Then I let it slipstream.

Now I have to copy \SETUP\XP\Pro\SPR\I386\txtsetup.sif to \PRAR (for my unattended-with-apps install).
Finally I have to modify \PRAR\txtsetup.sif to put SetupSourcePath the way it needs to be to work.

I build an ISO, fire up the VM and early in the text-based setup it complains that there is no amdide.sys.

I find amdide.sy_ in \SETUP\XP\Pro\SPR\I386, copy it to \PRAR and try again. This time it's missing
atiide.sys.

I compare txtsetup.sif against the txtsetup.sif that was there before.

There's a small section of diffs:

amdide=amdide.sys
amdide1=amdide1.sys
atiide=atiide.sys
nvrd325=nvrd325.sys
nvraid=nvraid.sys
siside=siside.sys
viaide=viaide.sys

OK, I copy all of those over. Now it cannot find 3wareDrv.sys.
That's in a much larger section of diffs (about 118 lines!).

Well I'm not prepared to try 118 times, so I whip up a bat file to copy all of these files from
\SETUP\XP\Pro\SPR\I386 to \PRAR.

Now it boots. I can see the driver packs being processed so it looks like all is well (although I've yet to try on real hardware).

My problem, obviously, is that I've had to copy 125 or so files from I386 to \PRAR (and also my
boot-unattended and boot-normally directories too).

I cannot believe that this step is normally required and that no-one has mentioned it.

So did I miss some instructions somewhere?
Did I misuse the tool?
Is it intended to work with some other multiboot disk arrangement?
Does  DPs_BASE.exe in fact generate this info for me somewhere and I've just missed it?

-- deadbug

Go to forum: Installation Platforms