[jaclaz]

ilko_t said:

I see the proper massages, answer YES to replace original boot.ini with boot.txt and get "the system cannot find the file specified. Could not find c:\windows\system32\boot.txt.", boot.txt is in root and looks ok, with all needed entries.

I'll look at it, maybe some "paths" are incorrect.

EDIT:
My bad, just temporarily change in the batch this:

:WriteBootIni 
CALL :attribs %source%
Copy boot.txt %source%
del boot.txt
ATTRIB !switches! %source%>nul
GOTO :EOF

to this:

:WriteBootIni 
CALL :attribs %source%
Copy %BOOTTXT% %source%
del %BOOTTXT%
ATTRIB !switches! %source%>nul
GOTO :EOF

I'll re-check the batch and add a kind of error check for this in next release.

ilko_t said:

About boot sectors- still having issues after winnt32 is run and files put on stick.
Using Hitachi driver and format stick from XP no matter FAT16 or 32, copy ntldr, boot.ini and ntdetect.com - boots ok to boot.ini

Run winnt32 with parameters to put files directly on stick- cannot boot stick at all, no matter FAT16 or 32, nor if boot files copied before or after winnt32.
Interestingly, yesterday I managed somehow to make it working this way using FAT32, and the same routine, no flipping idea what it wants. Could try reverting bootsectors, but am tired of this.

It could be some kind of "glitch" in the FORMAT command.

I am sorry to say so, but to help in this I need you to do a lot of work , I need 2x2x2x3 series of bootsectors AND MBR's:
1) Bootsector FAT16 made by HP utility+MBR
2) Bootsector FAT16 made by PEto USB+MBR
3) Bootsector FAT 16 made by FORMAT with Hitachi filter+MBR (made with Disk Management?)
same as above FAT32
same as above FAT16 and FAT32 after the WINNT32 execution

Now, ALL the above but using BEFORE 1) 2) and 3) a hex editor or a direct disk access utility like dsfo/dsfi to write hex value F6 to first 100 sectors of the stick.

jaclaz

This post has been edited by jaclaz: 06 August 2007 - 03:33 AM

[ilko_t]

Would samples only from XP format (right click on drive and format) and PEtoUSB be enough? I already have most of the files needed, just need to do it with F6 written prior to format.
PEtoUSB formats only AFAIK in FAT16 or FAT16x, would that be enough too? When stick is formatted by it boots every time, no matter when boot files are copied, or whether Hitachi driver is used or not (PEtoUSB senses the difference).

Meanwhile- any ideas about

Quote

Another question- any idea what could be the variable path for the USB stick during GUI part?
I'd like not to copy boot_ren.cmd, undoren.cmd and binifix.cmd to system32 and edit txtsetup.sif, but rather put then on stick and call them directly from the relevant entries in winnt.sif.
Could be done easily if the same letter is assigned to USB stick, but to make it universal variable path would be nice.

[jaclaz]

ilko_t said:

Would samples only from XP format (right click on drive and format) and PEtoUSB be enough? I already have most of the files needed, just need to do it with F6 written prior to format.
PEtoUSB formats only AFAIK in FAT16 or FAT16x, would that be enough too? When stick is formatted by it boots every time, no matter when boot files are copied, or whether Hitachi driver is used or not (PEtoUSB senses the difference).

Well, maybe yes, the problem might derive from the fact that, as has been reported by Dietmar on the famous Full XP on USB thread on 911CD, some utilities (NOT the HP one ) could try to interpret data already on MBR and/or bootsector.
This is has been reported for XP's FORMAT command (in other words a partition formatted with XP's tools from scratch on a blank 00's or F6's drive may be different from one created over a previously existing one, as XP's FORMAT comand may "inherit" some of the previous data).
This has been proved beyond any doubt for floppies:
http://www.denispetrov.com/format144/
but about hard disks/USB devices I have no definite proof.
So the problem might arise by a combination of the previous format with the new tool used.

ilko_t said:

Another question- any idea what could be the variable path for the USB stick during GUI part?
I'd like not to copy boot_ren.cmd, undoren.cmd and binifix.cmd to system32 and edit txtsetup.sif, but rather put then on stick and call them directly from the relevant entries in winnt.sif.
Could be done easily if the same letter is assigned to USB stick, but to make it universal variable path would be nice.

We can search for a file and set the variable to the drive where the file is found, using "binifix.cmd" or another "tagfile" just like the common "WIN51.IP" is used in Windows Setup, but still we need a minimal batchfile in %systemdrive% or in another path for which an environment variable is already established.
Try the following add this one liner (save it as CHECKVAR.CMD):

SET >CHECKVAR.TXT

put it in \System32 and add this in winnt.sif:

Quote

[GuiRunOnce]
"%systemdrive%\windows\system32\checkvar.cmd"
"%systemdrive%\windows\system32\undoren.cmd"
"%systemdrive%\windows\system32\binifix4.cmd C:"

You should get a CHECKVAR.TXT file with all Environment Variables already SET when [GuiRunOnce] is run.
We can even make a self-deleting batch, though it's a bit tricky, it can be done.

I'll think some more about this issue and see if I can come out with and idea.

jaclaz

[ilko_t]

@jaclaz

About boot sectors- please find attached what I gathered, Before and After stands for before winnt32 is run, right after format, after is after winnt32. In some folders I put a file telling how the stick boots with this bootsector. F6 folders are for stick when first 100 sectors filled with F6.

About binifix4.cmd- works fine, you may now remove YES confirmation. How would it behave if script is run for a second time? I mean for repair install, script would be already run once, and for a second time when repairing.


As for the variables- I am trying to avoid modifying TXTSETUP.SIF at all, and call boot_ren.cmd, binifix.cmd and undoren.cmd from winnt.sif directly on stick, without copying them on hard disc.
I was expecting to have a preset variable like %installdrive% or something similar, but cannot find any.

Simple way to set such for the USB drive is to use PRESETUP.CMD, which if seen by GUI Setup will be launched before anything else.
Here we have 2 options
1. Set the variable if possible- I am not in this field at all, tried to substitute SET with SETX for permanent results in simple script like this:

SET TAGFILE=\misc
FOR %%h IN (C D E F G H I J K L M N O P Q R S T U V W X Y) DO IF EXIST "%%h:%TAGFILE%" SET USBDRIVE=%%h:

Where folder MISC will be on stick, containing the files in question. Using SET works for this command prompt session only, using SETX should do it permanent, but seems the syntax is different and SETX with -m parameter works on
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

which I am not sure if it's ready at that point, before GUI setup continues.

2. My dumb and simplier way - use presetup.cmd to copy needed files in \system32 and call them easily from winnt.sif

ilko

Attached File(s)

•  MBRs_bootsects1.zip (41.01K)
  Number of downloads: 24

[jaclaz]

I'll check the bootsectors and let you know.

About re-running the batch, at first sight the only missing thing is a check for NOT duplicating the "Old Default" entry, it can be fixed allright, I'll do that and the other more general polishing as soon as I have time.

The PRESETUP.CMD appears to me an excellent idea, one could also try a POSTSETUP.CMD, as you already posted, it's not easily found info on WHEN postsetup.cmd is processed, but it seems like it is executed at the same point of GuiRunOnce:
http://blogs.msdn.com/pointofservice/
http://blogs.msdn.com/pointofservice/archi...stallation.aspx
though it seems that it is called by setuplauncher.exe:
http://msdn2.microso...y/ms912403.aspx

Check this oldie too:
http://www.msfn.org/...showtopic=12566
(could we use devicesetpath.exe?)

Or maybe we could use Fedit.exe:
http://www.msfn.org/...topic=48200&hl=
to edit WINNT.SIF on the fly?

jaclaz

[cdob]

ilko_t, on Aug 4 2007, 11:56 AM, said:

Why winnt32 changes bootsector? And what exactly it changes

That's syspart design: prepare install for another machine.

http://support.micro...kb/241803/en-us

Quote

In Windows 2000, the /syspart parameter for Winnt32.exe causes Windows 2000 Setup to copy all the necessary boot files and temporary Setup files to a drive and mark the partition as active. You can then install the drive in another computer, turn the computer on, and continue with Setup.

This goes for XP too.

Obviously winnt32.exe wasn't created for USB devices.
BIOS hard disk sort order maybe involved too.

Syspart work fine at internal drives.
C:\$WIN_NT$.~BT\BOOTSECT.DAT contain a boot sectors, string ntldr is edited.

[ilko_t]

I have tried postsetup.cmd a while ago- could't get it launched, it may be launched only in Windows Embedded setup, or I didn't make it right. Will try again. It's supposed to run when GUI setup is completed, may be after T-1 "deleting temp. files"

Fedit.exe seems good idea, I'll study it further.

@cdob- I get what you are saying, it's just a few things which doent's make any sense to me, please reread the posts above about bootsect.dat and how winnt32 with /syspart changes bootsector, rendering the stick non bootable. If stick is formated by PEtoUSB this doesn't happen.
It could be BIOS involved, that's an idea, or as you are saying winnt32 gets confused about the USB device.
It doesn't create abootsect.dat nywhere, but makes boot.ini on stick pointing to it, despite the fact TXT part will be launched by the renamed setupldr.bin anyway. Could be the part when winnt32 is not designed for USB drives and gets confused.
If it was creating bootsect.dat with a patched bootsector on the USB stick it would've been nice, one external tool (jaclaz's makeBS.cmd) less. Not a big deal though, I am just studying it's behavior and reporting results here.

Another thing- please excuse me as I sometimes use the topic as a draft, usually when I get too many results in my head and need to clear and sort it up, and at that point I write some unnecessary and not proved results and conclusions. Just noone else to talk with about this matter
Will try not to

[ilko_t]

I tried to make an easy way to prepare everything, please find attached an archive, containing all needed files, please excuse my skills in batch scripts, there is probably a lot to be improved in this simple script:

Quick how to:
1. Extract files to a folder of your choice
2. Run PEtoUSB and format stick
3. Run PREPARE.CMD, and follow prompts, pauses are added for troubleshooting
4. When notepad opens WINNT.SIF, delete the whole [unattended] section and add/amend whatever you


That's it, please test it, any feedback is appreciated.
---------------------

Could someone have a look at PREPARE.CMD and add a section to delete the whole [unattended] section in WINNT.SIF, I had no idea how to do it. Feel free to add any improvements i.e. error checking or whatever is needed to polish it, that was beyond my capabilities
Some of the batches could be merged at later stage.
For testing prepare.cmd ImDisk comes so helpful

Regards,
ilko

Attached File(s)

•  prepare_USB.zip (120.72K)
  Number of downloads: 66

[cdob]

@ilko_t
I like adding lines to TXTSETUP.SIF at a batch files.
This goes to a end user solution.

Free time: unfortunately I havn't tried hole solution yet.


I dislike possible changed boot sector still.

ilko_t said:

it's just a few things which doent's make any sense to me, please reread the posts above about bootsect.dat and how winnt32 with /syspart changes bootsector, rendering the stick non bootable. If stick is formated by PEtoUSB this doesn't happen.

Winnt32.exe goes back to NT4 times, there was no USB at all. Except some third party drivers.
Used at a not supported environment may get unexpected results.

Don't rely on a unsupported feature. You never know results.

By design Winnt32.exe /syspart makes a internal hard disk bootable.
MBR and boot sector are updated, if it is necessary.
Necessary according to Winnt32.exe rules. This rules may fail at USB.
A boot sector maybe valid by change according to Winnt32.exe rules.

The question:
Use a solution requiring a Winnt32.exe friendly boot sector?
Does all BIOS boot from a PEtoUSB boot sector?
Isn't PEtoUSB limited to FAT16?

My opinion:
A end user friendly solution dosn't require a winnt32.exe friendly boot sector.

You mentioned ImDisk already.
There are other Virtual Disk Drivers too.

What about?
create a virtual disk
winnt32.exe writes to this virtual disk
copy files to USB next

Granted, this may take longer.
But final USB stick may work at more machines.

[ilko_t]

Totally agree with you.
What I tried in the previous post is to make the steps as few as possible. The way could be always extended to meet specific needs- use HP format tool or whatever makes the stick bootable, usage of virtual disks to avoid winnt32 change of bootsector and messing with the local BOOT.INI etc.
Just need more tests to get the most simple, reliable and universal way, your remarks are always on spot. I believe Jaclaz's analysis of the attached boot sectors will give more light on what is happening and what could be done.

Here is my short "to do" list:

1. Find a virtual disk program, simple to use and not residing in RAM, but rather in a file. Manage this program by prepare.cmd to automate the process.
2. A script, deleting the whole [unattended] section in WINNT.SIF
3. Tests with USB hard disks, I don't have any bootable enclosures to play with. Issues I foresee:
-Text Setup will see it as fixed, list as first, before SATA/IDE disks, rewrite bootsector, possibly render it nonbootable(worst case)
-boot files will be placed on USB disk, instead of the local hard disk, need additional checks in binifix.cmd, for proper entries in the local boot.ini and ntdetect.com/ntldr.
-drive letters may get messed
4. Merge some of the scripts for simplicity

Some of the steps takes me a lot of studying, batch scripting is something very new to me, bootsectors/MBR structure too, and I really feel uncomfortable to ask Jaclaz every second post please this, please that, because I can't do it on my own

BTW over 50 000 hits to this thread and only 4-5 active posters
That was the other reason for the post above and prepare.cmd.

edit: 1) and 2) completed
edit2: 3) completed

This post has been edited by ilko_t: 29 August 2007 - 05:36 AM

[jaclaz]

@ilko_t
I had a preliminary view at the posted bootsectors and MBR, and I am really puzzled, as I can see no difference that can justify the booting/not booting.

Maybe after all there is nothing connected to MBR/bootsector that causes this behaviour.

I'll try building a couple of Virtual disks with those bootsectors and check them....

As cdob hinted, IMDISK, while being an exceptionally GOOD tool, is not suited to work with "full" HD images.

You'd better shift, at least for this kind of testing to Ken Kato's VDK:
http://chitchat.at.i...vmware/vdk.html
(optionally using my pseudo-GUI for it)
http://home.graffiti.net/jaclaz:graffiti.n...ts/VDM/vdm.html

You will need to use .pln file descriptors for geometry of drive, see my posts here:
http://forum.winimag...topic.php?p=938

ilko_t said:

Some of the steps takes me a lot of studying, batch scripting is something very new to me, bootsectors/MBR structure too, and I really feel uncomfortable to ask Jaclaz every second post please this, please that, because I can't do it on my own

Fell free to ask at any time , whether I can help you or not in a timely fashion it depends on the amount of free time I can set aside for this , however, the more you study and learn and the more you will see how there is nothing "magic" about anything computer related, everything can be, before or later, tracked to a cause, and (hopefully) a workaround or fix, even for the queerest of "behaviours" can be found, if only the same thing could be applied to "real" world.

jaclaz

[ilko_t]

jaclaz, on Aug 9 2007, 02:32 PM, said:

@ilko_t
I had a preliminary view at the posted bootsectors and MBR, and I am really puzzled, as I can see no difference that can justify the booting/not booting.

Could I help with anything else? Give me any ideas what I could do on my side.

jaclaz, on Aug 9 2007, 02:32 PM, said:

Maybe after all there is nothing connected to MBR/bootsector that causes this behaviour.

What else could matter for bootability? Could it be something beyond MBR/bootsector?

jaclaz, on Aug 9 2007, 02:32 PM, said:

You'd better shift, at least for this kind of testing to Ken Kato's VDK...

Thanks for it, prepare.cmd is redone, now it creates a virtual disk, formats it, makes WINNT32 to place all files there, amends the needed files and copies all on USB stick. Tested it with 2 XP sources- worked fine. A lot is to be polished, step by step. An archive containing all needed files is attached.

jaclaz, on Aug 9 2007, 02:32 PM, said:

Fell free to ask at any time , whether I can help you or not in a timely fashion it depends on the amount of free time I can set aside for this , however, the more you study and learn and the more you will see how there is nothing "magic" about anything computer related, everything can be, before or later, tracked to a cause, and (hopefully) a workaround or fix, even for the queerest of "behaviours" can be found, if only the same thing could be applied to "real" world.

jaclaz

Thanks, the information coming from you is usually like a waterfall, one can hardly drink that much at a time



edit1: _prepare.cmd updated, now deletes the whole [unattended] section in winnt.sif

Attached File(s)

•  prepare2.zip (100.98K)
  Number of downloads: 49

This post has been edited by ilko_t: 10 August 2007 - 09:33 AM

[jaclaz]

It's my turn to take a few days off-line.

@ilko_t

ilko_t said:

Could I help with anything else? Give me any ideas what I could do on my side.

Unfortunately I have no definite ideas at the moment.
I have re-checked the MBR/bootsectors you posted, and though I had no time to completely test them in VM's, I have reinforced my "feeling" that something else might be involved in the non-booting problem.
The only "strange" thing I have found is the number of reserved sectors on FAT16 formatted bootsector, 08, which is "normal" for FAT32, but that is normallly 01 for FAT16, at least on DOS and NT/2K formatted partitions, I need to try what happens under XP to make sure.
I hope to have time to do so on my portable while on vacation.
So, since the only other two things needed for booting (to an error message) are NTLDR/SETUPLDR.BIN and NTDETECT.COM, maybe there are some changes to them?
Any other missing/wrong file should generate a definite error message.
Please post the error message you got (if any) when NOT booting, it could help on pinning down where the problem might lie.

The ideas by cdob, as always , make sense, it is possible that some part of WINNT32.EXE does not "recognize" the usage of the Filter, accessing the drive directly or whatever.

Another thing you could try could be using instead of the Hitachi Filter, the dummydisk.sys driver from CodeProject:
http://www.911cd.net/forums//index.php?sho...181&st=1954

jaclaz

[ilko_t]

Have a nice holiday jaclaz, enjoy it

[iceangel89]

hi,

i am thinking of doing a boot from HDD, but yes i think some may think its a bit impossible that since i do not have much experience doing such things... but hope some1 can give me a guide here?

jaclaz, nice to see u helping me so much, but maybe its better to have "guides" instead of reading hundreds of posts... but still it helps, or try to tell me which post

This post has been edited by iceangel89: 11 August 2007 - 06:37 AM

[Legolash2o]

thx been looking for this

[iceangel89]

can some1 tell me how to do this? or which post/page has the answer?

reading through so many posts and cant seem to get anything done

[jaclaz]

iceangel89 said:

can some1 tell me how to do this? or which post/page has the answer?

reading through so many posts and cant seem to get anything done

Links to the most relevant posts (link already given, here):
http://www.boot-land.net/forums/index.php?...ic=2807&hl=
are in this post :
http://www.msfn.org/...opic=99453&st=3

Last one is here:
http://www.msfn.org/board/index.php?showto...1384&st=293


Eventually, and that means WHEN everything will be found to be working and it will be tested, ilko_t will publish a complete guide, but there is NO "road-map" established, it may happen in the next 15 days as well as in the next 15 months, this procedure is something experimental and everyone contributing to it do so in their spare time, so please, do not ask for a release date, just wait and check back once in a while or experiment with info already provided.
Check this:
http://www.msfn.org/board/index.php?showto...1384&st=273

By the way, it is rather amazing how at this moment the thread had 51,818 views and the number of people that have actually contributed or gave a useful feedback can be counted on fingers without taking one's shoes off....
To provide a solution that works on the most hardware we need some people that test the procedure on their hardware and report problems or success.

jaclaz

This post has been edited by jaclaz: 13 August 2007 - 04:13 AM

[wimb]

The automatic making of a bootable USB-stick for Install of Windows XP using prepare2.zip was tested.
Collecting files in a Virtual Disk and file editing with Fedit.exe are very handy in this approach

Fresh and Repair Install of Windows XP from the bootable USB-stick was realised successfully,
after some modifications in the _prepare.cmd file as described below:

For my version of XP it was necessary to remove the :all option in the winnt32.exe command.
Otherwise in making the LocalSource I get Error messages for missing files: tabletpc.cab and mediactr.cab

The /h /k option is not valid in the copy command, but gives no problem.

MakeBS3.cmd .... was replaced by CALL MakeBS3.cmd ....
in order to see the messages and to return to the following statements in the _prepare.cmd

It is interesting to integrate also CALL MkMigrateInf of cdob for giving the USB-stick drive letter U:
because without it the USB-stick gets the unwanted drive letter D:
and consequently the drive letters of other partitions on the harddisk are changing.

Fedit.exe was used in _prepare.cmd to make
the for the Repair option necessary change in the presetup.cmd of BTS DriverPacks.

The btinifix4.cmd was made ready for unattended install by removing the pause and the YES confirmation.

I think the automatic approach is very worthwhile and removes the previous risc of someone forgetting
to reset boot.ini after the winnt32.exe command, resulting after reboot in an unexpected install of Windows XP.

This post has been edited by wimb: 18 August 2007 - 03:12 AM

[ilko_t]

Hi wimb

Here are some results in my tests:

wimb, on Aug 18 2007, 09:59 AM, said:

For my version of XP it was necessary to remove the :all option in the winnt32.exe command.
Otherwise in making the LocalSource I get Error messages for missing files: tabletpc.cab and mediactr.cab

It's tricky, if :all is not used some folders are not copied, e.g. when preparing MCE and GUI setup will complain about missing files/folders. If it is used some files cannot be found by WINNT32 as it is looking at the wrong place for them, for example test with DELL XP Home SP2:
Here is part of TXTSETUP.SIF:

Quote

[SourceDisksFiles]
.......
startoc.dll = 100,,,,,,,32,0,0
startoc.inf = 100,,,,,,,20,0,0
startoc.cat = 100,,,,,,,,3,3
startoc.cab = 2,,,,,,_x,,3,3

Part of LAYOUT.INF:

Quote

[SourceDisksFiles]
.............
startoc.dll = 100,,22016,,,,,32,0,0
startoc.inf = 100,,109098,,,,,20,0,0
startoc.cat = 100,,167601,,,,,,3,3
startoc.cab = 2,,8672998,,,,_x,,3,3

And part of DOSNET.INF

Quote

[Files]
...........
d1,startoc.dll
d1,startoc.inf
d1,startoc.cat
d2,startoc.cab

startoc.cab is the only file, not found by WINNT32, and it's the only 1, which differs from others in it's source description. Why they did it like that I have no idea, however I'd rather make a note of the files not found and manually copy them after _prepare.cmd, than not copying whole folders (:all switch).
On generic XP SP2 situation is fine, no funny files or folders, but with different sources we can expect all kind of errors, because of the many ways OEMs integrate their stuff and WINNT32 fails to replicate the exact CD structure.

wimb, on Aug 18 2007, 09:59 AM, said:

The /h /k option is not valid in the copy command, but gives no problem.

That was xcopy before, forgot to remove redundant switches

wimb, on Aug 18 2007, 09:59 AM, said:

MakeBS3.cmd .... was replaced by CALL MakeBS3.cmd ....
in order to see the messages and to return to the following statements in the _prepare.cmd

Told you I am newb with scripts, didn't know how to avoid that Thanks.

Quote

It is interesting to integrate also CALL MkMigrateInf of cdob for giving the USB-stick drive letter U:
because without it the USB-stick gets the unwanted drive letter D:
and consequently the drive letters of other partitions on the harddisk are changing.

Here is tricky too, please read the results with USB hard disk bellow. USB stick getting C: is a good indication that something is wrong and stick will be rendered non bootable during TXT Setup because is seen as first disk- abort setup. If it's preset to U: you will not get that. Better fix drive letters later.

Quote

Fedit.exe was used in _prepare.cmd to make
the for the Repair option necessary change in the presetup.cmd of BTS DriverPacks.

The btinifix4.cmd was made ready for unattended install by removing the pause and the YES confirmation.

Would you attach the edited files please.

I also added simple check if winnt.sif don't exist on source not to use /unattend switch:

IF EXIST %instpath%\i386\winnt.sif (
%instpath%\i386\winnt32.exe /noreboot /makelocalsource:all /syspart:%tempdrive% /tempdrive:%tempdrive% /unattend:%instpath%\i386\winnt.sif
) ELSE (
%instpath%\i386\winnt32.exe /noreboot /makelocalsource:all /syspart:%tempdrive% /tempdrive:%tempdrive% 
)

If you can make it better please add it as well in the files to be attached.
-------------------------------

Some results with USB hard disk- unfortunately I couldn't make it work without deleting source files. USB hard disk is seen as first disk and gets letter C:, dispite the fact it's listed as second in list and TXT Setup attempts to place boot files on it. If it's write- protected by migrate.inf SETUP complains about damaged hard drive D:

Quote

Setup has determined that Drive D: is corrupted and cannot be repaired

Same behavior was desribed in post #130 , when in mixed SATA/IDE environment USB stick is seen as first bootable device, this was fixed by disabling IDE controllers or removing attached devices from them, but here I had only 1 IDE hard disk and the USB one.

Remove the write- protection form migrate.inf- no more complains, but all boot files go on USB disk and the files being copied to destination are deleted from source.
Make USB disk U:- same story.
Tests made with 2 different USB-IDE adapters and IDE disk as destination- same results.

Because the files deleted during TXT Setup are from ~LS folder I tried to keep ~BS for the TXT part and force Setup to look for source files in other folder- I386 copied on USB disk. This articles give some clues:
http://support.microsoft.com/kb/150497
http://technet2.microsoft.com/windowsserve...3.mspx?mfr=true

I have tried to change TXTSETUP.SIF to

[SetupData]
SetupSourcePath = "\"
SetupSourceDevice = \device\harddisk0\partition1
MajorVersion = 5
MinorVersion = 1

Also \ to \i386, with and without quotes and spaces to no avail- "Setup cannot format the hard drive- CD is damaged" meaning cannot find files on source destination. TXTSETUP.SIF is in root and in I386.

WINNT.SIF:

[Data]
Autopartition=0
UnattendedInstall="Yes"
floppyless = "1"
msdosinitiated = "0"
OriSrc = "\device\harddisk0\partition1\i386"
EulaComplete="1"
winntupgrade="no"
win9xupgrade="no"
Win32Ver="a280105"
uniqueid="C:\WINDOWS\JAL"
OriSrc="\device\harddisk0\partition1"
OriTyp="3"
unattendswitch=yes
sourcepath = \device\harddisk0\partition1\i386
floppylessbootpath=\Device\HardDisk0\partition1
[SetupData]
OSLoadOptionsVar="/noexecute=alwaysoff"
SetupSourceDevice = "\device\harddisk0\partition1"

floppyless = "1" and msdosinitiated = "0" were tried in all combinations, some funny lines were added to experiment, actually in over 20-30 attempts to change/remove lines I had no luck. No idea if it's by design like that or am missing something. May be Setup detects that has not been started from RIS ignoring paths and keeps searching for files in ~LS folder.

Another dumb idea- copied the contents of CD on USB disk, leave boot files to invoke SETUPLDR.BIN and amend WINNT.SIF and TXTSETUP.SIF(copied on root and I386) for other source paths- no luck again- BIOSINFO.INF cannot be found in ~BT folder, so it's either hard coded when booted from hard disk to search there, or I am missing something.
I am taking a break from USB hard disks for now, at least until someone gives better ideas.
May be a way to make USB hard disk seen as removable? AFAIK this could be done by using driver patching on the fly the removable bit which seems too hard for the purpose, or I am wrong?


Regards,
ilko