ilko_t

I guess if we start with the basics it would be easier to understand. Forget for now scripts, PE etc. etc. Lets figure out how Setup works. BIOS-->MBR on USB disk-->active partition boot sector. If it is a NT bootsector it will invoke NTLDR, which calls NTDETECT.COM, which enumerates the hardware and return to NTLDR, BOOT.INI is parsed for boot menu. NTLDR can chainload a bootsector. This is the same NT bootsector saved as a file, but the strings NTLDR are replaced with STLDR, thus it will invoke STLDR (SETUPLDR.BIN renamed) instead of NTLDR. NTDETECT.COM is recalled. Since it returns it's a hard drive, Setup goes in this mode, searching for $WIN_NT$.~BT folder for the boot files. Here we must note that SETUPLDR.BIN in ~BT folder can be directly invoked, if using grub4dos as boot loader for example. title Chainload SETUPLDR.BIN chainloader /$WIN_NT$.~BT/SETUPLDR.BIN Lets go back a step. GRUB4Dos can be launched in a various ways: 1. Own MBR code, which searches disk partitions for GRLDR file and loads it. 2. Own bootsector, loading GRLDR from the same partition. 3. Invoked by NTLDR/BOOT.INI: C:\grldr="Start Grub4Dos" 4. Using the same technique as loading STLDR- just replace the strings NTLDR in NT bootsector with GRLDR. This will fail on FAT16 partitions. Thanks to cdob and jaclaz for sharing their huge knowledge in this field. Now we loaded SETUPLDR.BIN using any of the above methods. Since it's in a "hard disk" mode, TXTSETUP.SIF is expected in root of the boot device. WINNT.SIF is expected and read from ~BT folder. SETUPLDR.BIN loads the drivers listed in TXTSETUP.SIF, then initializes them at once- "Windows is starting" message. At that point WINNT.SIF is read. The line MsDosInitiated is critical. If value is 1, then source files are expected in $WIN_NT$.~LS folder. If value is 0, SetupData section in TXTSETUP.SIF must point to the location where source files are, read for details: http://www.msfn.org/board/Alternative-loca...en-t119742.html A) Lets assume MsDosInitiated = 1. If section Unattended in WINNT.SIF is found, Setup won't prompt where to install Windows on, by default this is the partition/disk where Setup was executed from. Setup starts copying files from ~LS folder, deleting the compressed ones as they are copied to Windows folder. This is bad for us. To avoid this we write-protect USB drives using MIGRATE.INF. The trick works for Windows XP SP2/3 only. Possibly for SP1 too, not confirmed. Doesn't work for 2000/2003/x64. Thanks to cdob for this brilliant idea. Thus Setup cannot delete them while copying. I guess this design was made with disk space in mind, since by design those folders ~NT and ~LS are on the disk where Windows is installed to, considered as temporary and the disk space could be limited. At the end of Text mode Setup boot files (NTDETECT.COM, NTLDR and BOOT.INI) are placed to the disk, where Setup thinks boot will occur from. In case of Removable disk- it's ignored and files are places on the first active primary partition of the first fixed hard disk. In case of Fixed disk- the same rule, but now this happens to be our USB disk. This is bad too. We want them on the internal disk. Hence we use a driver (rdummy.sys) which patches all requests "Are you removable disk" to the USB and returns always "Yes, I am". Thus boot files go to the next disk, which is our internal one. BOOT.INI is created according to BIOS boot order. Internal disk is seen as second, boot disk(USB) is first. multi(0)disk(0)rdisk(1)partition(1)\WINDOWS is created, instead of rdisk(0) which we want. Text part is done, now time for reboot. On reboot we can NOT start from the hard disk, as it has incorrect BOOT.INI entry, and we have no means* to adjust it during Text mode. Hence we start the second part, using NTLDR/BOOT.INI on the USB disk again. *Some "tweaking" is possible by using grub4dos ability to map a disk to another, i.e. title Phase 1 WinXP Text Mode Setup map (hd0) (hd1) map --hook rootnoverify (hd1) chainloader (hd1,0)/$WIN_NT$.~BT/SETUPLDR.BIN This will result in a proper BOOT.INI, but will also add a signature to BOOT.INI entries, since Setup sees strange partitions. This signature Wimb reported that caused delay when booting from the hard disk. Setup continues with GUI mode. What is interesting for us is at T-1, right before it's completed. Then it will attempt to remove all temporary files and folders. This includes our ~BT and ~LS folders. To avoid that we execute a script (ren_fold.cmd) at T-9, which renames ~BT and ~LS folders. Setup is tricked- can't find and mess with our folders. BOOT.INI is amended again by Setup- timeout entry is made 30, also checks are performed if it's correct. This is bad for us again- cannot make a script, correcting BOOT.INI in this stage. Time for first boot- since BOOT.INI on hard disk is still with a wrong entry, we have to use NTLDR/BOOT.INI on the USB disk again. Upon first launch of normal desktop, we correct BOOT.INI with a script (binifix.cmd made by jaclaz), making the default entry from rdisk(Z) to rdisk(Z-1), i.e. from rdisk(1) to rdisk(0). In other words we "remove" the effect the USB disk caused on creating BOOT.INI entries. At the same time we rename back BT and LS folders to their normal names in order to be ready to be used again. This much for normal "hard disk" type Setup. =================================== B ) Now lets go back to this thread: http://www.msfn.org/board/Alternative-loca...en-t119742.html This shows us how Setup can be pointed to alternative location of source files, not ~LS folder as expected from hard disk type install. MsDosInitiated must be 0, Setup will ask TXTSETUP.SIF where source files can be found. [SetupData] SetupSourcePath = "\" SetupSourceDevice = \device\harddisk1\partition1 This would mean folder I386 is expected in \ (root) of \device\harddisk1\partition1 i.e. source files are in \device\harddisk1\partition1\I386 SetupSourcePath could be "\xppro\" or anything like this, so we can tidy up the folders, instead of placing everything in root. Unfortunately Setup sees USB disk at that stage as harddisk1, instead of 0. This is in case with 1 internal hard disk. If you have 2, USB disk will be harddisk2... A bit restricting. Anyway, since it's no longer "hard disk" type setup, unattended section in WINNT.SIF would not force installation on the same hard disk without a prompt, also files will not be deleted neither during Text part, nor during GUI part of setup. Since we booted from USB and ~BT folder is on USB, BOOT.INI on the destination disk will still get wrong entries, rdisk(1) for example, instead of rdisk(0). binifix.cmd is stil needed. Wimb used this cleverly in another way- boot from USB PE environment (WinBuilder), create the ~BT folder on the destination hard disk, find how many disks are attached and set SetupSourceDevice in TXTSETUP.SIF accordingly (USB disk will be the last one), leaving the "main" source on the USB disk. Next boot is from the hard disk, where Setup is launched from ~BT folder. Since boot is from the internal disk, BOOT.INI will be created with the proper entries. A quick note how SETUPLDR.BIN behaves if NTDETECT.COM returns that is executed from CD, Floppy or Hard disk media: CD- files are expected where SetupSourcePath in TXTSETUP.SIF points to. Floppy- boot files are read from the floppy (~BT folder), source files are to be found on a CD Hard disk- boot files are expected in ~BT, source in ~LS folders. This is pretty much what's happening and why all the mess with the Setup from USB, hope I put it in a understandable way.

First way is migrate.inf. Assigning U: or whatever to the USB disk "frees" letter C: for the first hard disk/first primary partition. Migrate.inf consists the entries from HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices, where each disk connected has own "signature" to say it in short, and corresponding drive letter. Look here for details: http://www.goodells.net/multiboot/partsigs.htm Migrate.inf is parsed when Setup enumerates the present disks. Second way- given USB stick, which is seen as REMOVABLE, and IDE disk with one primary partition, AND booting the Setup from the USB disk will result of internal disk getting letter C, and the USB one- D. If you boot Setup from USB stick, which is seen as FIXED(BASIC), or a USB hard disk, which is always FIXED/BASIC, Setup will give USB disk/stick letter C, and the internal disk gets D. Some details about REMOVABLE/BASIC(FIXED): http://www.codeproject.com/KB/system/sovie...;select=1468078 http://www.osronline.com/DDKx/storage/k306_00qa.htm Now lets make it trickier- USB stick, which is seen as REMOVABLE, SATA disk attached to SATA controller working in SATA mode, with one primary partition and IDE CD ROM. Now Setup flips the order again- USB stick gets C, SATA disk- D. The present IDE device messes with the enumeration. Technical explanation why is beyond my knowledge, it has something to do with the way the disk.sys/partman.sys read info from BIOS, and lets not forget that Setup has never been designed for USB disks and dates back to the days of NT. In the long initial thread and the links within you can find all kind of information, about the boot process, how Setup sees the disks, the first guides and batch files, which will be much easier to understand, how REMOVABLE/FIXED bit is "flipped" etc. etc.: http://www.msfn.org/board/How-to-boot-inst...key-t61384.html

The next version will support everything as if installing from a CD. Hence no hacks or modifications will be needed to to accomplish such tasks.Currently working on it, should be ready very shortly. The program is not messing with these settings. You most likely have a file unattended.txt in your source, which if found is copied and used as winnt.sif. This replicates what normal Setup would do.If that's the case- have a look in \I386 in your Windows source and rename unattended.txt to anything else BEFORE you use the program if you don't want to use it. Thanks for the feedbacks

Yep, no issues with that.

If you don't rename ~BT and ~LS folders using ren_fold.cmd before end of GUI part there will be loooooong delay at T-1 (removing temporary files)

(USB) boot process has several stages, say 1-2-3-4-5-6-7.... You fail at 1 or 2, and you are saying: which matters for stage 6-7 or 8 and is not relevant to your problem. Makes sense now?

You need to give more details on the bolded text- black screen, blinking cursor, error message or what?How did you prepare the USB stick, how did you format it, with what program? Do not confuse USB boot ability with what XP source you placed on the USB stick, in that early stage XP version does not matter at all.

ercofra, thanks for your tests and ideas Now it's our turn.

jonsa79- what partition are you installing windows to? First, second...? What folder name you gave for Windows, is it the default Windows? Doe the laptop have a hidden first partition? Please post your BOOT.INI on the root of the USB stick too. There must be a mismatch between BOOT.INI parameters and the location you install Windows to. tonich- thanks

Incompatible HALs are switchable- have a look here and the follow ups: http://www.911cd.net/forums//index.php?sho...st&p=136937 http://technet.microsoft.com/en-ca/sysinte...s/bb963892.aspx http://support.microsoft.com/kb/309283 http://support.microsoft.com/kb/237556 OfflineSysPrep is changing HAL files instead, as far as I remember a few registry entries were added as well when switching from Standard to ACPI supporting ones in order to get the service running, details should be in the same thread. Another way- Standard HAL is compatible with all machines, no ACPI functions, but who cares if portability is needed... Another way- NTLDR from Longhorn beta can auto detect and change HAL: http://www.911cd.net/forums//index.php?sho...st&p=144100

Good job That means Text mode part adds those paths to the registry. Can you do another test, I think Vernalex spdrvscn.exe will come handy in order to automate adding paths to drivers. Can you replace REG ADD... line with: %SystemDrive%\Drivers\spdrvscn.exe /p %SystemDrive%\Drivers /a /s /q and copy spdrvscn.exe in %USBDRIVE%\$WIN_NT$.~LS\$OEM$\$1\Drivers\ If it works I am thinking of a line like: IF EXIST %USBDRIVE%\$WIN_NT$.~LS\$OEM$\$1\Drivers ( %SystemDrive%\Drivers\spdrvscn.exe /p %SystemDrive%\Drivers /a /s /q ) If you don't need to keep those drivers, you could not copy them and use paths on the USB disk itself... I will work a bit to add support for presetup.cmd, should be fine for x64 versions too: http://www.msfn.org/board/x64-Drivers-From-CD-t50023.html Thanks for your feedback ilko

Excellent work, thanks Can you check if "Drivers\000_chipset;Drivers\001_ethernet;Drivers\002_graphics;Drivers\003_audio..." with %SystemRoot% at front are present in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion -->DevicePath If not present, then they may be added by Text portion of Setup, not by the GUI when we merge [unattended] section back. In this case we may use presetup.cmd to add those keys to the registry. Vernalex Sysprep Driver Scanner would be of good use for the purpose. The next step would be to make sure presetup.cmd is always executed, will investigate that further.

Program updated to 0.1 Beta, please refer to first post for list of changes and download links.

Presetup.cmd is launched at start of GUI part of Setup, before anything else. It's launched if it's found in I386 or AMD64 folder, no further entries are needed. There was a bug in WinSetupFromUSB in that version, which was fixed meanwhile, but not released- if presetup.cmd does not exist, some lines were not added. MkMigrateInf will be included in the next version, most likely as an option. Currently working on the beta version, should be done in a few days- just came back from holiday. Whats the path to them in WINNT.SIF? Can you post that part?Microsoft articles are confusing about where $OEM$ folder should be placed, either in ~LS folder, next to I386, or within I386. Can you copy $OEM$ inside ~LS\I386 and check if Setup finds the DRIVERS folder? edit:- can you include with your next post Windows setup log files, found in \Windows as attached archive? Need to find where Setup searched for \DRIVERS folder.

Can you post presetup.cmd in ~LS\I386 folder? Grub4dos version was the most stable by the time of writing, will be updated, thanks for the feedback. Can you elaborate a bit more about Documents and Settings issue? How do you use it in your setup? You may also try this, [unattended] section is not an issue when using alternative location: http://www.boot-land.net/forums/index.php?showtopic=5306

Try this: http://www.msfn.org/board/WinSetupFromUSB-...UI-t120444.html It should handle [unattended] section properly. Please let me know if it worked fine, amend WINNT.SIF prior to using the program!

Was PC field engineer for 4-5 years, in IT for more than 15, perhaps 80% of the jobs were malware on PCs with the bloated preinstalled Norton and McAfee. Number of jobs due to Norton AV screwing Secure web pages, for some reason unregistering a few DLLs, leading to empty pages and non-working applets such as System Restore, Search etc etc. Thank you Symantec and McAfee, you have brought so many clients... NOD32- useless in my opinion. I have seen so many PCs, where it's real-time scanner missed viruses, but on manual scan it finds them as such, properly configured, licensed versions...Are people really attracted by it's small footprint? Or what? I really wonder where all the noise about NOD comes from... One of the sites, which happens to cover exactly my observations, have a look at the tests- http://www.virus.gr/portal/en/ To declare- I am not associated with it in any way, it just repeats my observations during the years. And this is for detection rates, how well the malware is cleaned and how well the real-time scanner protects itself and blocks the malware before it gets installed is another story, and in my opinion KAV is unbeatable last few years. Another point- I often find new undetected malware (scan at virusscan.jotti.org or virustotal.com) and send them to a few famous AV vendors. KAV usually replies within an hour and within 2-3 hours signatures are updated for the examples I had sent. DrWeb has the same response time. Symantec- since first 5 times I got no answer I stopped sending them. McAfee- first few samples answer was received between 2 and 4 weeks. TrendMicro- 5 weeks on the first 2 and I stopped sending them as well. NOD was not among those and cannot comment in this aspect. Exactly.

Did you miss this topic? http://www.msfn.org/board/WinSetupFromUSB-...UI-t120444.html The program has been made exactly with your thoughts in mind. http://www.msfn.org/board/WinSetupFromUSB-...880#entry780880 For example:

Or just include BTS driver packs while installing XP for the hardware you will need (chipset, mass storage, LAN, WLAN...). Upon first boot on new hardware it's a bit slow installing all drivers, but once "trained" on various machines it's fine. Use the modified NTDETECT.COM too, for the machines with buggy BIOSes.

It's possible and works in most cases, read Dietmar's guides as well as his posts in the long thread here, I know, it's pretty long, but if you manage to understand the details, you will be able to do all you have to and A LOT more. Include BTS drivers pack to the installation too, at least chipset, mass storage, LAN and WLAN. Use File-Based Write Filter when necessary. Use the modified NTDETECT.COM as well.

Sorry about the delayed responses, I am still on holiday and have a little break from computers Good, NTFS really helps sometimes. For HAL.DLL error please check the FAQs. Umm, you need you ammend your syslinux.cfg for the particular distro and check kernel parameters for USB boot. The program just adds syslinux bootsector, copy the contents to USB and loads syslinux, and from the message you have posted it seems that syslinux is loaded indeed. It happens if your source is on CD, will be fixed very soon. Please use the file in post #36 it's fixed there, just extract it to WinSetupFromUSB folder and launch it instead of the other EXE. When I get back from holiday will put all changes in new beta version. Thanks for the feedbacks. ilko

Which part goes slow? Loading drivers during Text mode only or loading drivers AND copying files at end of Text mode? If it's first- your BIOS does boot in USB 1.1 speed, after loading drivers it should be USB 2.0. If second- try formatting stick in NTFS/FAT32 or FAT16 if it's 2GB or less and BIOS supports boot from such, matter of experimenting.

This is part of Binifix4.cmd, which is launched at GUIRunOnce, you may include your stuff inside or use the code. Mind you- when multiple windows sources are on the USB stick, tagfile is different- WIN_00.BT, WIN_01.BT etc. etc. You may use your own tag file. SET USBDRIVE= SET TAGFILE=\WIN_NT.BT FOR %%h IN (C D M N O P Q R S T U V W X Y) DO IF EXIST "%%h:%TAGFILE%" SET USBDRIVE=%%h: if "%USBDRIVE%" == "" ( FOR %%h IN (E F G H I J K L) DO IF EXIST "%%h:%TAGFILE%" SET USBDRIVE=%%h: ) menu.lst will be fixed in next version, by the end of september when I will have spare time- have a look at the posts at bottom of first page and firsts on second page of this thread- they are all about menu.lst and the default entry. edit: similar part for finding USB drive you will find in ren_fold.cmd, launched from SetupParams in winnt.sif. edit2: It would be good idea ren_fold.cmd or binifix4.cmd to set the found drive letter in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup SourcePath Need to investigate when it is created, and will include it in the next version, thanks.

Good You can safely ignore that error if bootfont.bin doesn't exist in \i386. Did you perform installation, any issues there?

Heh, quotes were not expected there too Here is a version, which should take care of them. http://www.datafilehost.com/download-4bf62239.html BTW what version of nLite is that? It rather seems like nLite bug, I wonder if winnt32.exe would accept that syntax.