[ilko_t]

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?

This post has been edited by ilko_t: 29 May 2007 - 12:49 PM

[cdob]

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

copy %SYSTEMDRIVE%\boot.ini %SYSTEMDRIVE%\boot.%date%.ini  /y
xcopy %USBDRIVE%\bootfiles\*.* %SYSTEMDRIVE%\  /y /h /r /k

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

[buseeliu]

ilko_t, on May 30 2007, 02:31 AM, said:

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.

[jaclaz]

ilko_t said:

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

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

[ilko_t]

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

Can you backup a possible existand boot.ini?
Idea, not tested:

copy %SYSTEMDRIVE%\boot.ini %SYSTEMDRIVE%\boot.%date%.ini  /y
xcopy %USBDRIVE%\bootfiles\*.* %SYSTEMDRIVE%\  /y /h /r /k

Should work just fine.

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

And can you create boot.ini dynamically?
Not a fixed \WINDOWS, extract foldername from %SystemRoot% ?

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.

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

About multi boot:...

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

jaclaz, on May 31 2007, 05:36 PM, said:

Here is what I have found:....

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.

jaclaz, on May 31 2007, 05:36 PM, said:

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.

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.

jaclaz, on May 31 2007, 05:36 PM, said:

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...showtopic=19663

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

jaclaz, on May 31 2007, 05:36 PM, said:

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

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.

jaclaz, on May 31 2007, 05:36 PM, said:

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

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.

[jaclaz]

@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/...topic=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.

ilko_t said:

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.

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):

set source=source
set dest=dest
set SOURCESIZE=getsourcesizeinsectors(source)
Set N=1
:loop
If exist source\sector(N) do Copy source\sector(N) dest\sector(N) else goto :end
display progressbar(N/SOURCESIZE)
goto :loop 
:end

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.ozema...eezip/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.

ilko_t said:

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.

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

[ilko_t]

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

map --read-only (hd0) (hd1)
map --hook
root (hd1,0)
chainloader (hd1,0)/ntldrstp

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?

[jaclaz]

ilko_t said:

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

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

Try this:

 
@ECHO OFF
::fix_bini.cmd 
::Small batch to make a BOOT.INI
::by jaclaz

::The following might need to be changed:
Set drive=C:
Set windowsdir=WINDOWS
Set rdisk=0
Set partition=1

:Check
IF NOT EXIST %drive%\%windowsdir%\explorer.exe GOTO :Error

::WARNING!
::DO NOT EDIT BELOW LINES - CHANGE VARIABLES ABOVE INSTEAD
ATTRIB -H -S -R %drive%\BOOT.INI
IF NOT EXIST %drive%\BOOT.$$$ COPY %drive1%\BOOT.INI %drive%\BOOT.$$$ >NUL
ECHO [Boot Loader]> %drive%\BOOT.INI
ECHO Timeout=0 >> %drive%\BOOT.INI
ECHO [Operating Systems]>> %drive%\BOOT.INI
ECHO Default=multi(0)disk(0)rdisk(%rdisk%)partition(%partition%)\%windowsdir%>> %drive%\BOOT.INI
ECHO multi(0)disk(0)rdisk(%rdisk%)partition(%partition%)\%windowsdir%="Windows XP Professional" /noexecute=optin /fastdetect>> %drive%\BOOT.INI
::DO NOT EDIT ABOVE LINES

REM ATTRIB +H +S +R %drive%\BOOT.INI

GOTO :EOF

:Error
SET Choice=
CLS
ECHO An installation of Windows was not found on given path %drive%\%windowsdir%
ECHO the batch has not performed any action, this could lead to an unbootable system
ECHO Do you want to search for an install on another drive letter?
SET /P Choice=(Y/N)
IF /I NOT %Choice%.==Y.  GOTO :Exit
:Loopdrive
CLS
ECHO Please input another drive letter and press Enter:
SET /P Drive=
IF %Drive%.==. GOTO :Loopdrive
Set Drive=%Drive%:
GOTO :Check

:Exit
CLS
ECHO An installation of Windows was not found on given path %drive%\%windowsdir%
ECHO Exiting...
PAUSE
  

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 :

 
ATTRIB -H -S -R C:\BOOT.INI
ECHO [Boot Loader]> C:\BOOT.INI
ECHO Timeout=0 >> C:\BOOT.INI
ECHO [Operating Systems]>> C:\BOOT.INI
ECHO Default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS>> C:\BOOT.INI
ECHO multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Professional" /noexecute=optin /fastdetect>> C:\BOOT.INI
ATTRIB +H +S +R C:\BOOT.INI
  

(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

[ilko_t]

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

[buseeliu]

ilko_t, on Jun 2 2007, 07:02 AM, said:

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.

[buseeliu]

ilko_t, on May 30 2007, 02:31 AM, said:

8. Create:


BOOT_REN.CMD

CODE
@echo off

SET TAGFILE=\bootfiles
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:

xcopy %USBDRIVE%\bootfiles\*.* %SYSTEMDRIVE%\ /y /h /r /k

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

exit

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

This post has been edited by buseeliu: 01 June 2007 - 08:55 PM

[jaclaz]

@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

[buseeliu]

jaclaz, on Jun 2 2007, 10:21 PM, said:

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

[buseeliu]

ilko_t, on May 30 2007, 02:48 AM, said:

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?

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.

[buseeliu]

ilko_t, on May 30 2007, 02:31 AM, said:

Step 6

MIGRATE.INF
CODE
[Version]
Signature = "$Windows NT$"

[Addreg]
HKLM,"SYSTEM\MountedDevices",,0x00000010
HKLM,"SYSTEM\ControlSet001\Control\StorageDevicePolicies","WriteProtect",%REG_DWORD%,1

[Strings]
;Handy macro substitutions (non-localizable)
REG_SZ = 0x00000000
REG_BINARY = 0x00000001
REG_DWORD = 0x00010001
REG_MULTI_SZ = 0x00010000
REG_SZ_APPEND = 0x00010008
REG_EXPAND_SZ = 0x00020000
If you wish to preserve your USB storage drive letter use CDOB's script to create MIGRATE.INF, don't forget to add the above entries :

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.

[wimb]

ilko_t, on May 29 2007, 08:31 PM, said:

MIGRATE.INF

[Version]
Signature = "$Windows NT$"

[Addreg]
HKLM,"SYSTEM\MountedDevices",,0x00000010
HKLM,"SYSTEM\ControlSet001\Control\StorageDevicePolicies","WriteProtect",%REG_DWORD%,1

[Strings]
;Handy macro substitutions (non-localizable)
REG_SZ			  = 0x00000000
REG_BINARY		  = 0x00000001
REG_DWORD		   = 0x00010001
REG_MULTI_SZ		= 0x00010000
REG_SZ_APPEND	   = 0x00010008
REG_EXPAND_SZ	   = 0x00020000

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

This post has been edited by wimb: 04 June 2007 - 03:25 AM

[cdob]

wimb, on Jun 4 2007, 12:28 AM, said:

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

[SetupParams]
UserExecute = "%systemdrive%\windows\system32\boot_ren.cmd"

Yes, boot_ren.cmd is executed at T-9.
http://unattended.msfn.org/unattended.xp/v...19/#setupparams

Quote

The above will execute the quotes command at T-9 during setup.

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

wimb said:

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

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.

[wimb]

cdob, on Jun 4 2007, 10:35 PM, said:

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

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.

This post has been edited by wimb: 05 June 2007 - 12:36 AM

[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