[billtodd]

Just a couple more oddities observed while running the current release (1.7.8):

The second entry in svcpack.log is

x86GetSourceArchitecture: Invalid handle for file: E:\OSKITWin2KReinstallKit\HFSLIP\SP\i386\mp\dosnet.inf

Does that sound OK?

At one point during the procedure (I didn't find this in either log file) a message to the effect that a valid iso9660 .iso image could not be produced apparently because some support file controlling use of Joliet (I think) extensions was not found appears on the screen. The .iso can still produce a bootable and usable installation disk (WinMerge validates that its data content matches the SOURCESS source) but ISOburner produced a disk on which ISObuster couldn't checksum a couple of the last sectors (could just have been a defective disk) and while InfraRecorder produced a disk that ISObuster could checksum the checksum didn't match that of the input .iso file, which leaves me wondering whether some additional .iso-creation file is missing (beyond bbie.exe, cygwin1.dll, and mkisofs.exe, which are there).

FWIW,

- bill

[tommyp]

Sorry, but I'm not too sure of svcpack.log. Is that file on the installed OS or in some folder on the install disk? I'll assume for now that you installed windows and the E drive is your CD. Looking at E:\OSKITWin2KReinstallKit\HFSLIP\SP\i386\mp\dosnet.inf doesn't quite make sense. Typically there isn't an "MP" folder, or at least I've never seen an MP folder. Dosnet.inf should be in the i386 folder.

The files I have in my hftools follow. If I rename zcdimage.exe to cdimage.exe, then cdimage is used to create the image. Both methods make the same file, so I always have an option to use either. cdimage take precedence for making ISOs, but if it's not there, it uses mkisofs.
bbie.exe
bbie.lic
boot.bin
boot.img
cmdow.exe
EXTRACT.EXE
HFANSWER.INI
mkisofs.exe
mkisofs.txt
modifype.exe
MSICabExtract.exe
MSICabExtract.txt
Reg.exe
ZCDIMAGE.EXE

FWIW, my hfanswer.ini has this:
FORCECDIMAGE=
CDIMGSW=-h -j1 -m
MKISSW=-relaxed-filenames -d -D -N -J -no-emul-boot -no-iso-translate -boot-load-size 4

[billtodd]

tommyp, on Oct 18 2009, 06:56 AM, said:

Sorry, but I'm not too sure of svcpack.log. Is that file on the installed OS or in some folder on the install disk?

svcpack.log is generated by HFSLIP in its main directory (\HFSLIP in my case) when HFSLIP is run. Its first line is

Service Pack started with following command line: -u -n -o -q -s:"E:\OSKITWin2KReinstallKit\HFSLIP\SOURCE\"

Quote

I'll assume for now that you installed windows and the E drive is your CD.

In this case the E: drive is the one containing the HFSLIP directory structure set up by hfslip-1.7.8.cmd which it then uses to generate a slipstreamed installation.

Quote

Looking at E:\OSKITWin2KReinstallKit\HFSLIP\SP\i386\mp\dosnet.inf doesn't quite make sense. Typically there isn't an "MP" folder, or at least I've never seen an MP folder. Dosnet.inf should be in the i386 folder.

Beats me: it's HFSLIP that's apparently looking for it during its processing. Didn't find the string '\mp\dosnet' with a quick search of the .cmd file, but the apparent error notation in svcpack.log seems to suggest that it wanted this and didn't find it.

Quote

The files I have in my hftools follow. If I rename zcdimage.exe to cdimage.exe, then cdimage is used to create the image. Both methods make the same file, so I always have an option to use either. cdimage take precedence for making ISOs, but if it's not there, it uses mkisofs.
bbie.exe
bbie.lic
boot.bin
boot.img
cmdow.exe
EXTRACT.EXE
HFANSWER.INI
mkisofs.exe
mkisofs.txt
modifype.exe
MSICabExtract.exe
MSICabExtract.txt
Reg.exe
ZCDIMAGE.EXE

All I have in \HFTOOLS are the three files that I placed there (bbie.exe, cygwin1.dll, and mkisofs.exe) plus the BOOT.BIN file that the installation places there - which I think is everything that the instructions at http://www.hfslip.org/ told me to place there.

Quote

FWIW, my hfanswer.ini has this:
FORCECDIMAGE=
CDIMGSW=-h -j1 -m
MKISSW=-relaxed-filenames -d -D -N -J -no-emul-boot -no-iso-translate -boot-load-size 4

Your instructions at http://www.hfslip.org/ under the 'Extras' heading say that all those are the default values (in which case I shouldn't need to have that answer file to cause them to be used, should I?).

Incidentally (there always seems to be one more question to ask) I just noticed that generating the installation seems to have added three .cabs to \HFCABS (_IE6_HFSLIP.CAB, _IE6b_HFSLIP.CAB, and _OE6_HFSLIP.CAB) - but not updated them (at least according to their modification dates) since the first slipstreamed installation that I generated. I understood that the \SOURCE directory had to be cleared and repopulated for each run - is this also true of \HFCABS (and any others)?

- bill

[tommyp]

Those _*.cabs are created to speed things up if slipstreaming ie6 on a 2k source. The files inside them won't update because the ie6 cabs weren't updated. There's no need to clear them, unless you want to (hfslip will just recreate them). There's no need to delete anything in hfcabs, hf, hfsvcpack* or any other folders. However, you should delete obsolete files obviously. You do not need to clear the source folder either. The script will clear and recreate the sourcess folder on each run. One little pet peeve I have with 2k vs xp is that when copying files from a cd to a hard drive, on a 2k box the files have a read only file attribute. This does not happen with xp. It would be beneficial to clear the read only attribute to the 2k source files.

It sounds like you using a pre-sp4 source. If you are, just include the SP4 and hfslip will slipstream the source directly with sp4. This is OK. There's no need to delete source after slipstreaming sp4. This will save time too. As far as the svcpack.log and mp\dosnet.inf files go, it could be an artifact of microsoft's sp4 slipstreaming routine. I can't say exactly though. I haven't slipstreamed a pre-sp4 source in many years.

[billtodd]

Our Win2K systems date back to 2001, when SP1 was what the distribution disks came with. A quick check with WinMerge suggests that what's happening to the \SOURCE directory is that SP4 is being slipstreamed into it, before all the other updates get slipstreamed into \SOURCESS. As long as that won't confuse HFSLIP when it gets run again with W2KSP4_EN.EXE still in \HF even though \SOURCE already has the SP4 updates it's understandable why \SOURCE doesn't have to be refreshed each time - one less step in the process (two less if HFSLIP also cleans out \SOURCESS before reusing it).

Whatever errors may or may not be occurring don't seem to have compromised the result, which installs and runs just fine. Thanks again for helping me understand things a bit better.

- bill

[billtodd]

Ah - yet more fun and games. I just finished installing the slipstreamed system withholding all the WMP-related updates (except WMP9's MPSetup.exe itself). When installing the WMP-related updates individually afterward, 969878 failed saying it required that WMP9 be installed and 975025 failed saying it required that WMP (no specific version) be installed. The other 10 or so WMP-related patches installed fine (including the original codecs that I downloaded from Microsoft rather than use the DRM-'enhanced' version in 891122).

Perhaps I shouldn't have included MPSetup.exe in the slipstream after all. I remember a claim that if you wanted the WMP9 encoder to work well you should first install the WMP7.1 encoder before upgrading to WMP9, so deferring the upgrade might have that advantage as well.

Just to see what would happen I executed MPSetup.exe manually (the result seemed to retain all the setting changes that I had made earlier) and then attempted to re-apply the two failed updates, but the result was the same: whatever was lacking didn't get cleared up by the reinstall. Unfortunately, there's no obvious way to uninstall the codec package to see whether that may have affected anything (**** - I *know* I should have taken an early image of the system just in case).

WMP certainly is a marvel...

- bill

(Oh, my - about the most innocuous '4-letter word' in my vocabulary seems to have been censored. I wouldn't want anyone to think it was something worse.)

This post has been edited by billtodd: 18 October 2009 - 12:13 PM

[billtodd]

Well, 'tain't HFSLIP's fault that 969878 and 975025 wouldn't install. After taking MPSetup.exe out of the slipstream and still having the problem, I went back to my SP1 disk and reinstalled everything by hand - and those two patches still wouldn't install (Google couldn't find any information about this, but both have only been out for less than a week and not that many people are still using Win2K - assuming it's peculiar to Win2K). I even tried installing the 891122 DRM patch just to see if that would make them work - but no...

If HFSLIP can save me 70-odd manual installs I won't complain about having to install a dozen or so WMP patches by hand (plus one DX9 patch). Slipstreaming the DX9c installation also eliminates 4 event log Windows File Protection failures (involving ks*.ax) that have always bothered me even though they never seemed to cause any problems.

- bill

[tommyp]

That's odd. Without WMP9, I was able to slipstream the 969878 and 975025 and directx9 and the rest of the hotfixes using beta R. In fact, the only missing update I got was the Malicious Software Removal Tool because I didn't include it. Weird. Maybe I'm doing something wrong?

edit. With WMP9, WU reports that I missed the sofware removal tool and 973540, which ironically I forgot to include. Others installed fine. I must be doing something wrong then. Oh well.

Let's keep this thread back on topic - windows updates. If you are running into a particular problem, please either report it in the beta thread or in a new thread. This is not a blog. Thanks in advance for understanding.

This post has been edited by tommyp: 19 October 2009 - 05:59 PM

[willydejoe1234]

Please update the list of xp updates in October 2009.
thank you very much.-

[fdv]

anyone seen muppethunter?

in the meantime, go to the 2003 list, load the KB articles, and select the XP patches from there...

[Muppet Hunter]

Sorry for the delay, see the attachment for the October changes until fdv puts up the new page.

Attached File(s)

•  Oct_hotfixes.txt (3.53K)
  Number of downloads: 64

[willydejoe1234]

KB958869 for GDI+ replaces kb938464v.2
KB975467
KB971486 replaces kb956572
kb969059
KB974571
kb973525 ActiveX Killbits - replaces KB973346
kb974455 replaces 972260 (i.e versions 7 and 8 independent)
kb974112 replaces kb954600
kb975025
kb954155
kb890830 v3.0


I think they are these

please update the post from October 2009 to xp

This post has been edited by willydejoe1234: 27 October 2009 - 07:28 PM

[fdv]

MH, did you email this to me? I dont have the file...

[bfc_xxx]

On october 28 I got 2 new updates on windows update:

IE8-WindowsXP-KB975364-x86
WindowsXP-KB971513-x86

but I cannot find them on Microsoft Security Bulletin Summary. Can anyone help if I have to delete older updates?

[wela]

KB971513 this is an optional Update, nothing to delete.

[gluon]

KB976749 for IE8 is up to fix previous cumulative update. From the description it seems like the previous cumulative update kb974455 need to be installed first otherwise there could be issues.

I'm trying it now, putting it in HF folder.... hopefully everything is OK.

[bfc_xxx]

I tried with latest beta and WU seems satisfied. No problems.

edit: how can I see if an update has been really installed and there is no conflict with other update?

This post has been edited by bfc_xxx: 05 November 2009 - 05:52 AM

[fdv]

I guess I need a new contributor for the XP list...

No hard feelings if you're reading this, Mup, but we've gotta keep moving forward... any takers?

Tom and I will help any new taker until they get on their feet.

The faster someone steps forward, the easier this will be.

[Mim0]

New (2009-11-10):
Windows® Malicious Software Removal Tool (KB890830)
MS09-065 (969947) replaces MS09-025 (968537)
MS09-066 (973309) replaces MS09-018 (971055)

fdv, on Nov 10 2009, 04:28 AM, said:

I guess I need a new contributor for the XP list...

I can offer my XP-List.

Mimo

This post has been edited by Mim0: 10 November 2009 - 03:28 PM

[tommyp]

Wow! That was fast. FDV, looks like we got a taker, and we have German precision to make it perfect too. Thanks for stepping up to the plate Mimo!

FDV, can you link to this list? Or host it for Mimo? Either way is fine with me. I'll update the hfslip site so that it points to the right place for XP lists once it's all settled.

Sorry muppet , but a one time update of a list doesn't cut it.