Another interesting for me thing- I had Bart PE minint folder on the root of the same stick, while testing I have noticed that if txtsetup.sif in root is missing or renamed, Bart PE is launched instead of TEXT mode setup. It might have been already discussed somewhere, but gives a good idea how both may coexist, without having to create second partition for it. I am going to test it further and report results.

@buseeliu- try some random shots to see why your USB stick is so slow:
1. Update your BIOS
2. Check setting in BIOS for USB, make sure USB2.0 is enabled, play a bit with the other settings for USB- legacy support etc.
3. Test the same stick on another motherboard/system, which is known to support faster speeds
4. Test on your motherboard another stick, which is known to be fast
5. Unplug all other USB devices while testing
6. Use one by one the rear USB ports, try do disconnect fron USB ports from motherboard

May be jaclaz can help you with some other ideas, hes knowledge about usb sticks is amazing

@jaclaz- Have you had a chance to look what was going wrong with MBRs?

@ilko_t

At first glance I dislike renaming $WIN_NT$ folder. Is this reliable?

Contrary no long wait at T-1: You confinced me.
I like renaming $WIN_NT$ folders. Nice solution, thanks.

BOOT_REN.CMD:
Can you backup a possible existand boot.ini?
Idea, not tested:
And can you create boot.ini dynamically?
Not a fixed \WINDOWS, extract foldername from %SystemRoot% ?

About multi boot:
Setupldr.bin seek folder minint first, $WIN_NT$.~BT next.
Hexedit \$WIN_NT$.~BT\setupldr.bin. Change minint to miniOf.

menu.lst
chainloader /$WIN_NT$.~BT/setupldr.bin
chainloader /minint/setupldr.bin

Thks for your effort again. I will try your method two days later since i am too busy currently.

Furthermore, Can i you use this method to install xp if i want to use usb notebook harddisk?

Thks for your good & professional advice.

@ilko_t
Here is what I have found:
No differences are found between BootSector_USB_Before.dat and BootSector_USB_After.dat.

Both are FAT 16 bootsectors with 63 sectors before and partition length of 3997633 sectors.

The stick appears to have a CHS Geometry of 248x255x63.

MBR_USB_Before.dat appears to be a MBR written with the "HP" utility, check this thread here for a very recent discover on how and why (maybe) the MBR written by the HP utility is different from the "standard" NT/2K/XP/2003 one:
http://www.boot-land.net/forums/index.php?...=2246&st=15

MBR_USB_After.dat is a "standard" NT/2K/XP/2003 (English).

MBR_USB_Before.dat has a 0E (FAT 16 LBA) partition ranging from CHS 0/1/1 to 247/254/63 with LBA StartSector of 63 and Numsectors 3997633.

MBR_USB_After.dat has a 0E (FAT 16 LBA) partition ranging from CHS 0/1/1 to 247/215/31 with LBA StartSector of 63 and Numsectors 3997633.

Now, in CHS->LBA translation, on a "normal" Nx255x63 Geometry, 0/1/1 is sector 63, so the StartSector in BOTH MBR's is correct.

On the contrary, both Numsectors appear to be incorrect, 247/254/63 in CHS->LBA translation is sector 3984119 thus Numsectors is 3984057, and 247/215/31 is sector 3981630 thus Numsectors is 3981568.

Going the other way round, Numsectors 3997633 correspond to CHS address 248/215/31.
(248 is a "wrong" value, as it is one Cylinder more than the total number of Cylinders that range from 0 to 247)

So, it appears that the "HP" utility defaults to the Max Cylinder, Max Head and Max Sector (247/254/63) and writes the LBA independently, whilst Windows Setup or whatever wrote the MBR_USB_After.dat gets the right End Head (215) and End Sector (31), and tops the End Cylinder to Max Cyl (247) getting 247/215/31 instead of the "theoretically coorect 248/215/31.

Some details of the "queer" way of CHS to LBA conversion and viceversa, and their effects can be found on my page:
http://home.graffiti.net/jaclaz:graffiti.n...B/USBstick.html

If you get Roadkil's Disk Image:
http://www.roadkil.net/DiskImg.html

and make an image of the stick, you will most probably find that the image has a size of 2,046,788,096 bytes, i.e. 3997633+63=3997696 sectors x 512 bytes/sector.

If you find another size, I would like to know it.

Good work with latest tutorial!

Just as a reminder, cdob's MkMigratgeInf.cmd (GOOD work) needs (of course) to be run from within a 2K/XP/2003 system. Even if I have NO idea why it could become useful, the data to build MIGRATE.INF.TXT can be found in the MBR of the stick, see here:
http://www.911cd.net/forums//index.php?showtopic=19663

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.

Of course the above would limit the amount of (possible) multi-booting capabilities of the stick, but will eliminate the need for GRLDR and menu.lst.

Also, I am not sure I have fully (or correctly) understood the need for multiple BOOT.INI entries, pointing to rdisk(0) and rdisk(1) and to partitions 1, 2 and three on them.
I am sure we can find a way to generate on-the-spot a correct BOOT.INI.
For the record, BOOT.INI has no need to be marked as System, Hidden, Read Only.

jaclaz

Should work just fine.

I spent a lot of time searching for a tool, which creates or amends properly BOOT.INI during GUI part with the correct entries, in order to avoid the brute-force way of copying generic one. Had no luck, BOOTFIX doesn't work during GUI part the way it does in Recovery Console, it works the way as in full XP environment. Couldn't find any other suitable tool for the purpose and ended up copying it from stick.
If you can get the windows directory and apply it to the generic boot.ini it would make the guide more universal. Actually ATM only boot.ini creation differs the last guide from normal setup.
Your ideas about mapping setup floppies via GRUB is nice, hopefully this can be done.

Thanks for tip
----------------

Perfect as usual
Stick was formated by PEtoUSB - MBR_USB_Before.dat
Later rewritten by TEXT mode setup- MBR_USB_After.dat, leaving some files unreadable and stick no longer bootable. If I format the same stick from XP with FAT16 or 32 I cannot boot from it.

2,046,820,352 bytes, formated by PEtoUSB as before. The only difference is that ATM I am using Hitachi microfiter driver to keep it as fixed, thus allowing me quickly to image it with Acronis TI. May be that's why it differs form your calculations?

BTW Roadkil's Disk Image v1.1 always gives me "image creation failed" with all USB sticks I have, formated by various tools, most of the time I can see progress going beyond 100%, i.e. 102, 105 and I completely stopped using it as a backup solution.


This would be nice, but is it necessary since all of the preparation is done in 2K/XP/2003 system anyway?

Yep, if we find a way to invoke setupldr.bin directly from BOOT.INI GRUB will be no longer needed. At the moment if it is called, result was restart as far as I remember, because stick at that time is initialized as hd1, perhaps newer or HEX edited versions of these files will avoid it, but that's beyond my capabilities.
I don't think patching MBR will be of any use at this stage, it should be setupldr.bin or ntdetect.com which cause that reboot. I will redo the tests and will report what may be causing reboots later.


The idea for multiple entries was to have as much universal BOOT.INI as possible, for example if one installs on different than 1st HD 1st partition. If it can be properly created that would be nice
The files are meant to be hidden and system exactly as a normal install will make them. There is no need to make them such, but it's good idea to have them, if installing it for non- technical users, which like to delete anything what they don't like or find strange, lets stay on the safe side

BTW on Dell Dimension E520 with Intel P965/G965 MB I had BSOD 7B when starting XP SP2 Setup from the same stick, right after loading drivers and showing "windows is starting". Plugging stick in diff. front/rear ports made no difference.
The fix was to use Dietmar's modified NTDETECT.COM, no more BSODs. Bart PE, based again on XP SP2 was giving the same 7B, and a full XP on another stick was freezing before loading shell. Modified file fixed them all.

@ilko_t
About boot.ini, wouldn't a good old batch file be more than enough?
I normally run Win2K, coming with experience on NT4, never used bootfix.bin in my life, just the old way with batches, here are some examples, but of course we need to modify them according to our needs, it won't be difficult once I understand what they are.
http://www.msfn.org/board/index.php?showtopic=66101&hl=

One could easily search for a "tag file" like a file that is only in %windir% on all drives, and prompt the user to confirm the entry or entries.

Just let me know which "features" are required.


Yep, that's perfectly normal, as, as seen in the case you posted, the real size of the stick differs from what is "declared" or at least from what Windows can "see".
To calculate the percentage of progress, rather obviously the programmer needs to calculate in "real time" the amount of data transferred divided by the total amount of data, the algorithm Roadkil's Disk Image uses is something like (in VERY "pseudo"code):

So, when N becomes bigger than SOURCESIZE, the number displayed becomes bigger than 100%, and it is probable that there is some check control that throws an error because the program thinks it has copied more data than available.
I would be curious about a comparison between image size results coming from the use of Roadkil's, Acronis and with dsfi/dsfo, part of the DSFOK toolkit:
http://members.ozemail.com.au/~nulifetv/freezip/freeware/
(command line, but VERY accurate, that, not having the check hypothized above, does not throw any error)

2,046,820,352 should then be the "real" size of the stick, this corresponds to the CHS end address of 248/216/31, this means that maybe, instead of "topping" to MaxCyl, the (wrong) partitioning simply takes 1 off BOTH NumCyl and NumHds.
On a different geometry, like Nx128x32, End address of 2,046,820,352 would be exactly CHS 976/0/32, i.e. a "correct" Head boundary one.
The maximum "correct" CHS address in a 248x255x63 geometry remains however 247/254/63, which leaves you with 2,046,820,352-2,039,837,184=6,983,168 bytes or 13,639 sectors not accessible/unused.


No need to patch the MBR, all the "fun" happens in the bootsector, as cdob pointed out.
If I am "allowed" to use dsfi/dsfo above, I can put together a small batch file that:
1) gets the bootsector from the stick and makes a copy of it
2) patches the copy so that it is invoking SETUPLDR.BIN
3) adds an entry in boot.ini directly chainloading the modified bootsector
I have used similar batches in the past, they work for both FAT16 and FAT32, using it for NTFS might need some more work, but the USB device is normally FAT16 (or 32) anyway, isn't it?

jaclaz

@jaclaz - what we need is a way to get the proper ARC path is it would be seen if no USB stick's BOOT.INI is used to call the GUI mode, find in what directory windows was placed in and amend or create a new BOOT.INI.

The issues I can see:
- bootcfg.exe doesn't change entries when working in this mode, it works as if run in normal XP environment. So no options to add boot entries.
- If GUI setup is called by ntldr/ boot.ini on the stick, hard disk is seen by GUI SETUP and supposedly by any suitable tool for getting ARC path as HD1, instead of HD0.
- If Grub mapping is used (hd0->hd1 and hd1->hd0) boot.ini will be created by Setup with the proper ARC path, but with a signature, which we liked to avoid. May be a script can replace the signature part with "multi", resulting in proper boot.ini? Can you do it by script?

signature(de33eaf8)disk(0)rdisk(0)partition(1)\WINDOWS ---> multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

Menu.lst in this case would be like:
restricting us to one hard disk only, if one plans to install it on another, mapping should be modified, which is a bit restricting. Thats why I preferred not to use mapping at all.
In summary: with mapping- signature part must be removed and Menu.lst amended if use more than 1 HD.
With no mapping- "universal" boot.ini must be used on both USB stick and the one we copy to hard disk.

Next few days I will be working on cdob's ideas.

BTW you mean bootcfg.exe, not bootfix.bin, right?

Cannot say, I never used it, WHATEVER it is called

Try this:

The above should have a very minimal error checking, what I would like to know is if it can work in the environment it is supposed to run, which I am not sure has all the features of a normal command prompt.

Of course, once we are sure (as we should) that the drive letter is C: and that arcpath is
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
this would even be easier :

(as said elsewhere, though "substituting" a string is the CORRECT way to go on, the QUICKER one is to rewrite from scratch the entire file, if it's a 5 liner...)

jaclaz

Looks quiet promising
I have to urgently go abroad for a week or so, as soon as I get back I will join the party.

Regards,
ILKO

Wish you have a nice trip. Waiting for your back.

In step 8, Undo_Ren.CMD Should change back to undoren.cmd in order to match Step 6

@buseeliu
Good find!
It's good to have more eyes checking, typos are so easy to go undetected.

See you soon ilko_t, be well.

jaclaz

my effort is too small actually, just want to help each other within my ability.

I think the main problem is my usb 2.0 stick is not fast enough , if i copy file to notebook harddisk through, the speed is very fast. Maybe i need to buy another high speed usb stick later. Thks for your advice.

Actually, i have tried to use notebook harddisk to install window xp by using the above method. but it fails.

If i use the above code in migrate.inf , i can't not install window xp and there is a warning message that my harddisk c:(should be the drive of the stick) has been damaged. cannot continue setup window anymore, press any key to exit.


If i use CDOB's Script, i can continue to setup window even copying temporary file to 3.5" harddisk, however when the PC restarts, there is a warning that ntldr is missing. If i copy ntldr manually to that 3.5" harddisk, i can enter ther screen of installing win xp , however , further warning message is prompt that my setup file is missing. \globalroot\hardiskvolume2\xxxx.

How can fix it? I think using notebook hdd to installing xp is faster than using flash drive. Thks for all of your effort again.

The Renaming of the $WIN_NT$.~BT and $WIN_NT$.~LS folders, and the TXTSETUP.SIF file,
using boot_ren.cmd and undoren.cmd is a very nice solution for the long-wait problem at T-1.
SetupParams executes from winnt.sif at T-9 minute stage,
and is indeed very usefull for the temporary renaming with boot_ren.cmd

There are some changes necessary in the MIGRATE.INF file !
Adding the "WriteProtect" registry entry and the [Strings] section in MIGRATE.INF are no longer needed,
because we use now Renaming instead of WriteProtection.

If the USB-stick is connected when making the LocalSource on harddisk C: ,
one can simply keep the USB-stick relevant entry for
HKLM,"SYSTEM\MountedDevices","\DosDevices\U:",0x00030001,\
in the MIGRATE.INF file produced in the $WIN_NT$.~BT folder,
note its drive letter and change the drive letter to U: as proposed in post #129 ,
instead of using MkMigratgeInf.cmd.

With MkMigratgeInf.cmd you are missing in MIGRATE.INF the registry entry
HKLM,"SYSTEM\MountedDevices",,0x00000010

Yes, boot_ren.cmd is executed at T-9.
http://unattended.msfn.org/unattended.xp/v...19/#setupparamsboot_ren.cmd is processed after first reboot.

Dosn't setup delete files earlier at textmode?
Writeprotect in migrate.inf does prohibit deleting files at textmode.

ilko_t remode HiveOEM.inf, because renaming replace this.

True, MkMigratgeInf.cmd dosn't create this line, because this line is not required in migrate.inf.

@buseeliu
Name your boot.ini. There maybe false settings.
Which hardware and partitions do you use?
Do you use a SATA hard disk?


Short notice about 2003 setupldr.bin RAM loaded idea.
I made a false assumption in the past.

Booting to recovery console (press F10 at F6 message) list 2003 setupldr.bin drive as C:
Grub4dos loaded image is not listed.

This is contrary to a 2003 setupldr.bin PE image: drive X: is used.

The WriteProtect registry entry in MIGRATE.INF is indeed essential !
Without this rule, I lost a lot of setup files from the $WIN_NT$.~LS folder.
Thank you cdob for making me aware of its function. I am sorry for the mistake, that I have made.

Inspired by one of cdob's hints, I made a small batch file to (maybe) solve the NTLDR/SETUPLDR.BIN renaming problem.

Here:
http://www.boot-land.net/forums/index.php?showtopic=2362

jaclaz

@ilko_t

Please try A updated BOOT_REN.CMD

\bootfiles is not used anymore.
Ntldr and ntdetect.com are copied from $WIN_NT$.~LS

Boot.ini is builded at boot time:
Boot.ini maybe not at %SystemDrive%: e.g. c:\boot.ini and d:\windows
If a signature line exist, boot.ini is not updated.
SystemRoot folder and partition number are read from boot.ini.
rdisk is set from 0 to 3.


Edited: Rename missed in BOOT_REN.CMD
Added: rename txtsetup.sif, $WIN_NT$.~BT and $WIN_NT$.~LS

it seems to be very interesting , i will try it after my friend lends me another usb flash drive (corsair), thks for your effort .

Hi everyone
Short and unexpected holidays are always nice and welcome




Thanks for finding, fixed now.


Have you read the red note at the end of the last guide? I think you fall in that case. Make sure your USB hard disk is NOT listed first, play a bit with the other IDE devices as described in the previous posts.


I have tested it under working XP and it works, however attrib must be used in order to access the existing BOOT.INI, in GUI mode setup I think it's already hidden/system.

Next few days I will be testing your and jaclaz's scripts and will report results.

ilko

I will try to use flash drive instead of notebook harddisk , i have use some software to test the reading/writing speed between the notebook harddisk & pqi flash drive, i find out that the reading performance is better for using pqi flash drive.

Happy you are back to "work"!

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

For a MultiBoot USB-stick combining BartPE ( minint folder ) and the Windows XP LocalSource,
I found the following solution to make BartPE boot from the minint folder, instead of launching Windows XP setup.

BartPE minint folder was installed on USB-stick using peinst.cmd.
Booting via ntldr and boot.ini using peboot.bin bootsector and peldr bootloader in root-dir of USB-stick.
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.

It is also interesting to add to the GRUB4DOS menu.lst on the MultiBoot USB-stick,
Puppy Linux (NTFS Read/Write support) and DSL Linux (Knoppix with NTFS Read only support) ,
according to the procedure described by diddy in:

http://www.911cd.net/forums//index.php?showtopic=18846

DSL Linux is booting very fast in 1.5 minute,
whereas BartPE is taking 15 minutes (My BIOS supports booting with USB 1.0 speed only).
It is clear that KNOPPIX is able to use the USB 2.0 speed already in a very early stage of the booting process !!

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

I opened old logs and found:Yes, \txtsetup.sif is the keyfile.

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

I'm currently rebuilding the entire usb stick.

Its structure will be:


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.

@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?).

@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

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.



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

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

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

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.

@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

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


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

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

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


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

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.

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

Hi porear, welcome back


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


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

Well, you missed my post here:
http://www.msfn.org/board/index.php?showto...1384&st=218

And the batch I wrote:
http://www.boot-land.net/forums/index.php?showtopic=2362
it does EXACTLY that.

Allowed are ANY 8+3 names, so you can leave SETUPLDR.BIN as is without renaming it.

(You may notice the amount of feedback I received , I guess that changing loader in bootsectors is an activity that very few people do)

About the arcpath, I am still thinking about it, the problem may lay with some "unorthodox" Partition tables, see these:
http://www.goodells.net/multiboot/editbini.htm
http://www.goodells.net/multiboot/notes.htm#10

Easiest would probably "assume" that one would use USB install just for installing XP on FIRST PRIMARY partition of FIRST harddisk, as it happens, say, in 99% of cases and operate a manual adjustement for the remaining 1% (like myself) that install to Logical Volumes inside Extended Partition or that install to a non first hard disk.

In this case the batch could ask user if he installed it to first active partition of first disk, and if answered yes write on BOOT.INI a line referencing multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

or otherwise write several lines like:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
multi(0)disk(0)rdisk(0)partition(3)\WINDOWS
multi(0)disk(0)rdisk(0)partition(4)\WINDOWS
multi(0)disk(0)rdisk(0)partition(5)\WINDOWS
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS
multi(0)disk(0)rdisk(1)partition(2)\WINDOWS
multi(0)disk(0)rdisk(1)partition(3)\WINDOWS
multi(0)disk(0)rdisk(1)partition(4)\WINDOWS
multi(0)disk(0)rdisk(1)partition(5)\WINDOWS

Another idea would be to parse the existing boot.ini lines with:
multi(0)disk(0)rdisk(z)partition(w)\windir
get the rdisk(z) value and just subtract 1 from it, leaving al the rest as is.

What do you think of this last idea, it came to me just as I was writing this post, could it work?

If yes, I think I can jolt it down in batch quite easily.....


jaclaz

Shame on me , my memory is so short, I even downloaded that script when you posted the link here, but completely forgot about it. Yesterday I was reading wimb's ideas and though "why not try this on Xp from USB?" and it worked. Apologies for the ignorance.


I think that should do the trick, we need to change only rdisk, the rest is always OK, however I am not sure what the situation will be on mixed SATA/ATA disks environment.
Mind you when preparing the script to think about a situation when another XP exist, and a second copy is being installed. In this case SETUP will preserve the old lines, will change the default line and add a new one under [operating systems], am I right? In this case will you be able to keep the old line(s) and amend just the 2 new lines?
I haven't had spare time to experiment with CHKBTINI, will do it as soon as I can, it may be just enough to fix boot.ini when run before the end of GUI part.

Already sometime ago I tried your script, but was not able to use it.

Good to hear that TXT-mode Setup can be added to boot.ini Menu and that GRUB4DOS is no longer needed.
I have tested it and everything is OK

Launching TXT-mode Setup Windows XP via boot.ini has been added
as one of the boot options in my post #5 in 911cd.net
http://www.911cd.net/forums//index.php?showtopic=20036

The MultiBoot USB-stick is becoming more and more versatile
with all the new boot options via boot.ini Menu

Regards, wimb

Well, this does not help much in correcting it (if needed ), does it?

Can you reply to the original topic on boot-land (as to not clutter this one) and tell me more about the problems you had?

I tested it on two separate machines, and it worked, but since both PC's are my own, they have very similar setups so they do not represent a good test.


@ilko_t

I'll try and see what I can come out with.
About the "already" present lines, it should not be a problem since, if I a not mistaken the "new" entry will be by default the "default" one (pardon me the pun ).
What I mean is, if on First hard disk there is already a "complex"BOOT.INI like this:


The result when modified by the new install, let's say on first hard disk, partition 3, will be:


And what the batch has to do is to look at the arcpath specified in "Default=" and change just that entry and the corresponding menu one below with same arcpath as follows:


Am I correct?
What happens with SATA drives?

jaclaz

I have used your script and was able now to use it successfully !

In Boot-land Forum http://www.boot-land.net/forums/index.php?showtopic=2362
is described the solution of the problem I had on first use of the script.

Yep, that's it.
About SATA drives- if it is a mixed environment- SATA+ATA, USB stick would be listed fisrt when hard drives are detected by TXT Setup, if one plans to install on ATA when SATA is present, SATA disk must be disconnected or controller disabled, and vice versa, if installation is on SATA and IDE (no matter CD or HD) is present it must be disconnected/controler disabled. This might be BIOS dependant.
Therefore SATA/ATA shouldn't matter for script's functionality.

ilko

Hey guys,
I've been following all the stunning progress you guys have been making here - very impressive! I had one other suggestion though, that might work. If you read uberplay's OEM guide (http://uberplay.org/Documents/oemguide3.html), it demonstrates how it is possible to use sysprep + vistaPE to install any version of windows for which a sysprep exists. Notably, it does a vista-style partitioning system I believe, then simply installs your carefully setup system - you can even integrate all sorts of drivers, hotfixes and programs very easily, and with a faster install time than nlite gives. As vista can easily be installed from a USB disc, I imagine this can? Has anyone tried this?

Wrayal

Ok, here is the tentative batch to transform rdisk(z) into rdisk(z-1)

As is, it is a bit complicated by the fact that it is written for debugging, it works with a boot.ini in the same directory as the batch, and, knowing how people love working in directories with spaces in them (why? ) provides support for them.

Once it has been tested with positive results, it could be simplified as to work with %drive%\BOOT.INI.

@ilko_t
BOOT.INI should always be on C:\BOOT.INI, whatever the hard disk(s) setup is, am I correct?

jaclaz

I have been testing binifix.cmd and got:


Is not working yet, approach is interesting, will try to find source of problem.

wimb