ilko_t

Found the problem: The bolded was not seen in other dosnet.inf files I've came across. Program updated and new version uploaded: vers. 0.1.1 - 23.Oct.2008 Download: 0.1.1 mirror http://www.msfn.org/board/install-USB-WinSetupF-t120444.html Thanks for reporting BTW can you give some more details about your source, is it with SP3 slipstreamed? Has the original source been modified by other program and which?

Thanks. For some reason program failed to parse dosnet.inf properly d1,asc3550.sys d1,mraid35x.sys d1,ini910u.sys First and third are fine, but d1,mraid35x.sys was parsed wrongly: To get you going just manually copy mraid35x.sy_ from D:\xp\I386\ to $WIN_NT$.~BT\ on your USB disk. Is your windows, where you run the program on English version or with localized settings?

WinSetupFromUSB.log is in \WinSetupFromUSB folder, where you installed the program. By default it's C:\WinSetupFromUSB. If the log file is too small in size check in C:\WinSetupFromUSB\backups and zip a few of the largest DATE-TIME-log.cab files if you run the program more than once. Please also include in the zip file DOSNET.INF and TXTSETUP.SIF from your XP CD \I386\. You may attach the zip file with your next post, or use public file server to upload it to, like www.datafilehost.com or www.mediafire.com.

Is mraid35x.sys in $WIN_NT$.~BT folder? Please attach your WinSetupFromUSB log:

This usually indicates a hardware problem or bad/incompatible drivers. Your best bet is to access Setup log files, found in \windows and examine them, especially the last lines. setuperr.log setupapi.log setuplog.txt setupact.log To access them you may use Linux distro with NTFS support, BartPE/Winbuilder disk or similar. If you manage to copy them and post here, hopefully we can spot some clues. Other things to try- test it with one or another stick of RAM if you have more than one or have spare. Try with another USB stick or at least rebuild this one, there could be a file not copied properly. Do you have any drivers slipstreamed in your XP source? Try plain XP SP2/SP3.

Macster, there can't be any hard feeling in the cookie trade It was an issue, not showed up in my tests as I never use special characters in folder/file names since there are still number of programs which may give you headaches if you use them. Or just a habit from the old days. Here is 0.1 with this issue fixed, just replace the exe file you have. http://www.datafilehost.com/download-4a80688c.html

Fixed, just tested it using "H:\NLite, $ # . new юя" as source directory. Will be in 0.2, for now please don't use source paths with comma in the name. Actually only the commas were the problem, spaces and other characters should be fine, it was failing in the parse DOSNET.INF procedure, where commas are used as delimiters. [FloppyFiles.3] d1,disk1,disk104 d1,ntdll.dll,system32\ntdll.dll Macster, you get the cookie What Jaclaz probably meant was if you want to stay on the safe side, you'd better stick with 8.3 DOS compatible names (especially with AutoIt scripts, written in someone's spare time as a hobby and for free ). Thanks for reporting.

Good, knowing who wrote it I am surprised that it worked As for the repair entry: \DOCS\HOW-TOs.txt:

Solved in the last version. Presetup.cmd is always executed, if BTS DP was not used, their setup-ex_ is copied and used, old setup.exe is setuporg.exe. If oempreinstall=yes is found, the relevant entries are added in presetup.cmd in order to copy $oem$ folders. If OemPnPDriversPath is found, it's values are parsed and passed to spdrvscn.exe, executed again by presetup.cmd WatchDriverSigningPolicy.exe is included in the download, but entries not added to presetup.cmd, this has to be done manually. Tested on both 32 and 64 bit XP versions.

You need to have WINNT.SIF inside XpSource\I386 folder, that would be only file used as answer file.

Thanks for the suggestions and sharing your experience, will have that in mind Hi ilko, I had noticed that there is a unattended.txt in the E:\$WIN_NT$.~LS\I386 too. can i just rename or delete from there? previously when you said there is some problem using the source from the CD. could you elaborate on that? Deleting from ~LS folder won't help, you need to delete or rename it in the source folder, before running the program. However, this is no longer required for 0.1 version, it will not use unattend.txt as an answer file when winnt.sif is not presentIf source is on a CD read-only attributes are preserved while copying files. In this case AutoIt fails to edit the files we amend- txtsetup.sif, winnt.sif, presetup.cmd... The latter 2 were fixed in beta, but not the first. In 0.1 this has been taken care of, and source should be fine to be used from a CD. Hi ilko, Very good idea Thanks for providing the AutoIt3 Source code. It is quite an impressive peace of work. I have just finished and Uploaded my first AutoIt3 GUI module for USB_XP_Setup. It is a GUI for Display and Edit of the winnt.sif file for providing the XP Setup parameters to be used in $WIN_NT$.~BT folder. It makes live again easier I am sure your source code will help me a lot in programming USB_XP_Setup completely with AutoIt3. wimb Hope it helps you Mind you, don;t rely completely on what I wrote, there is a lot to be improved in terms of error checking etc. It just happens to work, sometimes.. lol

Version 0.1 uploaded, please look at first post for download links and list of changes. In the next version - 0.2, which is almost ready the major change is, that all changes are made during GUI mode, thus user can unlpug the USB disk or start from internal disk right after GUI mode. Jaclaz is adding some functionality to binifix.cmd, which will be executed from presetup.cmd. @wimb- if we edit $winnt$.inf in system32 before start of GUI mode and make msdosinitiated=0, at T-1 setup will not wipe out the temp folders, allowing to get rid of 2 scripts and perform everything during GUI part. This is what binifix going to perform since now presetup.cmd is always executed, no matter if BTS DP is present or not. I have tested with x64 and it works too. I am using presetup.cmd to launch spdrvscn.exe from Vernalex (has 32 and 64 bit version), as per this thread: http://www.msfn.org/board/index.php?showtopic=123023 Basically unattended section is almost fully covered, besides, presetup.cmd gives many other opportunities. @Vially- thanks for the report, I think that's the only issue and it's fixed now. As for the unattended part- why not using SetupMgr.exe for example? I put in Docs\Useful_Links.txt link to it and guide for using it, if not already in \SUPPORT\TOOLS\Deploy.cab. It creates answer file in seconds. Lang&win9x folders- if you never use them why just not delete them from the hard disk, just curious. I am considering completely different GUI, still working on it as much as time allows. It will have tabs for each multiboot option added, thus interface will not be overloaded and I can add more checkboxes/options, however, this will not be out in a week or month, just spare time does not allow. edit: how about a button "advanced", which opens up another GUI with advanced settings?

Just copy your XP source on the hard disk (drag&drop from Explorer would work too) and rename unattended.txt in I386 folder. Next launch the program and continue. Getting rid of this option, thanks for reporting

@Kaida- check if in your source you have unattended.txt. It's used as answer file if winnt.sif is not present. As far as I know behavior when installing from a CD is the same- it looks for unattended.txt and uses it if winnt.sif is not present. If you don't want to use these setting you can rename that file to anything else. Make sure your source is on a hard disk, 0.1 A and B fail to change a few lines if source is on a CD. Fixed in the next version, which I am currently testing before publishing.

Please copy ModelRam.exe from liveXP folder to root of USB disk and let me know if that works. This was the only change I did, just tested 075 beta E and it worked, not using winbom.ini.

Antivirus software for some reason is sensitive to AutoIt scripts, there are always false alarms. To stay on the safe side you may cross-check on virusscan.jotti.org or virustotal.com. winbom.ini looks file, need to investigate further what else it could be. edit: What's the exact version of WinBulder you used?

Thanks, bug indeed. Quick fix- create in USB drive root winbom.ini: [Factory] WinBOMType=WinPE Reseal=No [WinPE] Restart=No [PnPDriverUpdate] [PnPDrivers] [NetCards] [UpdateInis] [FactoryRunOnce] [Branding] [AppPreInstall] and delete winnt.sif in \minint. BartPE/UBCD4Win/WinFLPC were tested and did not need winbom.ini. Seems WinBuilder does need it. Will fix that asap, winbom.ini doesn't seem to interfere if Windows setup coexists in the same partition. edit: Apparently forum software was updated, there was a post above yours, which disappeared magically while I was trying to log in and reply.

grub4dos starts ntldr on the usb disk which fails. Error message is from the latter, which cannot see your esata disk.You still have the option to install XP on the same disk, but using the USB interface, links were given above.

Ahh, you should have started with this It should be possible to make the Windows work from the esata, but needs some experience and time: http://www.911cd.net/forums//index.php?showtopic=21242 cdob has even made a batch file, which automates the process, haven't read details or tested, should be in that thread somewhere. As for the USB port- we are back to square 1- look a few posts above the links I gave you, they are for XP installed on USB drive. edit: In simple words- integrated in the motherboard esata, actually just another external sata connector- good chances you can boot from it since BIOS provides extension. esata port via external card or PCMCIA card- no. Unless manufacturers implement this functionality. It's like using SCSI card, which doesn't have it's own BIOS, extending your motherboard BIOS. This is not something I can comment thoroughly, little experience with it.

hd0 is your USB disk, hd1 is the internal disk with Vista. Why NTLDR is found on both hd1,1 and hd1,2? Do you have there another XP or recovery partition? Seems your laptop doesn't provide BIOS extension for the esata disk, hence it's not seen by grub4dos and ntldr-->that's why the error "Windows could not start because of a computer disk hardware configuration problem..." and why grub4dos is not displaying it. First part goes fine, because the sata driver helps installer see the disk, but more important is if BIOS provides arcpath for it, it seems not. There is a slight possibility this to happen because of the new Vista partition rules, this is a random shot of mine: http://www.multibooters.co.uk/partitions.html If you can, backup whatever you have on the external disk, and use other tool to delete all partitions on it and create new ones, even by using Text mode of XP setup for the purpose. What is the exact model of this laptop? Have you googled if other people managed to have AND boot XP from esata disk, connected to it? Do you have any setting in BIOS, regarding esata ports?

@thegr8anand Another test- when you start from USB and see any of the menus, press C on your keyboard, it will go into command prompt. There you type exactly: root ( <---and press tab key It should return something like "Possible disks are hd0 hd1..." Post the result here. Next type: find /windows/system32/$winnt$.inf <----press enter Should return something like "(hd1,1)" Post the result here.

BOOT.INI has improper entry, pointing to non existing location.Can you post here winsetup.lst from USB stick root? Was this hard disk partitioned from Vista disk management? On second read- back to your external disk, I guess you have eSata port, right? Are you sure Windows will start from it? Have you had any operating system on it? Are we sure you can boot from it? http://www.boot-land.net/forums/index.php?...ic=3366&hl= Hi ilko, Might it be that this problem is solved with [Data] AutoPartition=0 This works for me in USB_XP_Setup, where [unattended] Section can be used as normal. Works because msdosinitiated=0 msdosinitiated=1 combined even with an empty section [unattended] results in that behavior. I'd love to be proved wrong, it would save sooo much trouble.

Without the exact error message before I can only guess what the problem was. On second though- similar message would come if you started second part of setup first, did you? First part (Step 1)- Text mode, the one without mouse, where you format disks etc. Second part (Step 2)- GUI mode, the one with mouse and better graphic. Fat32/16 can be painfully slow on some systems, USB stick matters too, it seems. NTFS really makes huge difference in those cases. Reminder again- start from USB 3 times- Text, GUI mode and first start of windows. This is important.

@thegr8anand- since you have BTS driver packs integrated you are fine about the unattended part. Lets fix the boot. Can you give some more details about the error message? My guess is that you started from USB and you got that message, which means grub4dos was not installed properly on the USB bootsector. Can you go in \WinSetupFromUSB\files\grub4dos\ and launch grubinst_gui.exe giving it admin rights. Select radio button DISK and select your USB disk. Be careful which one you select. Use disk sizes as a clue, just in case. Then click refresh button next to PART LIST and select from the drop-down menu the partition on the USB disk. Select Verbose output and click INSTALL. If you see that it successfully installed, try to boot again from the USB disk. If not- please make a screenshot or post what it says. @Macster- thanks : ) I should be ready with next version in a few days, most of the new stuff is about unattended install. Started using the same approach as BTS team is using (fake Setup.exe) and presetup.cmd to carry out whatever could be done for the unattended section. However, there is quick and dirty workaround- the problem with unattended section is that if it's present, even if empty, Text part of setup doesn't ask where to install windows to and puts it on the USB drive, where ~BT and ~LS folders are. Well, it won't if you create a few big dummy files, making the disk space less than the one stated in txtsetup.sif ~1.1GB on unmodified XP. Now you can safely put back unattended section in winnt.sif and start setup- it will try to install there, say that it can't and go back to the disk list fsutil file createnew U:\dummy1.temp 1000000000 This makes setup 1:1 as from a CD, regarding contents. I was thinking to use this approach, it eliminates all the mess with unattended section, but if one is with a USB hard disk or 16GB stick it's not practical to occupy all the free space.

Nope, where you setup Windows you set during Text mode. We need to know that in advance, because of the USB disk drives are "shifted" and resulting BOOT.INI from Windows setup is not proper. That's why we need to know in advance and create proper boot.ini in order to start GUI part of the setup and Windows for first time. Remember to start from USB 3 times- Text mode, GUI mode and first start, when desktop is fully loaded you can unplug the stick. edit: unless you have custom files/folders in $OEM$ to be copied you are fine. If you do have- then easiest way is to integrate BTS mass storage drivers pack to your source and redo the USB disk. Here is why: http://www.msfn.org/board/install-OEM-drivers-t123023.html 0.2 is almost ready, all this has been taken care of, beta testers are always welcome btw, just let me know if you can help