ilko_t

From PE disk, boot.ini on the hard drive. When you open it there are 2 lines with rdisk in it. Both values should be the same. Well, you have hit a thread with a method, which is relatively new and barely tested. Unless you have the time and willingness to experiment I'd suggest you to stay with the proven to work and well tested methods:http://www.msfn.org/board/index.php?showtopic=111406 http://www.msfn.org/board/index.php?showtopic=120444 http://www.msfn.org/board/index.php?showtopic=121446 Using (heavily) modified sources makes the things trickier, but I do not remember a case in this subforum, which has not been resolved. Setup started by WINNT.EXE from DOS and WINNT32.EXE from PE environment are always an option too. And you got reply. Rebuilding the USB disk in order to gather the required information would have not costed you much time, would it? I guess not more than 10-15 minutes with USB hard drive formatted in NTFS.

This one should be because of wrong partition(X) value in boot.ini. Did you start from USB the second time? Does partition number in boot.ini match the partition number you installed to? Do rdisk values in boot.ini on the internal hard disk match? Since you can boot from PE disk you should post the relevant information, this would save both parties time. In other hand- what are you trying to accomplish? Need one-off install or you are willing to experiment?

Wrong rdisk value in boot.ini on the internal disk...

Nothing interesting in the log files. Without presetup.cmd and setup.exe comparison I cannot help any further.

Please post ~LS\I386\presetup.cmd and compare file sizes of extracted setup.ex_ and setuporg.exe, do they match? Please attach WinSetupFromUSB.log found in program's directory, along with the old archived logs, found in \backups\date-time-log.cab. edit: have you removed by any chance 16-bit support by using nLite? Maybe the fake setup.exe needs some components in order work properly and execute the real setup.exe (setupORG.exe) after had launched presetup.cmd.

I'd try with a source in a folder too. Nah, just the time zone. As for waking up early mornings- that's never been my strong side

You meant SetupSourceDevice = \device\harddisk0\partition1, right? What was SetupSourcePath? I thought it was a typo. Maybe on real hardware result will be different That's restrictive, I personally would always use NTFS plus one may want to install windows on the second or third internal HD. Maybe search for a tag file... In other hand, binifix.cmd at start of GUI is a proven to be working option.

Check \windows\system32\$winnt$.inf where Setup looks for the source files. Check setup log files in \windows too.What did you put as SetupSourcePath in txtsetup.inf? Were those missing files from a slipstreamed SP or updates? Check paths to them in txtsetup.sif, they may differ from those of a 'regular' source file. This is expected behavior- Setup would put boot files on the first fixed hard disk according to BIOS order. In case of USB stick which is normally 'removable', Setup puts them on the first fixed disk.rdisk value is not wrong. According to BIOS order the second disk, where Windows is being installed to, is rdisk(1). There is still need to mess up with BOOT.INI later on. The only way we found to avoid this behavior was to "break" HD order using grub4dos map command. Seems at that stage grub4dos mapping is still in effect. Setup would detect a strange situation and will use HD signature along with ARC path- e.g. signature(de33eaf8)disk(0)rdisk(0)partition(1)\WINDOWS. Note, rdisk value is the desired one. Those were tests with USB sticks. Signature part also seems to cause delay during boot, longer or shorter, depending on the system. Read around this post for details: http://www.msfn.org/board/index.php?showto...st&p=646746 Read here:http://www.msfn.org/board/index.php?showto...st&p=776205 In short- if MsDosInitiated="1", then SetupSourcePath and SetupSourceDevice are ignored, it defaults to $WIN_NT$.~LS, source files gets deleted as the source path is considered as temporary, saving disk space as the installation goes along. MsDosInitiated="0"- SetupSourcePath and SetupSourceDevice are taken into account, source path is no longer considered as "temporary", no files are deleted.

Try if you get a chance running it on English version of Windows, it could be something to do with the localization, just a guess...

That's all. In case of fixed disk a few lines are added for rdummy.sys as well. I've tried using the posted original txtsetup.sif and the resulted file was OK. Could be something to do with AutoIt & Vista x64 @HarryKane Can you try the tool on another computer, running XP or Vista 32 bit?

Good one A few questions: 1. Does boot files (NTLDR, BOOT.INI and NTDETECT.COM) get copied to the internal disk? What are rdisk values in it? 2. Has anyone tried it with USB memory stick? With USB hard disk when booted from it SetupSourceDevice should be as mentioned harddisk0, but with USB memory stick it becomes harddisk1 etc. as mentioned in the related topic. Has anyone observed different behavior? 3. I guess USB hard disk gets drive letter C:, correct? Using migrate.inf should help as no driver is used to patch removable/fixed result. 4. Why putting XP source in ~BT folder? Should be easier to copy it as it is in own folder, and give this path in txtsetup.sif: SetupSourcePath = "\xppro\"

Can you post your WinSetupFromUSB.log file? What operating system do you run the tools under? What is the brand/model of the USB disk/stick used?

What are contents of this CD? Is it a recovery CD, restoring the factory image or an OEM Windows, which you can install?Run the following in command prompt: dir F: /b /s > c:\list.txtWhere F: is the drive letter of the recovery CD. Compress and attach or upload in datafilehost.com c:\list.txt with your reply.

Your boot files (boot.ini, ntdetect.com, ntldr) are most likely on D:. Make BOOT.IN on USB disk like : [Boot Loader] Timeout=10 Default=multi(0)disk(0)rdisk(2)partition(1)\WINDOWS [Operating Systems] multi(0)disk(0)rdisk(2)partition(1)\WINDOWS="Continue GUI Mode Setup XP + Start XP from HD 1 - Part 1" /FASTDETECT multi(0)disk(0)rdisk(2)partition(2)\WINDOWS="Continue GUI Mode Setup XP + Start XP from HD 1 - Part 2" /FASTDETECT multi(0)disk(0)rdisk(2)partition(3)\WINDOWS="Continue GUI Mode Setup XP + Start XP from HD 1 - Part 3" /FASTDETECT multi(0)disk(0)rdisk(2)partition(4)\WINDOWS="Continue GUI Mode Setup XP + Start XP from HD 1 - Part 4" /FASTDETECTand test each entry in order to start GUI mode and start Windows for first time. The entries which should work are HD1- Part2, or HD1- part 4. Once you install windows and enter the first windows desktop, you need to manually amend BOOT.INI in D: and change rdisk values to rdisk(1) if they are rdisk(2). Why this has happened: http://support.microsoft.com/kb/234048

What program is the screenshot from? Do you have any other operating system installed and starting? Can you post a screenshot of disk management, showing all disks and partitions? Is the disk with partition D: first in BIOS boot order? Is either of those disks IDE? Which one is IDE/SATA? Any reason to use logical partition for F:?

Did you place XP setup before copying Vista and other stuff? If grldr was placed later on it may not be reachable by the bootstrap code, being beyond certain boundary. Always copy boot files first, then all the rest.

Please list all your partitions and their contents, as well as which one is set active. A picture like this could be very handy as well:

I would check the hard disk with its manufacturer tool a few times with the extended test, check IDE/SATA cables, check if jumpers MASTER/SLAVE are correctly placed, and finally play with BIOS settings for hard disk mode- LARGE/LBA/AUTO. How old is the hard disk? Is the computer overclocked? The problem has nothing to do with USB boot or Windows setup edit: what file system do you format the windows partition in?

As a side note- use NTFS for the XP setup pertition: http://www.msfn.org/board/index.php?showtopic=125116

I am glad it's now resolved The file is just a tag file, it should have worked with any other TAG file or folder, which is present on the USB, e.g. SET TAG=\$WIN_NT$.~BT, unless that tag is coded in the fake setup.ex_ as well. Have to play a bit with the latest BTS packs to see what has been changed.

It seems presetup.cmd does not get executed. The reason would be incorrect setup.ex_ used. Can you put back \files\winsetup\setup.ex_ in ~LS\I386 AND change SET TAG= to \OEM. If that resolves the problem, compare the extracted setup.ex_ (expand setup.ex_ setup.exe) with setupORG.exe in your XP source, are they the same? If yes- what BTS base did you use, any night build or beta? Have you used nLite or similar tool AFTER integrating BTS packs? Just random ideas... BTW- do you have any internal/external card readers in this computer? Can you disconnect or disable them?

Have a look at this topic and the links within: http://www.msfn.org/board/index.php?showtopic=128303 Look at the FAQs as well. This is the most common situation and has been discussed many many times

Here it is: presetup.cmd: SET TAG=\WIN51 This file is not copied by default. In the previous BTS integrators the tag was \OEM folder. You may copy back setup.ex_ from your XP source to ~LS\I386\ and WIN51 to USB root, or change presetup.cmd to SET TAG=\OEM. Hopefully this will resolve all the issues. I will make the required changes in the program, thanks for reporting

That would require a lot of changes, so no such plans any soon. Well the file in the WinSetupFromUSB directory was indeed different to the one on the USB, however overwriting it does not seem to have made a difference. I have also just realised that this might perhaps be related but, when the GUI portion of the setup begins, where the Driverpacks extraction would normally take place (i.e. the light blue screen where you can see only the cursor) shows for a few seconds, before launching straight into the "billboard" setup screens However, I also get a Command Prompt appear showing: Microsoft Windows XP [Version 5.1.2600] <C> Copyright 1985-2001 Microsoft Corp. C:\WINDOWS\system32> I tried typing "presetup.cmd" at this prompt at which point I get a scrolling list of commands, implying that it is running the presetup.cmd, but it doesnt seem to do anything else (I.e. I do not see the unzipping of .7z files as I normally would) not that this is all taking place while normal installation is continuing in the background... (Note that this was happening before as well as after I copied an setup.ex_ files as you suggested, I didn't realise until now that the two may perhaps have been connected) On the case of the log file, there seems to be rather alot inside of it, is there a specific phrase i can search for? Or should I upload the log and link to it? Thanks again. This is weird behavior I've never seen. As you can see the section in presetup.cmd added is at the bottom and should not affect the entries above it. No idea why the modified setup.exe does not launch presetup.cmd automatically either Does SetupORG.exe exist in the XP source? Maybe BTS guys made some changes to their integrator... How it was before- original setup.exe is renamed to setupORG.exe and replaced by a fake one, which executes presetup.cmd and then launches the original setup.exe in order to continue GUI mode. If WinSetupFromUSB finds setupORG.exe it does not copy the fake setup.exe, if not- the original setup.exe is extracted and renamed to setupORG.exe and the fake one is copied to ~LS\I386\. As for the log files- please put them all in a zip archive and upload them somewhere. Format the USB stick with HP USB format tool using NTFS. Select Vista setup checkbox, browse and give the Vista source path, then click GO. That's all.