Jump to content

Hotfix Slipstreaming


GreenMachine

Recommended Posts

Good Job GreenMachine.

I have any question ( to You, MSTest, gosh ? ):

is posibile any "upgrade" this comparison to MSTT (MSTest) method in two variants:

1) full slipstreaming hoffixes with this method

2) slepstreaming only: rollup (KB826939) - guide is simple ( thx gosh ! ) and MM2, WMP9 -guides was simple too ( thx MSTest ! ) and if is possibbile DX9b (a no seek simple) guide and rest of hotfix slipstreaming with RHSM method (because is fantastic script - thx to RoyalBox and You )

Przemek

Sorry to my English

Link to comment
Share on other sites


Yeah, the hotfix installation and deployment guide does a wonderful job detailing what to do and Q814847 - well that's one of the reasons I stayed away from hotfix slipstreaming for so long. It's so much hand tweaking, which is of course prone to errors. In an ideal world, hotfixes would be written to support -s just like service packs so we could just slipstream them right in and let Microsoft take care of the hairy stuff. I hear there is something like this in the works for the Longhorn timeframe. Adding, modifying, and replacing components (like WMP/DX/etc) is supposed to be a piece of cake. We'll see I guess.

For now, I've slipstreamed RU1 into my XP SP1 CD for work and home using the MSFN guide. As I install XP in so many different situations, however, I've elected for now to keep the other hotfix installations in a separate batch file. I'm not so concerned about having a complete install with one click as I am automating the tedious tasks.

Link to comment
Share on other sites

Thanks, Przemek.

The reason I doubt that I will update the chart to include a method such as MSTest's, is that it is simply too complicated for me. I am dead against editing any files by hand, and following the excellent and simple guides of Aaron exhausted my ability to follow directions. If you, or someone else, provides me with the type of files I included with the comparison chart, I could probably produce a CD to complete the chart in terms of speed and CD size.

In terms of a guide for the RHSM, I will work on that ... However, bear in mind that it is basically a "turn-key" script, so the only user intervention required is dropping the right files in the proper directories. I have a page on the site, Current Hotfixes, where the patches and corresponding directories are listed. The only user specific file required, and then only to allow for unattended installation, is WINNT.SIF. All other files are available for download, and most linked off the Current Hotfixes page.

Link to comment
Share on other sites

ok i also did a install compare.

from reboot of a formated drive to complete final reboot fully installed on a 1.1 ghz amd with a 52x cd-rom took 37.30 using techtype's install

GreenMachine took 53.10 from formated boot to complete install.

I do think this could have been just me...but thats a big time difference...

BTW no bashing meant GreenMachine...I did notice you timed yours from after the dos copy point. this would have droped the time down alot..per it took almost 15 min to copy the files...have no reason why it took so long...possible a bad burn ?

PLEASE don't be offended

I would just like to find out if this was me ...or more like it my system its not the best test system :)

Thanks again GreanMachine and techtype...it's enjoyable testing your guy's work and i do learn.

Link to comment
Share on other sites

I vote for a burn problem. I created 5 CDs for these tests, and they all seemed to require comparable times for DOS copy. My original timings were from the point where I selected the partition, to the time when the system was ready to log on after last reboot. My values were this (again, two tests for MSFN and RHSM, one for the rest):

RHSM - 35 Minutes

MSFN - 37 Minutes

TTP1 - 46 Minutes

TTP2 - 43 Minutes

RUNO - 46 Minutes

While the TTP1/TTP2/RUNO has slight variation with the posted results, I find MSFN and RHSM values to be consistant with these findings. I did set the timer start at a point AFTER DOS copy, but at the same point for all tests. This was chosen, as my first timings relied on me looking at the PC, pressing buttons, and noting times. The final timing system relies totaly on PC compiled data.

I have noticed that some CDs copy faster than others, all created with the XPCREATE scripts. Specifically, it seems that on some CDs there are some points that the CD stops spinning. This includes the 71% point of file copying. The only reason I have come up with to explain this, is perhaps the validation of slipstreamed files requires longer, as the correct .CAT file must be found. Unfortunatly, that does not explain why some CDs are so much faster than others.

I'm a little tired of installing XP for the moment. If I can devise an accuraqte timing system, that does not rely on my noting times, and does include more of the whole installation process, I may rerun the tests. Perhaps I will simply time the first part of the installation. I will also mention that the RHSM CD I used did NOT seem to display this "hiccup" when copying files.

Why would I think YOU are bashing me: you are one of the handful of people that has taken the time to test this, and provide me your feedback. For that you have my thanks!

Link to comment
Share on other sites

I'm noticing that my slick new GreenMachine CD takes a lot longer to copy the files too. I've gained back some time by opening the ISO in UltraISO 6.51 (use only this version) then extracting all the files (except the bin files). Then I deleted all the files from the ISO (except the bin files). Then I re-added the same files from the location that I extracted to. Under File - Properties (in UltaISO) I marked "Optimize", then I resaved the ISO (Lots of activity as it claims to be optimizing). Whew! This gained back some of the lost time, but not all. Further testing and experimenting by me needed! I suspect the same thing as Green posted, there is some delay caused by something it's searching for --- Hmmmmm. But, some of the delay was apparently caused by the CDimage process.

Link to comment
Share on other sites

Thought I wouldn't see your edit, eh?! Yes, what techtype says makes me question the CDImage process. There are a lot of switches, and I am convinced there is something to be done there. This is obviously supported by the fact that WinISO extraction - addition has an effect.

In addition, assuming that Tbone2 did not use XPCREATE to create the other CDs he benchmarked, that would also explain why my results were consistent with both timing methods: I used the same script to create each CD, the difference was in the actual files modified. Please tell, Tbone2.

I appreciate the help of both of you in debuging this problem. I do not have much time over the next few days, but I will be testing a few things, and I will post if I discover anything interesting. In the mean time, there are two tests that could be run, should time, conditions and inclinations permit.

1) Create a CD using other ISO or burning software. The CDROOT directory contains all the files that are to be burned to the CD, and the BOOTIMG.BIN file can be found in the TEMP\NEWFILES directory.

2) Replace the contents of the CDROOT directory with the contents of the TTP1 / TTP2 CD, and use the "Create ISO" option to create this CD with CDImage.

Again, thanks for your help, and post if you find something.

Link to comment
Share on other sites

Yeah, I'm thinking that we need to start with a CD that has never seen or heard of CDimage. Then, we'll know. I'm shot too right now, but I'll post when I try it. (Edit - who ever edits?? :) ) More testing and experimenting needed by me, I mean!

Edit:

Well, I just tested mine again -wow- I forgot how fast the file copy was supposed to be. Then I started with my ISO - deleted my files and put in GreenMachine files.

Slow, slow copy. Very strange - Watson!

Link to comment
Share on other sites

Well a job needs done :)

this is what i did

1 took GM's CDROOT directory changed it to XPCD and ran ISO Creator for WinXP Pro.cmd sorry don't rem where i got it...from one of the great here ...using xpboot.img because this is the way i created ttp1 cd that only took 37.5 mins to install :rolleyes:

so we what to be the same way i guess...

created the iso burnt it with nero.

will install and see what we have...BTW i created the cd from dos not in a window...

will let ya know

EDIT:

still slow copying files in dos part just some of the file are:

modem.sys long time

swenum.sys

pjlmon.dll

wdmavd.drv

.chm files

.icm files

oembios.bin

driver.cab alway take a little longer to copy

gm.dll

and many more...that normally just flashes by

maybe this will help find the problem

Link to comment
Share on other sites

Thanks, Tbone2. Unfortunatly, I am not that optimistic. The script you use, from the MSFN guide, uses the same program and switches to create the ISO as I do. I have played with some switches, and I have found fast combinations, but with unwanted side effects (UPPERCASE ...). Let us know ...

Link to comment
Share on other sites

Tbone2: After much hair pulling, and relentless help from techtype, I think we have pinpointed the problem. In the pursuit of removing every outdated file on the CD, I update any CAB fils which contain files that have been updated. This was previously done be default, and is now optional in the later versions. In repacking the cabs, I have somehow rendered them more "complex", and it is when text based setup is copying files that are inside the cab files - you can see it stutter with modem.sys, usr*.* and more - that all the time is lost.

I do not yet have the final solution, but it will be in how I repackage the cab files. Right now I am looking into:

- using CABARC instead of MAKECAB

- updating the cabs, as opposed to rebuilding them

- trying different switches/compression ratios

- reading the documentation (if someone has some - PM me please)

I also wonder if there is some sort of index inside the cab that I could update.

If someone out there has any ideas, and experienced similar problems when making cabs, give a holler. miso1391 ???

For now, the workaround is to simply select the N option (Full, No Cabs) from the menu.

Tbone2, sorry to have made go through a 15 minute file copy. I understand why you question my timing methods! The CDs I compared where compiled using the N option. Note that not updating the cab should be safe, and is in fact the way that MS outlines in KB articles. The DOSNET.INF file HAS been updated, so older versions still in the DRIVERS.CAB and SP1.CAB should not be used.

I'll post again when I get this sorted out.

Link to comment
Share on other sites

Sorry for having me go though 15 minutes file copy ?...WTF Thats is what we are here to help each other....BTW I wasn't really question your timing methods I was questioning my system...hahahhahah

Beside thats what I like doing is trying all these new ways...Ya know when your old , like me :)

Hey when your ready with new version i have no problem testing.

Once again thanks for putting up with me...and doing a great job that the rest of us wish we knew how to.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...