Tomalak
Content Type
Profiles
Forums
Events
Posts posted by Tomalak
-
-
But if you're using switches at T-13, what's exactly the command with switches you're running? Is that exact command generating that broken error box only on T-13?
I use the packages as generated by SNM, no further modifications. If put into the HFSVCPACK_SW1 folder of hslip, they are exectued at T-13 via svcpack.inf with the following parameters: "/quiet /norestart". This has always been the case, no change on hfslip side here. When installing them after Windows setup, I just execute the files without parameters, and this works without a problem.
No time left now, so I can continue testing only next weekend. Maybe someone else can try meanwhile what happens if the packages are run with the above parameters, but on an already installed Windows (instead of T-13 during setup)? Thanks!
Regards,
Tomalak
0 -
I'm having a problem installing Silent .NET Maker synthesized for Win2k and WinXP using HFSLIP. I've put the EXE file in the HFSVCPACK folder in both instances.
For Win2k, neither version is installed. Should the EXE be put in HFGUIRUNONCE or am I doing something else wrong?
For WinXP, only Net v1.1SP1 is installed, not the others. Should the EXE be put in HFGUIRUNONCE here also.
Same problem for me (only used 2.0, 3.0 and 3.5, nothing installed at the end, i.e. after Windows setup was completed), used version 20100102 for creation of the installers. But I got an error message during T-13 phase, saying something similar to "Use %FILENAME -h for help" with just an okay button (that's right, only one '%' sign). This has worked before, but I cannot tell you which was the last version I tested it successfully.
If required I can re-do this later in a virtual machine to provide a screenshot. By the way, running the same installers after Windows installation was fine, no messages (except the missing KB951847 problem in MU for that specific SNM version, but this was fixed meanwhile). So this is something specific to the T-13 phase I guess.
Tomalak
0 -
Tomalak
I couldn't recreate your error. Can you attach your processdata.txt file?
Of course, here it is. I also played with the settings (e.g. including WIC and MSXML6 for .Net 3.0, as it is default), but that didn't change anything. Note that I'm building a German version of the packages - using corresponding files for the hotfixes - on a Windows XP Professional. Any more information or help I can give?
Hope that helps to recreate the error
0 -
According to Microsoft the error 2727 means "The directory entry '[2]' does not exist in the Directory table."
Seems that something is broken in one of the transform files...
Problem persists with most recent version (20091229). The MS API error in the cmd window is gone now, but the message window with the 2727 error is still there...
0 -
Yes. The content of table 2 (Security updates) should be mandatory but the optional things [...]
Hello Mim0,
I'm sorry but I do not fully agree, these contents are not all mandatory. So here are some remarks from my side regarding table 2 (security updates):
- First of all, I think it makes not much sense to list updates for components that are by default not installed. In this case they should have a note explaining that they're usually not useful or necessary. This applies at least to the following entries:
- MS09-023 (Windows Search 4.0): Windows Search 4.0 is not part of a standard Win XP SP3. You do not even have it in the list of optional updates...
- MS09-051, KB969878 (DirectShow WMA Voice Codec): Applies only to systems with Media Player 9, as also the name of the update indicates. If the user slipstreams or installs WMP11, this update is neither necessary nor reported by WU/MU.
- MS09-053 (FTP for IIS): IIS is not installed by default. Including this update does not hurt, but it is also not absolutely required.
- MS09-066 (Active Directory): The same. ADAM is only present in the system if manually downloaded and installed by a user (which is by the way possible only for XP Professional, not XP Home), so listing this update is questionable.
- M08-069 (XML Core Services): While MSXML3 and MSXML6 are part of Win XP SP3, MSXML4 (SP3) is not! It is only present in the system if intentionally installed by the user. As not having the library in the system at all is even more secure than having a patched version (with probably yet unknown security issues), it should not blindly be listed here - MSXML4 is not essential, so the recommendation is to skip it completely...
- MS09-023 (Windows Search 4.0): Windows Search 4.0 is not part of a standard Win XP SP3. You do not even have it in the list of optional updates...
[*]KB955759 (Indeo Codec advisory) is strongly recommended but not mandatory. Therefore it is more of optional character than a definitive must, although mentioning it in table 2 is still appropriate I guess.
And then I have some comments regarding table 3 (optional updates):
- KB952287 (MDAC update): Same issue as before. This update is relevant only for systems with installed MS SQL server (which the standard user does _not_ have). Doesn't cause harm if included, but still superfluous (we're talking about lean installations, aren't we? ).
Update 2009/01/03: Strange enough, but this is indeed reported by MU/WU when not installed. So everything okay with listing it. - KB967715 (Autorun update): The registry file linked here and provided by Mupper Hunter is over-perfect. The "HonorAutorunSetting" is already set by the update itself and correctly considered by hfslip, so it could be suppressed. Additionally the "NoDriveTypeAutoRun" entry for HKEY_CURRENT_USER is redundant, as the HKEY_LOCAL_MACHINE entry overwrites user-specific settings.
By the way, autorun for all drive types _except_ CD/DVD drives is also disabled by KB971029, listed in the table too. So if you want autorun only disabled for USB and other drives, but not for CD/DVD, just omit above registry file and you get a system with the MS suggested autorun settings automatically. - KB970430 and KB971737 (Extended Protection for Authentication): Please mention that for these updates the same registry entries as for KB968389 (in table 2) are necessary! If they're not present, these updates are meaningless and have no effect.
That's it for now, I'll come back if I find more issues
Kind regards,
Tomalak
0 - First of all, I think it makes not much sense to list updates for components that are by default not installed. In this case they should have a note explaining that they're usually not useful or necessary. This applies at least to the following entries:
-
Yeah, I know about it, but Mimo's list isn't bad at all and sometimes it can be useful
I didn't say it's bad - just that it's not the ultimate truth
and common sense still applies. And yes, it is very helpful and actively maintained - we can be glad that Mim0 takes care of it!But if you know a better list then write about it, it would be very helpfulNo better list (although I have my own internal list of updates I include), so nothing to write about. I think we're better off with not more lists, but one reliable reference list instead.
And so of course I contribute by informing Mim0 about issues I have with his list, and he can then improve if he agrees with my suggestions. This helps us all B)
Regards,
Tomalak
0 -
Your screen contains same "MSI API error: Commit" as for me....
Ah, yeah, now I see, you already reported this.
According to Microsoft the error 2727 means "The directory entry '[2]' does not exist in the Directory table."
Seems that something is broken in one of the transform files...
0 -
Hello,
I have a problem with the most recent SNM script (20091224). During processing of the KB963707 update (for .NET 3.5 SP1) an error occurs with code 2727, and the package is not built correctly (way too small compared to previous runs). See attached screenshot.
Settings deviating from default .ini file:
DNF35FFXBAPPLUGIN=NO
DNF35FFCLICKONCEEXT=NO
Thanks for investigating!
Tomalak
0 -
EDIT: I didn't notice it before, but XMLLite slipstreaming doesn't work for XP with SP3 in HFSLIP (it shows 0 files copied)
Of course, because it's not necessary. XMLlite is already included in Service Pack 3. See here, and KB915865 is also directly listed here.
Take Mim0's list with a grain of salt as there seem to be some minor issues with it, and do not blindly include everything just because it's listed there...
Kind regards,
Tomalak
0 -
Hello Mim0,
Regarding your update list:
- KB958911 (optional GDI+ update) needs to be removed from table 3 (and your update checker), as it is outdated and has been superseded by KB958869 (MS09-062).
- KB976098 (cumulative timezone update) is listed as to be put into HFSVCPACK_SW1. Any special reason for this? I have found that it works flawlessly in HF.
Kind regards,
Tomalak
0 - KB958911 (optional GDI+ update) needs to be removed from table 3 (and your update checker), as it is outdated and has been superseded by KB958869 (MS09-062).
-
Adobe Flash got a security update also.
I've uploaded an updated SWFLASH.CAB (version 10.0.42.34) here
SHA1 checksum c0d67df4e53927ecf834ca007816d43a0c62add5
MD5 checksum 07bd474624bfa8e0937dea4eefdf18a8
@Kiki Burgh, no, that is not the latest. The latest is v1.9.40.0. I can't recall the MS URL right now. http://go.microsoft.com/fwlink/?linkid=39204 should be it but is still linking to 1.9.9.1Are you sure there is an updated cab provided by MS? Not a manually reworked one? As far as I know the most recent version of 'legitcheckcontrol.dll' is to be found in KB905474 (Windows Genuine Advantage Notifications, last updated 2009/03/24).
Sorry, but I can only provide the direct link to the German version. Maybe someone can determine the English one (from Windows update log)?
Extracting this file and then using "wganotifypackageinner.exe" (properly renamed to something like "WindowsXP-KB905474-x86-<LNG>.exe") in the HF directory worked for me. hfslip took care of the rest, no MU/WU complaints afterwards...
HTH,
Tomalak
0 -
Tomalak, you need three utilities to achieve that:
Wait, here's the original tutorial in english:
http://www.eeeguides.com/2007/11/installin...-usb-thumb.html
bye!
I tried this tutorial but when I install xp and the files are copied I get error: advpack.mui cannot be copied.
Same for me (by the way, you can skip the error and continue), this seems to be a general problem with this kind of setup. I tried the above mentioned SetupWinFromUSB tool as well as WinToFlash, identical result. So yesterday I decided to use the direct approach - put WinPE to an USB flash disc with SOURCESS folder on it (no problem when installed from CD to a VM, so the source is okay), booted from it, launched Windows installation via "winnt32.exe".
Installation was overall successful, but: seven or eight *.mui files reported as missing during text mode copy (I have the names if anyone is interested). Some more *.mui and one .dll reported as missing during GUI phase. $OEM$ folder was apparently not copied, so my drivers included there were not used. "winnt.sif" (resp. "unattend.txt" for non-CD based install) was not considered at all, braking some customizing settings I put there. Everything foreseen for T-13 (HFSVCPACK_SW1 and HFSVCPACK_SW2) was installed as intended, but everything that is usually performed after first boot during logon (e.g. some registry tweaks I have in HFSVCPACK, or putting the hfslip entry in the software list) was not executed.
In the end I had a working system, but not one I was satisfied with. All not critical issues, but nuisances. The different setup method that is used for USB based installs (copying everything to the "$win_nt$.~bt" and "$win_nt$.~ls" folders first, and obviously making some other changes, all by "winnt32.exe") has apparently its problems...
Conclusion: I probably have to swallow the bitter pill, buy an external CD drive and install XP to the netbook from there. The ISO image seems to be the only reliable way that works without all this hassle
Sorry for the offtopic talk (will give up at this point anyway, need a working system now and no more time for tests in the next feew weeks),
Tomalak
0 -
Now I can finally retry everything from an ISO image and in a VM and see whether the problems described before are caused by hfslip or only a result of the "transfer to USB" program. But not today, too late. Will report back tomorrow...
Okay, short followup. With the test install from CD in a VM everything worked as expected - no file copy errors (except my famous "tweakui.exe" problem
) and no other problems. So everything I experienced with the other install like several files not being copied, one update reported as missing, reg files in HFSVCPACK not being applied etc., seems to be the result of the above mentioned WinSetupFromUSB tool which apparently broke several things by fiddling with my source.So my quest continues to find a way how I can install Windows from an USB stick, but based directly on thee ISO image or at least the SOURCESS folder with as few modifications a possible. Don't want to buy an external CD drive just for that one-time install to the netbook. But that's a story not belonging here, not hfslip related...
Regards,
Tomalak
0 -
Sure doesn't sounds like an hfslip related issue at first glance.
Well, it was not. Of course. I meanwhile found out the reason... Stupid me
Question for you - did you/can you test your dvd extracted source by itself to see if it installs?Yes, that was exactly what I was doing next - testing with unmodified source. Failed as well, so no hfslip issue.
And then I had the crucial idea: I was able to get the full i386 directory from the DVD (resp. Ghost image on it), but not the few files on top level (e.g. setup.exe), they are not stored in the image. So I took these files from the XP Pro source. What I didn't know is that the identifier files for Windows and the applied service packs have different names for XP Home and Pro. So renaming "WIN51IP", "WIN51IP.SP2" and "WIN51IP.SP3" to "WIN51IC", "WIN51IC.SP2" and "WIN51IC.SP3" was the solution!
Looks as if installation would work now with unmodified source (due to time I didn't try further than to the start of the file copy in text mode phase, but I assume everything will go smooth from there on). Strange thing is that I wasn't immediately able to recognize that because installation from the USB stick worked, only occurs for the CD based setup.
Maybe this post is of help to someone else some day when he/she encounters that strange behaviour. Sorry for the unneccessary disconcertment.
Now I can finally retry everything from an ISO image and in a VM and see whether the problems described before are caused by hfslip or only a result of the "transfer to USB" program. But not today, too late. Will report back tomorrow...
Good night,
Tomalak
0 -
Tomalak - did you have the same issues with a VM? Or just the real install? Are those files missing inside the sourcess\i386 folder? If the files are in the sourcess, chances are it's a bad burn. I typically test the CDs out on a VM prior to a real install to verify the burn is ok.
Well, to be honest what I said above is not exactly true: one change I did was the replacement of the SOURCE folder content. I was doing my tests so far (for MSI installer and debugging some other things) with an XP Pro source and in a VM, but now as I wanted to install XP on a netbook, I used the respective XP Home source which I extracted from the recovery DVD.
I didn't create an ISO image (so a bad burn cannot be the reason), but put the resulting SOURCESS directory to an USB stick and did the installation from there, with the help of WinSetupFromUSB. This might have been the source of my problems (the tool does some modifications to the source, i.e. it adapts the "WINNT.SIF" file).
So I wanted to try with the exact same configuration as before, but this time in a VM and from CD, to see if the copy problems occur there also. But now I'm not even able to get that far! See screenshot below, this appears directly after booting from the CD. It requests me to put a floppy disk named "Windows XP Home Edition Service Pack" into drive A:. I cannot go on from there, and only abort the setup at this point. What the hell?
Has anyone experienced that before, any ideas? Incomplete source (don't think so, as the Windows installation from the USB stick went fine), wrong WINNT.SIF (but tried even without such file, therefore cannot be a wrong parameter I think), wrong CD label (tried "GRTMHOEM_DE" and "GRTMHFPP_DE" which seem appropriate for me) or some hfslip hiccup? I'm perplexed, never seen that. Cannot reproduce the other problems as long as this big obstacle stands between me and another test install
What's wrong with my XP Home source?0 -
Hello,
Just wanted to let you know that in a another hfslip run (with version "r" this time) I had several files in the textmode phase of setup with the "could not be copied" error message. Files seemed not to be related to each other or to all belong to the same patch. Nothing changed compared to my previous attempts (except that I this time installed on a real system instead of a virtual one), so I'm really puzzled.
Not a big problem, as all these files (6 or 7 IIRC, among them "advpack.dll.mui", "jscript.dll.mui") were translation files only, i.e. "<something>.mui", but strange nevertheless. By the way, "wpdshext.res" was not affected this time.
What's going on here? Can someone confirm, or is this something only I experience with the new beta?
0 -
George King
A lot of thx. I've included it in the guide.
This does not work for me, I'm sorry.
I added KB974417 yesterday when I rebuilt my silent .Net packages (2.0SP2, 3.0SP2 and 3.5SP1) for T-13 installation (doing my WIndows setup with hfslip) witn SNM of 20090922, but afterwards this patch was still listed as missing in Windows resp. Microsoft Update...
For some reason it is not recognized as installed.Can anybody confirm this? Can I help somehow in debugging? Thanks in advance!
Regards,
Tomalak
0 -
Hello,
I can confirm that version o (20091012a) works now as desired and slipstreams MSI installer 4.5 perfectly. I was able to install silent packages for DotNet 2.0, 3.0 and 3.5 at T-13 (HFSVCPACK_SW1) and Silverlight (HFSVCPACK_SW2 with modified switches) during setup, as well as some regular MSI based software afterwards, all without any problems.
And I also already tested with all new updates from yesterday's patch-day. Again everything okay, no peculiarities.
Hail tommyp!
But today I got a new error message during the textmode copy phase (see attached screenshot) - never seen that before. Does not seem related to the updates of yesterday (as no such file is contained within them), although this is the only change I have done to my hfslip input folder. Any idea? Where does this "wpdshext.res" come from? "wpdshext.dll" is the "Portable Devices Shell Extension", I think this is a native part of Windows sources itself and not added by any later patch I think...
Does anyone know how to debug such an error ("could not be copied" is not very helpful...)? Thanks!
Regards,
Tomalak
0 -
Hello,
I found out how to satisfy MU/WU so that it considers KB905474 (item 11) as installed and does not report it as missing when searching for updates. It's one single registry entry that has to be added (not all that are listed by Acheron here are really necessary).
Please see my updated post above for details. I think most of the 'open topics' I stumpled upon when returning to hfslip are solved now. Great!
Regards,
Tomalak
Update: Sorry, seems that MSFN currently ruins the URLs of links to other posts even though I entered them correctly...
0 -
...sure it should read "IF NOT" instead of simply "IF" at the beginning of line 506? Seems to me that the logic is simply inversed here...
Yep, you're right, but it was the thought that counted. lol. New beta rev o posted. Added in gluon's contribution too.
Meanwhile tried, in contrary to my words above (who needs sleep anyway? Note to myself: don't be that impatient), previous version "n" with corrected logic.Works almost perfectly now, except one problem: the 'msimsg.dll.mui' was copied to system32\mui\1031, and not system32\mui\0407. Seems that the hex value is required here, not the decimal one...
0 -
Hello tommyp,
New beta is re-posted that slipstreams the Macrosoft Installer v4.5. Slipstreaming this is only possible using a XP OS and slipstreaming XP. Or in other words, you can't slipstream an XP source using a 2k host OS. Why? The installer is not extractable via a commandline switch in a 2000 host os.Please post constructive criticism. I have not tested this beta in an xp host os.
Ok, just found the time for a quick test (no changes in my input files except removal of the HFEXPERT\WIN\system32\mui\<LANG>\msimsg.mui file as this should be handled by hfslip now).
Sorry to say, but that failed. Still had the old Windows installer after setup (even broken in my configuration as I slipstreamed an updated msi.dll 4.5.something), with all files having version 3.1.something.
Looking at the code, without understanding too much of that batch language: sure it should read "IF NOT" instead of simply "IF" at the beginning of line 506? Seems to me that the logic is simply inversed here...
No time now to change it and re-test, but if you confirm that this is the problem, I start another attempt tomorrow. Otherwise something else is broken, obviously preventing that the MSI 4.5 slipstreaming is performed at all.
Regards,
Tomalak
0 -
Hello Muppet Hunter,
Another update. I vaguely remember reporting once something very similar (only a minor difference in otherwise very similars URLs for two different files), but I cannot find that again... STUPID STUPID STUPID MICROSOFT!
Please change the link for "muweb_site.cab" from this one:
http://update.microsoft.com/microsoftupdat.../muweb_site.cab
to this one:
http://www.update.microsoft.com/microsoftu.../muweb_site.cab
Look almost identical? Only an additional "www"? Yes, that's right! But they refer totally different files. The first one is from 2008/10/17 and contains version 7.2.6001.788 of the MU ActiveX control, whereas the second is from 2009/08/07 and contains version 7.4.7600.226. Using this most recent file, MU was satisfied on first run in Internet Explorer...
I HATE THAT! DO THOSE F****** GUYS IN REDMOND KNOW WHAT THEY DO SOMETIMES?
Thanks for correcting the link in the update list!
Kind regards,
Tomalak
0 -
Moved to the updates thread...
0 -
Hello all,
Made some progress... Here's a short update (well, not so short, have to give the story as it was some work to figure it out).
I extracted and checked out the msi v4.5 installer earlier this week. It's packed with every imaginable language! HFSLIP does not support this (neither does Nlite IIRC). Slipstreaming this is possible, but would be lots of work with no reward. I'd say that one possibility is to manually extract it, chose your language, rename the binaries and use the hfexpert directory option. Installation *could* fail though. I think that the windows xp setup routines kinda sorta needs the right msi binaries, but I could be wrong. I haven't tested the hfexpert msi method, but you are free to try it out.Seemed a little bit too much work for me, and in this case all the details for the registry from the inf files etc. would not be considered. So I started by repacking the hotfix to a new package, putting just the correct files in it (for German language in this case) and rearranging the file and directory structure so it looks like any ordinary hotfix. Finally had a replacement executable, an "improved update". Only to find out, one hour later, that running the file with the "/Q /X:<Path>" flags does exactly the same anyway: it removes other languages and leaves you with something hfslip should be able to work with... Still didn't work, file was not used
And finally I found out why: KB942288 is simply blocked by hfslip itself! Didn't think of that possibility before, had no deep look on the code - and no one told me
So after deleting the culprit, the six characters "942288" from the variable DefExcHF (line 1473), everything worked. KB942288 was slipstreamed, and I had a working MSI installer 4.5 after the setup of Windows. That also explains why it had worked before, but then stopped suddenly (at least for me, seems I'm currently the only one working with most recent hfslip beta): somewhen this update was added to the list of excluded patches...But there's one subtlely: with my approach the file "msimsg.dll.<LANGUAGE>.mui" is not dealt with properly, so if you run 'msiexec.exe' afterwards, you get an empty help window as no translation is available. This can be resolved by putting the mentioned file, renamed to "msimsg.dll.mui" (no language identifier!), to the directory "Windows\system32\mui\<LANGUAGECODE>". <LANGUAGECODE> is 0407 for German, you may have to adapt that accordingly (a list of codes is easy to find).
Et voilà, first problem solved! Will add it to my post above as well so the solution is easy to find.
As far as the WU goes, MSFT changes their mind on what registry info is present on the host OS for WU to work. I could have sworn that the CAB files or some hotfix added the necessary registry info into the install disk. If something needs to be hardcoded, I can add it in. Or perhaps it's just an outdated hotfix? I can't quite say what the answer is. [...]Well, I now can
. No hardcoding necessary, it was indeed an outdated file. Took me quite an effort to investigate, but finally I discovered that the "muweb_site.cab" was not up to date. Got the most recent one (new URL, will post that in the main update thread), put it in HFCABS, and no complaint by WU anymore...Et voilà, second problem solved!
Will tackle the remaining ones another time, enough for today. Hope that helps so far,
Tomalak
0
).
Windows Updates
in HFSLIP
Posted
Hello,
The Adobe flash player was updated once again (security issues resolved). I have uploaded the addon here at Mediafire (version 10.0.45.2)
SHA1 checksum a207aa9f705ba0b5fb27fcb92b69d8640cdae863
MD5 checksum 05e77185a011b177591a714a517e45cc