@jaclaz

I like rdisk(z-1) idea.
This should work in most cases. Tests have to follow.
Strange BIOS, like wanderer's BIOS, may get different results.

I changed one line at binifix.cmd.
Signature compare Post #34
http://www.msfn.org/board/index.php?s=&...st&p=585105
Dosn't signature() contain rdisk(0) already?
Do we habe to change a signature() line?

Nice, your code is already fail safe
Yes BOOT.INI should always be on C:\BOOT.INI, but it isn't always in real life.
Please read Post #220, boot.ini is seeked at %SystemDrive%. If this fails, drive letters are seeked in decending order.
This support more cases. Of course this may fail at strange machines.
Given a default MS MBR: How to detect the drive letter of primary active partition?

Can you backup a existing boot.ini as e.g. boot.bak?
%date% from Post #220 was a bad idea. This may fail at different languages.

The line to SET Timeout requires also to be changed by adding /I


But then binifix.cmd does its job OK

Due to delims== the EntryDesc misses the last part =optin /fastdetect

@cdob
@wimb

Good work in bug finding guys!

I'll try and fix the reported misbehaviour of the batch.

@cdob

Yes, I just added the signature(aabbccdd) syntax as a "proof of concept" that the "logic" in the batch can be adapted to ANY situation, you are right, we can get rid of it in "final" release.

About drive letter, I give as assumed that boot.ini is on the root of the drive, I wasn't sure that, at the time when the batch needs to be run, %systemdrive% represents correctly the latter (and I am still NOT convinced of it, I know I am a bit tough ) but as I usually, and from immemorable time, install Windows NT/2K/XP in extended partitions, %systemdrive% does NOT represent the BOOT drive.
I had gathered from the thread that the "definitive" boot.ini is ALWAYS on C:\, boot drive, i.e. First Primary Active Partition of First Hard Disk, no matter where windows is installed, I would like to have a confirm of that, otherwise I think we need to use the batch passing to it a parameter.


No problem if I can access the DosDevices key of the Registry, what I am not sure about is if at the time the batch is meant to run the Registry is accessible (I suppose not) and if the proper entry has already been written to the key.
But, as said, if NO other "strange" setting has been applied, First Primary Active Partition of First Hard Disk, should always be C:\, maybe I can add the drive letter as an optional parameter for the batch (if not supplied willl default to C: )

No prob in adding a BOOT.INI -> BOOT.BAK feature, nice (and safe) idea.

@wimb
Can you post an example of line where the "=" sign is used on the left of the "main" "=" sign for description?
Also, are there any cases where more than one "=" sign is used (besides the "main" one)?

I guess I can modify the "tokens=1,2" "to tokens 1,*" or "tokens 1,2,3", but I need one (or more) example(s) to test the behaviour.

jaclaz

Good job .
Script could be run at first logon via [GUIRunOnce] along with undoren.cmd, when folders on stick are renamed back to ~LS and ~BT, so it should be OK.

I modified the script so that the EntryDesc includes the last part =optin /fastdetect



This works for simple boot.ini but the script needs more adjustment for boot.ini of BOOTFILES folder
or other complex boot.ini

@wimb
This should work as well, takes into account multiple (if any) "=" but the main one, and is a bit more simple :




Please do post some examples of these boot.ini's so that I can adapt the code.

@ilko_t
Ok, I'll see what I can do with the Registry thingy.

jaclaz

The second part of the script needs also some adjustment


A problem occurs when trailing spaces are present in the !DefaultEntry! string.
This occurs for the boot.ini in folder BOOTFILES
The traling spaces must first be removed.

@wimb
Hey, I don't want to seem unfriendly, I am not, and at times I am also an extraordinarily friendly guy , but when one asks (I guess politely) for something, like:


and:


One expects two kinds of replies:
#1: Yes, here are the examples required.
#2: No, I will never post what you required.
(and all possible variations of the above)

Quite frankly telling me HOW I should correct a batch file I wrote, because it does not work with some entries of which I have not (and asked for twice) any example is a bit trying for my otherwise good manners.

However, should I have failed in explaining this before, can you please post some examples of boot.ini files that do not work with the tentative batch I posted?

jaclaz

@jaclaz


As fas as I know there is no boot.ini example with a line where the "=" sign is used on the left of the "main" "=" sign for description.

The standard boot.ini of Microsoft is a case where more than one "=" sign is used (besides the "main" one)


In my posts #255 and #257 I indicated that the script does not work for the well known boot.ini of folder BOOTFILES
that we all use in the procedure for Install of Windows XP from a bootable USB-stick, as reproduced here:

7. Create a folder BOOTFILES in USB stick root, and copy NTDETECT.COM, NTLDR and create there your custom BOOT.INI, which will be copied on hard disk later, during the first logon. Set them system, hidden and read-only in advance.

BOOT.INI
CODE
[boot loader]
timeout=15
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="XP Professional 0 1" /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP Professional 0 2" /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="XP Professional 0 3" /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="XP Professional 1 1" /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(1)partition(2)\WINDOWS="XP Professional 1 2" /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(1)partition(3)\WINDOWS="XP Professional 1 3" /noexecute=optin /fastdetect

It is not easy to find, why the script does not work for this paticular boot.ini
But when you select the boot.ini you can see there is a trailing space in the line with the entry default.
It is this trailing space which causes the problem,
because it becomes part of the seach string !DefaultEntry! used to determine EntryDesc according to:


Due to the trailing space, the search gives no valid result for EntryDesc

When I was writing this result in my post #257, your post #256 was not yet on my screen visible,
but came up after submitting the post. So this explains why I missed your request at that time.
But anyway I indicated in my posts #255 and #257 that the script does not work for the well known
boot.ini of folder BOOTFILES.

@jaclaz
Assumption was: If %systemdrive%\boot.ini exist, this indicate "definitive" boot.ini.
If %systemdrive%\boot.ini dosn't exist, but C:\boot.ini exist, use C:\boot.ini.
Assumption was not: %systemdrive% contain boot.ini.

A logical partition dosn't cotain a d:\boot.ini by default.
Of course there can exist a c:\boot.ini and a d:\boot.ini.
Assumption will fail at this case.

And there can be several primary partitions.
Each primary partition can hold a different boot.ini.
Assumption may fail too.

Assumption c:\boot.ini is fine in most cases.

Contrary the "definitive" boot.ini is not always on C:\.
Remember the RAM loaded install solution: Primary Active Partition of First Hard Disk got D:
What about several internal hard disk including internal card readers?
I recall another windows installation was not at c: Sorry I don't remember details anymore.

Given a grub4dos MBR, "definitive" boot.ini can be at diferent drive letters.
Contrary most likely after Windows installtion, there is a default MS MBR.


Textmode setup write a false rdisk(), first reboot fails.
Batch should run at end of textmode setup.

@ilko_t and wimb
Dosn't this replace bootfiles\boot.ini?
Call jaclaz's batch at [SetupParams] UserExecute = "%systemdrive%\windows\system32\boot_ren.cmd" ?


@jaclaz
Just wondering: Rename %SysteDrive% early at installation?
Currently I don't know if this is useful, but maybe I need this one day.
At end of textmode setup:
What happens if DosDevices key in Registry is chaned from c: to d:, or from d: to c: ?
E.g. is there full path to Userinit.exe already?
Compare http://support.microsoft.com/kb/249321/

@all
Please find attached a 2nd tentative version of the batch file.
Unlike the first version, this will ONLY work with a BOOT.INI on root of a drive (or in a path without spaces in it)

Solved three problems:
1) one or more "=" signs on the right of the "main" one
2) one or more leading or trailing spaces in entry or entry description
3) empty lines

Added backup feature for original BOOT.INI, saving a maximum of three versions.

@cdob
I'll look at your suggestions, I have not yet a complete and definite idea on how to find the right drive.

There is a key in Registry:
HKEY_LOCAL_MACHINE\SYSTEM\Setup\SystemPartition
where this values are set:
"SetupType"=dword:00000000
"SystemSetupInProgress"=dword:00000000
"CmdLine"="setup -newsetup"
"SystemPrefix"=hex:c2,0b,00,00,00,40,3f,20
"SystemPartition"="\\Device\\HarddiskVolume1"
"OsLoaderPath"="\\"

Though illogical as it may seem, the "SystemPartition" actually appears to represent the "Boot" partition, as opposed to %SystemRoot%.

"\\Device\\HarddiskVolume1" is a "symbolic" link for which I have not found (at least yet ) a way through pure batch and through "normal" XP included command line tools.

One could however use the vlm.exe utility (part of the DSFOK toolkit) to "couple" this link to actual drive letter.

Otherwise we are back to "square 1" with DMDIAG.EXE.

I would greatly prefer to only use "standard" tools, so any idea is welcome, maybe this is possible through a .wbs script?

jaclaz

P.S.: Please someone have a look at this batch:
http://www.robvanderwoude.com/bootdrive.html
(I have not handy a XP machine right now)
Does this return "System" or "Boot" drive?

The version of binifix2.cmd will not yet be able to replace the use of bootfiles\boot.ini
because then the signature problem with 20 sec bootdelay described in my post #141 will return:


Also the availability of the Repair Install option of Windows XP Setup from a bootable USB-stick
still requires such a multi-entry boot.ini
But in most cases one does not need this Repair Install option and one can change boot.ini if needed.

Actually I had no problem with the value of rdisk.
The GUI-Phase of Setup always made the correct value of rdisk(0) in boot.ini
For me the problem was that the default entry was set to signature(87538753)... entry, which gives bootdelay.
So I am a bit confused about the purpose of the present binifix.cmd

[SetupParams] runs at T-9 and that seems a suitable moment to use binifix.cmd, but I am not sure.
I remember that ilko_t observed that boot.ini is changing many times during setup.
Testing of the final version of binifix.cmd will be necessary to determine if this moment is right,
or that we use [GuiRunOnce] at First Logon.

@jaclaz
After changing drive W: into C: the binifix2.cmd was tested on two boot.ini files
All boot.ini files were modified correctly and the problem of trailing spaces is solved.
It is nice that a backup of boot.ini is made now as well.
After some modification for unattended use,
it will be interesting to use the final version of binifix.cmd in a real Install of Windows XP from bootable USB-stick.

@wimb

Could not the batch file provide a way to automatically get rid of the signature(aabbccdd) line of your post #141?

If I get it right, that line gets the correct rdisk(z), and as so it would just be a matter of replacing signature(aabbccdd) in the lines with multi(0).

As "normally" there are no entries with signature(aabbccdd) syntax in boot.ini, if one is found it should always be the one created by the install.

Just to be on the safe side one could just correct the default entry and duplicate the [Operating Systems] one, leaving one entry with the multi(0) and one with the signature(aabbccdd) syntax that could be manually selected in case the "direct" one, for any reason, won't boot.

jaclaz

The present binifix2.cmd does not change the signature entry, it only changes rdisk(1) in rdisk(0)

You are perfectly right that rdisk(0) need not to be changed for me and that it will be just a matter of replacing signature(aabbccdd) in the lines with multi(0) .
It would be very nice if the binifix2.cmd can be a way to change that.

For the [Operating Systems] I got two lines which became equal after I changed signature(87538753) in multi(0),
so I removed the "double" one. That seems to me always save for a new install,
but for a Repair Install your save solution can be interesting.

But it might be that in the configuration of ilko_t with SATA drives it is different,
but I think he will comment on that.

@wimb

Please try the attached binifix3.cmd

Changes:
1) Replaces (if Default entry)
signature(aabbccdd)disk(0)rdisk(z)partition(w)\windir
with:
multi(0)disk(0)rdisk(z)partition(w)\windir
Both in default entry and in [Operating Systems]
2) Writes original entry in [Operating Systems]:
signature(aabbccdd)disk(0)rdisk(z)partition(w)\windir="Some description" /some parameters
modified as follows:
signature(aabbccdd)disk(0)rdisk(z)partition(w)\windir=(signature) "Some description" /some parameters

This should cover all cases , I guess that the user that uses this "experimental" way will be able to delete the (signature) entry from boot.ini manually once the new "default" one has proved to be working.

jaclaz

P.S.: Just found a smaller problem in binifix3.cmd
Removing the attachment, will re-add it later, as soon as I fix it.
OK, now it should work.

I am sorry to say, but I have made a mistake.

Today I made a Fresh Install from USB-stick without the xcopy command for bootfiles folder with boot.ini

The boot.ini that was produced by the Install procedure is given:


As you can see there is no longer a signature entry and I have now also to correct the rdisk(1) to rdisk(0)

I was not aware of this change caused by the renewals that the Install Procedure has undergone.
I never saw this before because I was always using the procedure with the xcopy of bootfiles folder included.

So the signature and bootdelay problem no longer exists and we can return to the code of binifix2.cmd
And that means indeed that your code can replace the use of the xcopy of bootfiles\boot.ini
as cdob already suggested.

The effects of different Booting procedures are complicated and sometimes not to be foreseen.
I must apologise for the confusion that I have made.

No need whatsoever to apologize, your contributions have been and are of the max importance.

However, since the binifix3.cmd has the same functionalities of binifix2.cmd, one could stay with it, just in case some other user, with different/strange BIOS or something else, should come out with a signature(aabbccdd) entry in boot.ini.

jaclaz

binifix3.cmd was tested on the 4 different boot.ini files and everything is OK !

Thanks

wimb

Hi guys,
let me remind you this post of mine, which kinda summarizes the options about boot.ini:



I'd like to avoid GRUB mapping, now we can also directly invoke setup by modified bootsector, meaning no GRUB at all.

If the batch file, which subtracts rdisk value is used wimb is right, this installation won't be seen as available for repair. To include this situation as well may we add an option to the batch script, something like:

would you like to include an entry for repair from USB?
If yes- leave the original entry with rdisk(z) and may be rename it to something like "only for USB repair, do not use to boot", change the default line to rdisk(z-1), and add the line with rdisk(z-1) under [operating systems]. If no- do not leave the old entry, just use the script we already got.
My idea about the choice is to leave boot.ini as simple as possible if one prefers, what do you think?

Folder bootfiles is no longer needed.

I can't recall and can't recreate the problem when on some installations the bootfiles didn't go to hard disk's first active partition, may be at that setup USB stick was seen as such during that stage of setup, and it placed or tried to place them on stick's root. To be on the safe side then I decided to copy them to hard disk anyway, this may not be necessary. It might have been when mixed SATA/IDE disks were used, now we know how to avoid the issue. For now I think we don't need to copy bootfiles again, also the script we are going to use assumes boot.ini is present on hard disk, which means ntdetect.com and ntldr will be there too.
The SATA disks should be no issue if no IDE drive/controller is present or it's disabled.

I am away for 2 weeks and as soon as I come back to my PC will make final tests and write an updated guide, I believe what we have gives us now pretty much "universal" way to install and repair XP from USB stick.

BTW have anyone tried this guide for USB hard disk? If I am right the USB disk should be seen as fixed, therefore listed first when TXT SETUP searches for disks, if that's the situation then we might need to go back to bootfiles folder or back to the option to create brand new boot.ini and copy ntdetect.com and ntldr, also a backup and later restore of boot.ini on USB disk might be needed.

Regards,
ilko

No prob, I'll add the option to keep the "USB Repair" entry in the batch.

Just an abstract idea, mind you, but we could make a second batch to "clean" the BOOT.INI from the signature(aabbccdd) and "USB repair" option entries on second boot, i.e. once the user is certain that the procedure worked.


You are right, I'll add this check to the batch.



Have fun and relax.


I am not sure I fully understand this last part, but I think that if anything changes between USB stick and USB Hard Disk, we can make a detection in the batch for the type of media and have a conditional execution of different instructions.

jaclaz

Hallo Ilko,

You described already very well how the occurrence of signature entry and the value of rdisk in boot.ini depend on the way of booting the USB-stick. Thank you for reminding me of your post #207.
I learned a lot again about Booting USB-sticks these days !

I wish you a pleasant vacation.

Is there any chance of writing an updated (read: final) guide for this?

And still cannot get MCE components, nor IE, nor WMP, nor Windows messenger to install on a preactivated OEM XP MCE install.

If anyone wants to eliminate the need to use third party software to format their USB drive, you can do this....

Visit http://www.xpefiles.com/viewtopic.php?t=92 and download the hitachi drivers.

Effectively, after install, your stick will be seen and treated as a regular hard drive. This way you can format and partition the Stick with the Windows manager, creating primary and extended/logical partitions, creating an xp MBR.

After downloading extract the contents. Open cfadisk.inf and note the following section, we will need to edit this in a moment.....



Find and add the ID specific to your usb stick. To find this insert your USB stick and use REGEDIT navigate to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USBSTOR registry key

There will be an entry for the subkey HardwareID. Open this and there will be a string of values - for my PMY stick the values are:


We only need to use the first value in the HardwareID string - in this case, for mine, USBSTOR\DiskPNY_____USB_2.0_FD______PMAP. Copy this value into the [cfadisk_device] section in cfadisk.inf. So for eg, my [cfadisk_device] section contains the following code:


Save cfadisk.inf. Open Device manager and check for your USB drive in "Disk Drives". Right click on the entry for your drive and select option to update driver.

* Don't use windows update
* Install from a list or specific location
* Don't search for driver, but use....I will choose the driver to install
* Have disk
* Browse to location of edited cfadisk.inf

Update and restart windows. Your USB stick should be treated as any regular hard drive!

Let me know if this does not work with any of the current projects, as I have not yet gone through this whole XP on a stick! and tried it all out. He..He...

But actually the "updated" guide should not have anything new that could possibly be related to MCE and your problems.

Though both ilko_t and I tried to help you:
http://www.msfn.org/board/index.php?showto...1384&st=230
http://www.msfn.org/board/index.php?showto...1384&st=231

You appear to have not posted any feedback....I find quite improbable that MCE compatibility will appear in the procedure by sheer magic...

Maybe it would be better if you wait patiently for the release of the updated guide, then, once most probably it won't work for MCE , you start a new thread and we try together to find what the problem(s) might be and (hopefully) find a solution for them .

Also, it is my opinion that the whole idea of technical boards like MSFN is or should be that of exchanging ideas and contribute, each according to the spare time and knowledge he has, so it is pretty pointless, not to say somehow rude, to put pressure on members that are working in their spare time and wish to share with the community their results.

In Italy we have a saying that would sound in English something like "one that throws the stone and hides his hands", does it remind you anything/anybody? :
http://www.msfn.org/board/index.php?showtopic=81788&st=5
http://www.msfn.org/board/index.php?showtopic=81788&st=6

jaclaz

Hi guys

I am back to my PC and will have some time to test and update the guide.

Jaclaz, have you updated the script?

@all- what do you think will be easier for novices- make a custom bootsector using jaclaz's script and use only ntldr/boot.ini or the way it was- using Grub4DOS for the TXT part?

Regards,
ilko

@biohead- I believe your answers are here:

http://blogs.msdn.com/astebner/archive/200.../12/464304.aspx
http://www.msfn.org/board/index.php?showtopic=31936

Are you using 2 CDs, or a modified one?
I have just installed MCE without a hitch from Dell CD (one only). Used
If you have other specific folders on your CD make sure you copy them to the appropriate place on the USB stick.
If you have custom winnt.sif on the CD use /unattend:winnt.sif switch too, do not forget to delete redundant entries, i.e. the whole [unattended] section.

If you have answered the questions me and jaclaz asked you before, you could have saved me a couple of hours


@jaclaz- using binifix3.cmd gives me errors, drive letter is set to W, which is not present, script aborts. When you get some spare time could you have a look and also implement the other 2 changes from the post above?

ilko

edit: ahh silly me, shall I change W with C, or this can be done other way, with variables?

Launching TXT-mode Setup direct from boot.ini Menu is faster and more logical, and in my opinion the better choice.
Once making the custom bootsector is automated, it is not to difficult for a novice.

Perhaps the most difficult step in the whole procedure is the making of the LocalSource with the winnt32.exe command. There a novice might need some more support of what is actually occurring and what answers he has to give. Especially it is important to mention that the Setup procedure is taking only a few minutes ( instead of 59) and that one returns to the existing installation. Resetting boot.ini as mentioned already is of course very important.

ilko_t

Welcome back!


No, I was waiting for you to get back, I'll do it in the next few days.

About drive letter, it can ALREADY be given as a parameter, as in

though there is no real (at the moment) parameter checking routine, the hardcoded "W" is just for testing, BOOT.INI should always be on the C: drive, at the time the batch is run.

jaclaz

Sorry, i'm in a hurry, haven't read the whole topic but this is how i did it.

Yep, you did not , that method is using DOS + WINNT.EXE, this thread is related to direct install.

A slightly different DOS + WINNT.EXE howto is here:
http://www.911cd.net/forums//index.php?sho...c=16713&hl=

jaclaz

Please find attached binifix4.cmd

I made a few changes, now it should do everything needed:
1) If you invoke it without parameters it will ECHO usage instructions and ask for a drive letter
2) It will take current "default" entry and add it to the end of the newly made boot.ini editing the description from, say:

to


Let me know if it works for you the expected way.

Also, once it is confirmed to be working, we could delete the "YES" confirmation, add something like a "/noold" parameter to avoid the [OLD Default] entry, and suppress "informative" messages.

jaclaz

I've been playing with winnt32 parameters to make the install easier. Here are some results:

1. Stick formated in FAT16, Hitachi driver used
2. Copy from XP SP2 ntldr, ntdetect.com, setupldr.bin and the custom boot.ini to the stick BEFORE anything else.
3. From I386 folder run

/makelocalsource:all instructs Winnt32 to copy all additional folders as described in DOSNET.SIF. Could be useful to edit it in order to include/exclude files/folders to automate the process.

/unattend:winnt.sif - useful when you have custom winnt.sif, if the needed answers are included Winnt32 carries out the process without a single prompt.
If used the whole [unattended] section must be deleted afterwards, otherwise TEXT Setup will attempt to install on USB stick and recovery console won't be given as option.

/syspart:U /tempdrive:U prepares the drive given for next stage and copies all necessary files and folders. NTLDR gets replaced by SETUPLDR.BIN, renamed to NTLDR.
The custom BOOT.INI gets backed up as BOOT.BAK and a new one, including entries from the old is written:

BOOT.INI before Winnt32 is launched


BOOT.INI after Winnt32:


BOOTSECT.DAT is not created in C:\$WIN_NT$.~BT\, nor the folder is, nor in U:\$WIN_NT$.~BT\, TXT Mode will be launched by the renamed SETUPLDR.BIN anyway. Why it creates this entry is still unknown for me, may be for the GUI part, but when BOOTSECT.DAT will be created...? Perhaps during TEXT mode? Hard to test that as stick will be write-protected.

Winnt32 also changes the bootsector on USB stick, however stick is still bootable. Copies of bootsectors before Winnt32 and after are attached, for stick formated in XP with FAT16 and FAT32.

Jaclaz, please, will you have a look what was changed, and if you have an explanation why. I'll be testing the new BINIFIX tomorrow, thanks for it.

NTLDR (the renamed setupldr.bin one) must be rewritten with normal NTLDR in order to use boot.ini.

txtsetup.sif is put on root by Winnt32, no need to manually copy it.

4.Used Jaclaz's makeBS.cmd to add a new entry in boot.ini and get a patched for SETUPLDR.BIN boot sector. No issues at all.
Please don't forget to put a new copy of NTLDR on root, replacing the renamed setupldr.bin. Also setupldr.bin MUST be copied on stick right after format, or it may not be visible for the boot sector.

In this way I believe would be much easier to perform preparation, even at some point by a script, as not too much is to be changed/added.

Sorry if I made it too detailed, trying to be as much informative as possible.

ilko

@ilko_t
Checked the bootsectors, NO problems, everything is cool, results attached in a .xls file.

However you lied to me

You did not use the SAME procedure with FAT16 and FAT32, as the bootsectors in FAT16 have a different Volume Serial, whilst the ones in FAT32 have the same one.

There must have been a FORMAT between "snapshotting"
FAT16_BootSector_Before.dat
and
FAT16_BootSector_After.dat

(I won't believe that the same operation happened with FAT32 ones and the semi-random routine that calculates Volume Serial gave two times the same number )

jaclaz

You got me

There could have been a format between snapshotting, however I am pritty sure the copies I have were made before and after Winnt32, which changes something in bootsectors. I am interested why and what actually was changed, as this affects sometime stick's bootability.
I still cannot recreate the results every time. There must be something wrong I am doing between steps. Once I get everything working fine, next time stick won't boot at all, using the very same procedure. It could be the way I select boot files to copied, or have to fill the stick with FF, no idea yet. Will carry on tomorrow figuring out what's happening.
Why winnt32 changes bootsector? And what exactly it changes, please as for novice in this field? Please ignore serials

The only reason I can see is that if some kind of error is found, instead of the default message:

this one is shown:


Maybe it is derived by our "unconventional" method , maybe setup "senses" that the USB stick is a Removable device and changes the bootsector to one "appropriate" for this kind of devices.

All other changes, as detailed in the .xls files are consequence of the different length of this message.

However, the "After" bootsectors appear to be valid so I would not worry too much about it.

jaclaz

@jaclaz

About binifix4.cmd- used it from winnt.sif

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

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

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

Format stick with PEtoUSB- no matter seen as fixed or removable, use the very same procedure to prepare stick, both boot files copied before or after winnt32 and all work great.
MBR seems the same, geometry reported by PTEDIT32 is the same in all cases, bootsector changes the same way as when formated by XP and Hitachi driver used, but this time I get NO hangs at boot
Anyway, will not keep trying format from XP, PEtoUSB does the job for me.

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

@silacomalley- thanks for tip, I' ve been using Hitachi microdrive driver for a long time, never got permanent results about stick bootability, PEtoUSB and HP format tool always worked fine for me.


ilko

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

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

to this:

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



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

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

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

jaclaz

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

Meanwhile- any ideas about

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


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

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

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

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

jaclaz

@jaclaz

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

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


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

Simple way to set such for the USB drive is to use PRESETUP.CMD, which if seen by GUI Setup will be launched before anything else.
Here we have 2 options
1. Set the variable if possible- I am not in this field at all, tried to substitute SET with SETX for permanent results in simple script like this:
Where folder MISC will be on stick, containing the files in question. Using SET works for this command prompt session only, using SETX should do it permanent, but seems the syntax is different and SETX with -m parameter works on
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

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

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

ilko

I'll check the bootsectors and let you know.

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

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

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

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

jaclaz

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

http://support.microsoft.com/kb/241803/en-usThis goes for XP too.

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

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

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

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

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

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

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

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


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

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

Regards,
ilko

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

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


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

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

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

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

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

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

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

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

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

Here is my short "to do" list:

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

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

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

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

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

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

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

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

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

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



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

jaclaz

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

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


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


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



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

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

@ilko_t

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

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

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

jaclaz

Have a nice holiday jaclaz, enjoy it