[jaclaz]

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...?showtopic=2362

jaclaz

[cdob]

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

@echo off

set BootIniDrive=%SystemDrive%
SET TAGFILE=\BOOT.INI
if not exist %BootIniDrive%%TAGFILE% FOR %%h IN (Z Y X W V U T S R Q P O N M L K J I H G F E D C) DO IF EXIST "%%h:%TAGFILE%" Set BootIniDrive=%%h:
set BootIni=%BootIniDrive%%TAGFILE%

echo SystemDrive %SystemDrive%
echo BootIniDrive %BootIniDrive%
echo BootIni %BootIni%

SET USBDRIVE=
SET TAGFILE=\$WIN_NT$.~LS
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:
echo USBDRIVE %USBDRIVE%

for %%a in (ntldr ntdetect.com boot.ini) do attrib -r -s -h %BootIniDrive%\%%a
copy %USBDRIVE%\$WIN_NT$.~LS\I386\ntldr %BootIniDrive%\ /y
copy %USBDRIVE%\$WIN_NT$.~LS\I386\ntdetect.com %BootIniDrive%\ /y

ren %USBDRIVE%\txtsetup.sif txtsetup.bak
ren %USBDRIVE%\$WIN_NT$.~BT WIN_NT.BT
ren %USBDRIVE%\$WIN_NT$.~LS WIN_NT.LS

call :createBootIni

goto :eof


:createBootIni
(echo [boot loader]
echo timeout=10)>%BootIni%.new

for /f "tokens=1-9* skip=2 delims=(=)" %%a IN (%BootIni%) DO (
  if %%a.==signature. (del %BootIni%.new & goto :eof)
  if %%a.==default. echo %%a=%%b^(%%c^)%%d^(%%e^)%%f^(%%g^)%%h^(%%i^)%%j >>%BootIni%.new
)

echo [operating systems] >>%BootIni%.new

for /f "tokens=1-10* skip=4 delims=(=) " %%a IN (%BootIni%) DO (
  if %%a.==multi. (
	echo %%a^(%%b^)%%c^(%%d^)%%e^(0^)%%g^(%%h^)%%i=%%j rdisk^(0^) %%k >>%BootIni%.new
	echo %%a^(%%b^)%%c^(%%d^)%%e^(1^)%%g^(%%h^)%%i=%%j rdisk^(1^) %%k >>%BootIni%.new
	echo %%a^(%%b^)%%c^(%%d^)%%e^(2^)%%g^(%%h^)%%i=%%j rdisk^(2^) %%k >>%BootIni%.new
	echo %%a^(%%b^)%%c^(%%d^)%%e^(3^)%%g^(%%h^)%%i=%%j rdisk^(3^) %%k >>%BootIni%.new
  )
)

(echo.
echo [debug]
echo SystemDrive %SystemDrive%
echo BootIniDrive %BootIniDrive%
echo BootIni %BootIni%
echo USBDRIVE %USBDRIVE%
)>>%BootIni%.new

type  %BootIni%.new

copy "%BootIni%" "%BootIni%.%date%.txt" /y
copy "%BootIni%.new" "%BootIni%" /y

goto :eof

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

This post has been edited by cdob: 11 June 2007 - 11:51 PM

[buseeliu]

cdob, on Jun 11 2007, 03:39 AM, said:

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

[ilko_t]

Hi everyone
Short and unexpected holidays are always nice and welcome

buseeliu, on Jun 2 2007, 03:42 AM, said:

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

Thanks for finding, fixed now.

buseeliu, on Jun 3 2007, 11:01 AM, said:

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

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.

cdob, on Jun 10 2007, 08:39 PM, said:

@ilko_t

Please try A updated BOOT_REN.CMD...

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

[buseeliu]

ilko_t, on Jun 16 2007, 05:30 AM, said:

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 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.

[jaclaz]

ilko_t said:

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.

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

[wimb]

cdob, on May 30 2007, 11:30 AM, said:

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

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...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 !!

This post has been edited by wimb: 17 June 2007 - 12:50 AM

[cdob]

wimb, on Jun 16 2007, 09:23 AM, said:

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]

Biohead, on Jun 22 2007, 08:35 AM, said:

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

This post has been edited by jaclaz: 22 June 2007 - 04:19 AM

[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.

This post has been edited by Biohead: 22 June 2007 - 10:23 AM

[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]

cdob, on Jun 10 2007, 08:39 PM, said:

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

jaclaz, on Jun 16 2007, 09:13 AM, said:

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]

ilko_t said:

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.micro...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

This post has been edited by ilko_t: 01 July 2007 - 01:34 PM

[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

Quote

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.