How to boot/install from USB key ?

[cdob]

peldr seeks txtsetup.sif first in root directory, in minint folder next.

Hexedit peldr using TinyHexer. Change in peldr the first occurrence of txtsetup.sif in notsetup.sif

Now BartPE will boot from minint folder and will not use WinXP txtsetup.sif from root directory.

Thanks for correcting. Sorry, bad message from bad memory last time.

I opened old logs and found:

U:\minint>gsar -o -s:000txtsetup.sif:000 -r:000txtsetup.off:000 setupldr.bin
setupldr.bin: 6 occurrences changed

Yes, \txtsetup.sif is the keyfile.

[Biohead]

Great work to all involved.

Is there anyway to get this working for XP Media Center edition? When I've tried it, it just installs XP Pro and none of the media center components, nor any of my additional programs after installation of Windows.

It did not install IE6 or WMP10 either. I upgraded to IE7 and that still was not present after installing, and WMP11 would refuse to install saying I needed Unsupported Operating System. I did make a mistake with undoren.cmd - would this have caused this problem or is this an unrelated problem?

[jaclaz]

Great work to all involved.

Is there anyway to get this working for XP Media Center edition? When I've tried it, it just installs XP Pro and none of the media center components, nor any of my additional programs after installation of Windows.

It did not install IE6 or WMP10 either. I upgraded to IE7 and that still was not present after installing, and WMP11 would refuse to install saying I needed Unsupported Operating System. I did make a mistake with undoren.cmd - would this have caused this problem or is this an unrelated problem?

No, if you somehow "skipped" the run of undoren.cmd the only effect is that you have on your stick the two "install" directories mis-named, so you will not be able to run a second install from the stick.

What you report appears to me more like something missing in txtsetup.sif or however in a similar file that lists all added components for Media Center.

Are you positive that you used as base the correct txtsetup.sif?

Maybe you can use some of the info here:

http://www.msfn.org/board/Windows_XP_2003_...ion_t61070.html

jaclaz

Edited June 22, 2007 by jaclaz

[Biohead]

I'm currently rebuilding the entire usb stick.

Its structure will be:

$OEM$\
$WIN_NT$.~BT\
$WIN_NT$.~LS\
cmpnents\
DOCS\
DOTNETFX\
I386\
SUPPORT\
VALUEADD\
Autorun.inf
Boot.ini
grldr
menu.lst
ntdetect.com
ntldr
README.HTM
README.TXT
Setup.exe
Setupldr.bin
SETUPXP.HTM
txtsetup.sif
WIN51
WIN51IP
WIN51IP.SP2

I wasn't sure what to do with folders on my install disc as it doesn't mention, so I put them on the root of the stick as above (I can afford the space). Is there anything extra I have to do to these folders? I pretty much followed the guide on page 10 of this thread by ilko_t.

Once I've finished rebuilding, I'll reinstall it all again and see whats missing then repost.

UPDATE: It still does exactly the same thing. Its missing IE6, WMP, Windows Messenger, Media Center, Outlook Express. It does not install the Royale theme (the MCE theme) and is the standard Blue Luna.

Edited June 22, 2007 by Biohead

[Biohead]

@jaclaz: Where should I have gotten the txtsetup.sif from?? I originally got it from one of the WIN_NT folders as the guide states. Am I best off getting it from the i386 folder (or wherever it is usually located?).

[jaclaz]

@Biohead

As I won't touch MediaCenter with a three feet long stick (though shorter of the five feet one I currently use to NOT touch VISTA ) I only supposed that the additional components you find missing are not specified in the txtsetup.sif you used.

Maybe, when you create the two bootfolders, a "reduced" file is generated?

Just check what differences are (if any) between the one on stick and the one on CD you already installed from succesfully.

jaclaz

[ilko_t]

@ilko_t

Please try A updated BOOT_REN.CMD

Tested it with both mapping and no mapping, result is a "proper" boot.ini, however no copy of the original file is present, just bootini.new, which is exact copy of the final boot.ini. I would prefer to set the attributes of the 3 files on the root at the end of the script.

With mapping signature must have been present, in my test both ways ended up with the same boot.ini, haven't checked though whether signature was used, but should have been.

In my "bootsector renaming" script there is a re-usable (clever? ) routine that checks the attribute status of BOOT.INI, whatever it is, does the needed changes and re-applies the same attributes.

jaclaz

Jaclaz, there is a lot more of "usable" ideas in that script, but unfortunately (for me) I cannot make use of it, due to general lack of capabilities in this field

The first script you made for creating boot.ini works fine too.

Is there any way to get the proper arcpath and amend or create a new boot.ini according to it?

Something like:

1. Scan for windows installations and get their arcpath

2. Find a marker file, which is present only in prepared for GUI part partition, and set this partition default

This will simulate pretty much the function of bootcfg command, which we need.

@Biohead have a look also at differences in both winnt.sif files, can you also post the folder structures on the CD and the USB stick?#

Regards,

ilko

[jaclaz]

Is there any way to get the proper arcpath and amend or create a new boot.ini according to it?

Something like:

1. Scan for windows installations and get their arcpath

2. Find a marker file, which is present only in prepared for GUI part partition, and set this partition default

This will simulate pretty much the function of bootcfg command, which we need.

I don't seem to remember any simple way to get arcpath, but I'll look into the matter, maybe we can get something from the Registry....

jaclaz

[AlexTitov]

Greetings and thanks to jaclaz and porear who started that work, to ilko_t who joined later, to cdob who added drops of spices (as wise advices in right moments) and to Halfwalker who started that topic

I found out that MsDosInitiated parameter influences $WIN_NT$.~?? directories deletion.

I.e. if you change \windows\system32\$win_nt$.inf file this way before GUI portion of setup:

\windows\system32\$win_nt$.inf

[s]msdosinitiated = 1[/s]
msdosinitiated = 0

then $WIN_NT$.~?? directories will not be deleted after setup.

So you may avoid directory renaming.

Though read-only stick protection is still necessary: I failed to use that msdosinitiated trick for text portion of setup Windows refuses to search for files at hdd and asks for setup cdrom.

[jaclaz]

@AlexTitov

Good find!

Another little step towards perfection.

@all

About the arcpath thingy, I had a look but it is not an easy thing at all.

What we actually need would be the behaviour, under Recovery Console, of the

map arc

command, which is very fast and has an output which is something like:

C: FAT32 500MB multi(0)disk(0)rdisk(0)partition(1)
D: FAT32 800MB multi(0)disk(0)rdisk(0)partition(2)
E:					  \Device\CdRom0

I tried a few of the (less known) utilities that come with XP, but could not find any that gave the wanted results in an easily "parsable" form.

The only one that gave good results is the dmdiag.exe that comes from the Resource Kit (but that is downloadable) as either "Windows XP Service Pack 2 Support Tools":

http://www.microsoft.com/downloads/details...61-BA8011FABF38

or as dmdiag.exe (this is the W2K tool, but should work as well):

http://support.microsoft.com/kb/927229/en-us

that outputs all the symbolic names of various disks and partitions, i.e. info enough to recreate an arcpath.

Still there is the need to test it's output, unlike, as I did, on a normal working system, in the possibly "reduced" environment in which it is expected to re-create the arcpath.

Another possibility could be some clever working with the output of diskpart, but again one has to check if it works when we need it, and the parsing is definitely not easy.

I am still loking for some small nifty third party utility that may be easier to use, so please, if any one has ANY idea, post it to the thread.

jaclaz

[ilko_t]

I have found a small utility, which does pretty much the job we need- CHKBTINI, which comes with 16 and 32bits versions. I have just tested it and it works fine, however with very limited options.

It can fix only errors or discrepancies in rdisk(X)partition(X), if multi(X), disk(X) are wrong or signature part is present it cannot fix it, but these parts are created properly anyway and signature is avoided by not using mapping.

In summary- using direct chainloading creates boot.ini like

multi(0)disk(0)rdisk(1)partition(1)\WINDOWS

and the utility fixes it to:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

when launched during GUI part. If only 2 lines are in boot.ini- default and under "operating systems" it changes both lines, if there are more than 1 line under "operating systems" it changes only "default" line. On the test system it works just fine, but on my working system it cannot find the windows partition, listing it as NON-NT PRIMARY PARTITION and skips it, 1 NTFS primary partition which is active with NT boot sector, and 3 NTFS logical partitions, I need to test why it skips it. BOOT.INI can be system/read-only, it's not a problem.

A little drawback, if a proper boot.ini is present and no mapping is used TXT Setup may not see windows installation to be repaired, I'll test this further.

@AlexTitov- welcome and thanks for info.

Idea- $win_nt$.inf could be changed during GUI part, lets say by a script, launched at T-9 instead of boot_ren.cmd, will jaclaz or cdob create something to test with?

ilko

Edited July 1, 2007 by ilko_t

[jaclaz]

Interesting.

For the record, the "multi" syntax is a derivative of the "scsi" one or whatever, in any case,

multi is ALWAYS multi(0)

and

disk is ALWAYS disk(0)

reference:

http://support.microsoft.com/default.aspx?...b;en-us;q102873

MULTI(X) Syntax

The MULTI(X) syntax of the ARC path is only used on x86-based computers. In Windows NT version 3.1 this path is only valid for IDE and ESDI drives; in Windows NT version 3.5, 3.51 and 4.0 it is valid for SCSI drives as well.

The MULTI() syntax indicates to Windows NT that it should rely on the computers BIOS to load system files. This means that the operating system will be using interrupt (INT) 13 BIOS calls to find and load NTOSKRNL.EXE and any other files needed to boot Windows NT.

The X, Y, Z, and W parameters have the following meaning:

• X is the ordinal number of the adapter and should always be 0 (see the text below for the reason).

• Y is always 0 (zero) if the ARC path starts with MULTI(), because MULTI() invokes the INT 13 call as described above and therefore does not need the DISK() parameter information.

so THAT is not the problem.

However, if we define a "standard" for our install, it can be done in batch, no problem, it is when there are multiple \WINDOWS directories on different partitions that the problem might be tricky to resolve, though I am not yet done with this....

jaclaz

[porear]

Hey guys! Sorry for a slightly OT post, just wanted to say hi and I am excited by your success. I have not been on here in a while, the new little man in our house has obviously changed our lives quite a bit. I am looking forward to finding some time to try out the ilko_t method, thanks very much to you and cdob, and of course jaclaz, who has been an excellent mentor in this whole process.

[jaclaz]

Hey, porear,

glad to see you are still around.

Congratulations to you and Mrs. porear, for the contribution to the world population (much more important than your however notable contributions to finding a way to install XP from USB).

jaclaz

[ilko_t]

Hi porear, welcome back

...If I get it right, with this latest one, since there is no drive "exchange" grub4dos is only needed to chainload setupldr.bin.

If you think it might be of use, I could follow cdob's idea and get from the FAT12 bootsector of the first of the install floppies the code for invoking setupldr.bin instead of NTLDR and prepare an easy way to patch any FAT16 or FAT32 bootsector (for NTFS it might prove to be tricky).

We could use a NTLDR and add to it an entry to direct chainload such a patched bootsector....

The idea came from this post of yours and wimb's posts in 911cd.net about loading io.sys via boot.ini.

Saved a copy of USB stick bootsector with HDHacker, hexedited it and changed NTLDR to STLDR, saved it on stick as bootsect.dat, rename setupldr.bin to stldr, add in boot.ini

c:\bootsect.dat="TXT Setup"

TXT mode worked just fine, GRUB is no longer needed, unfortunately the new boot.ini on the hard drive gets multi(0)disk(0)rdisk(1)partition(1)\WINDOWS, I was hoping that when started directly by setupldr.bin that may change the order, but no, modification is still needed.

Regards,

ilko