Tomalak

Member
  • Content count

    162
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Tomalak

  1. 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
  2. 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
  3. 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
  4. 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 PROCESSDATA.TXT
  5. 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...
  6. 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... [*]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
  7. 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! No 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
  8. 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...
  9. 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
  10. 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
  11. 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
  12. I've uploaded an updated SWFLASH.CAB (version 10.0.42.34) here SHA1 checksum c0d67df4e53927ecf834ca007816d43a0c62add5 MD5 checksum 07bd474624bfa8e0937dea4eefdf18a8 Are 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
  13. 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
  14. 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
  15. Well, it was not. Of course. I meanwhile found out the reason... Stupid me 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