Login to Account Create an Account
Retail XPSP2 and a Clean Source Flag
Posted 15 June 2007 - 10:20 PM
I used 1.50 for this XP install, and got flagged on a lack of a clean source. I always do some OEM TEXTMODE driver work prior to running HFSLIP. When I got the warning, I blew right through it - thinking it might have detected the my OEM work.
But since I never got this warning before, I considered that it came from HFSLIP detecting the SP2 inclusive source. My log indicates, WARNING - Previously Patched Source Detected.
The "virgin" XPSP2 (Pro) source disk is a full retail version - the kind you would have bought at a store before Vista came out.
So I ran HFSLIP again with a new/clean SOURCE (I copied the entire disk). But this time, I didn't do any preliminary OEM TEXTMODE work. The warning popped up again, so HFSLIP was indeed flagging the SP2 in the retail source disk.
I understand the safety measure of the flag, but is this something to be concerned about? IOW, do you have to have a true "gold" disk not to get flagged? Is the flag meaningless?
Posted 15 June 2007 - 10:25 PM
Posted 15 June 2007 - 11:08 PM
This is probably overkill, but here is a WinMerge report.
I can go deeper.
The ASMS contains the following folders: 1, 10, 1000, 2, 5100, 52, 60, 6000, 70, and 7000
The COMPDATA folder contains mostly HTML and TXT doc.
The DRW folder contains a 1033 folder and a couple files.
The LANG, SVCPACK, SYSTEM32, WIN9XMIG, WIN9XUPG, and WINNTUPG folders all look like the usual stuff.
I named the 7z folder the label of the disk.
Posted 16 June 2007 - 12:33 AM
What is in there?
Posted 16 June 2007 - 06:01 AM
The reason I haven't come up with a solution for that yet is because, if that update is not installed (which happens after running HFSLIP) and you don't include the latest cumulative update for IE6, you get tons of errors reported in setuperr.log. So I don't want to simply ignore the existence of the SVCPACK folder as a whole. Instead, the warning message needs to be different.
Posted 16 June 2007 - 10:45 AM
(SOURCE\I386\SVCPACK is not removed if the source was patched with USP5)
Posted 16 June 2007 - 10:57 AM
Kel., nice pickup.
Posted 18 June 2007 - 11:22 AM
I guess you could have guessed that I would stay in paranoid mode. If I understand what you're doing in the beta build, you are coding HFSLIP to "simply" remove the entire SVCPACK (and KB911164) from the SOURCE to produce a KB911164-less SOURCESS installation.
I'm going to wait for your final build. But, could you simply remove the SVCPACK folder from the SOURCE folder prior to running HFSLIP (1.5.0 or whatever build), or would setup throw a fit (looking for SVCPACK and than stupid file)?
I know MS doesn't create software with the 3rd party slipstreaming community in mind, but this one is a real "head scratcher".
I'm slipstreaming the latest IE6 cumulative updates - an up-to-date, conservative, file set based on your 06/12/07 dynamic page. Thanks again.
I finally bumped into this on a Russian message board. About halfway down, a poster explained on 11/22/06:
Well, this is the SP2b.
Remember that the SP1a different from SP1? Only the lack of MS Java.
А SP2b [is] different from the SP2 only a KB911164. The reason seems Microsoft lost the lawsuit, the company Eolas over the use ActiveX in IE and has been forced to change the behaviour of the browser (add bothersome Khint "Click to activate and use this control" for any ActiveX components).
KB911164 contains files :
In fact, it is not needed, since the offset recent cumulative update for IE (KB922760).
Edited by PVU, 18 June 2007 - 12:51 PM.
Posted 18 June 2007 - 06:28 PM
Letting HFSLIP remove the SVCPACK folder or doing it manually is the same thing. You only need to make sure you update IE (latest cumulative IE6 or slipstream IE7). When including IE7 but not slipstreaming it (ie, first GUI logon or SVCPACK methods), it's better to also include the cumulative IE6 update to avoid the errors in setuperr.log.
Posted 18 June 2007 - 08:44 PM
Just wondering...how new is that? I've never seen that label before on an XP SP2 disc.
Edited by Super-Magician, 18 June 2007 - 08:44 PM.
Posted 18 June 2007 - 10:00 PM
Supe, I bought it just recently on eBay. It was an open box at the right price. The seller indicated that she had recently purchased it at a local store for an app she thought she needed it for, but then realized that her old OS could handle the app. She said it was never used, much less activated. I want get it up quickly to be sure.
I've never used XP as my OS before, so I have nothing to compare it to. But based on all the posts here ("b disk"), it looks like it's pretty new, and the seller's story seems to jive so far. If I was at work, I'd look at the source date stamps.
Super, all files within all folders are date stamped 02/28/06.
Edited by PVU, 19 June 2007 - 09:51 AM.
Posted 20 June 2007 - 12:30 PM
- SVCPACK (folder)
The removal of the SVCPACK folder is understood, and the INF calls on the KB911164.exe. I'm just not sure about removing the SVCPACK.DL_ (or how it might mess with HFSLIP or the install).
Posted 20 June 2007 - 02:20 PM
1) Whatever is in your SOURCE folder is copied over to SOURCESS; this includes SVCPACK.INF/SVCPACK.IN_
2) When the SVCPACK items are processed, any SVCPACK.IN* files in the SOURCESS folder are deleted and a new one is created
This has been the case for a long time.
So basically, you can leave SVCPACK.INF or SVCPACK.IN_ alone.
The SVCPACK folder should be deleted manually if using the latest final. This isn't the case anymore with the current test release.
HFSLIP doesn't mess with SVCPACK.DL_. I wouldn't touch that file.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users