I tried option #1 using FreeDos. I ran into more or less the same problems. Maybe that would give some hint to your very deep research.

PS:
Just a word of caution to anyone using method #1. Do not use FreeDOS. Use a DOS bootable disk derived from XP. Fdisk.exe in this has a limitation in changing the primary partition. Use fdisk.exe from FreeDos to overcome this problem. Do not use anyother files form FreeDos....

Yep,
FreeDos has some problems on some USB devices.
They are said to be fixable, as they appear to be related to Freedos drive geometry autodetect and to a "magic" byte that needs to be in the bootsector, makebootfat mentions this:
http://advancemame.sourceforge.net/doc-makebootfat.html

I never had problems with it on my particular hardware, but I can confirm that I received reports of failures with FreeDos from other people, whilst both "XP extracted" (read Millennium Edition) and Win98 Dos Files (IO.SYS, MSDOS.SYS, COMMAND.COM) work flawlessly.


Another hint, if you don't have a floppy disk drive on your PC (nowadays quite uncommon on laptops), extracting the DOS files from XP could be a problem, there are a few ways out.
1) Use VFD from Ken Kato:
http://chitchat.at.infoseek.co.jp/vmware/vfd.html
2) Use this program by codebeetle:
http://www.gocoding.com/page.php?al=bootflashdos
3) Use this method inspired by the StarMan, focused by yours truly and actually put together by Nuno Brito to just extract the files and later use the HP USB utility normally:
www.911cd.net/forums//index.php?showtopic=16745
(as soon as the 911CD forum works again, for the moment Google cache is here):
http://72.14.221.104/search?q=cache:DXfWKb...owtopic%3D16745
http://72.14.221.104/search?q=cache:dlc3nN...16745%26st%3D20

If you don't have a 98/ME bootfloppy around, the problem might be FORMAT.COM, that is in the XP DOS disk, INSIDE the DELETED file ebd.cab, see this:
http://www.911cd.net/forums//lofiversion/i...php?t18896.html
http://209.85.129.104/search?q=cache:uSdTU...p%3Ft18896.html

You will need a little knowledge using a data recovery program to get it.

Or, even better, get the enhanced FORMAT.COM by Petr:
http://www.msfn.org/board/index.php?showtopic=85573

jaclaz

Happy New Year! Just dropping a quick note to say I'm still here and still have not abandoned this, but my time will be spotty for a bit. The wife is nesting, so I have quite a few home projects in progress, and I've also changed job assignments at work. Will contribute again as soon as possible.

Ok, I figured out a MUCH simpler method for getting NTLDR, and for getting one that doesn't point to \minint assuming you have the prereqs.

NOTE: I havent finished my testing yet as I am remaking my installdir right now with the new patches, so if there is something that comes up later on in setup due to this then shoot me a PM so I know.

Prereqs:
- WinImage (http://www.winimage.com) (the shareware version works fine for this)
- Bart's mkbt
- A working copy of XP
- The 6 boot floppy images from the Original XP Install CD

1) Open WinImage
2) Click the Disk menu, and select Edit Master Boot Record Properties
3) Check the checkbox Include non removable Hard Disks
4) Select the Hard Disk that XP is installed on (Usually Disk 1), and click Save
5) Give the bootsector a name and save somewhere you can find it (I save it to the mkbt directory with the name bootsect.bin)
6) Open a command prompt and switch to the directory mkbt is in
7) Run mkbt as follows:
mkbt -x bootsect.bin j:

NOTE: Make sure you insert the path to the bootsector file if it is not in the mkbt folder. Make sure you change bootsect.bin to the proper file name. Make sure you change j: to the proper drive letter for your USB drive, else you will overwrite the wrong bootsector and MAY not be able to boot back into XP

8) Within WinImage, hit File -> Open and select the first XP Setup Disk image.
9) Copy all of the files there to the root of your USB Drive
10) Open your USB Drive in explorer, and rename SETUPLDR.BIN to NTLDR, and move BIOSINFO.INF to a new folder named $WIN_NT$.~BT
11) Open each of the other Disk Images, and copy all of the files in them to the $WIN_NT$.~BT folder in the root of your USB Drive.

The rest I have not finished testing, I will edit this post once I figure out where to put the rest of the CD files.

I have a question, why not just use ISOBuster and copy the XP CD to the USB key? There are at least two ways of doing this,

First method is just open ISO Buster and copy XP to the USB key and be done with it. Make sure you just copy the files and not create an ISO on the drive, this will give you basically a CD on the drive and it will be seen as a USB CDROM drive.


Second method:
requirements:
NOTE: These instructions are going to assume you're trying to create the Windows XP Profesional x32 SP2 cd from the Windows XP Professional x32 GOLD (Original CD.) SP1/1a and other flavors will be slightly different.
NOTE: You must have time to do this as well...
NOTE: ISOBuster is what I am using, you can use any software which allows you to see the hidden "Booable CD" folder on the O/S disk to do this with, I highly reccomend ISOBuster though. This is a major requirement!

1. Operating System Disk (OEM may work, but one from Dell, HP, Compaq, etc may not)
2. XPSP2.exe file which contains your SP2 slipstream information.
3. RyanVM's Update Pack.
4. Siginet's RyanVMIntegrator.
5. Your drivers if you want to add them.
6. Any applications from RyanVM's site, including his forums.
7. The "Labels.txt" file from the forums here. Make sure you know what the "name" of the CD you're going to create otherwise you "can" use any other name but these instructions will give you a proper looking Windows O/S CD/DVD when you're done.
8. The script below.
9. The instructions over at RyanVM's forums as well as at Unattended.msfn.org
10. A copy of these directions...
11. CDImage.exe and the code below or an ISO creator of your own choosing that can take those commands.
12. Did I mention time?


Step 1.

Grab your labels.txt file and look up the name of the operating system you're going to create.

Step 2.

Keep in mind here "HDD" is the drive location that you are working from it should have at least 10GB of working space on it for this, also the name of your O/S your going to create as well.

Using that information create HDD:\VRMPFPP_EN. You'll want to substitute the name from the labels.txt file, of the O/S you're going to create here.

Step 3.

Put the Windows GOLD cd into your optical drive and open ISOBuster.

In ISOBuster find the folder with the name of your CD on it, it should be red, right click on it and click on "Extract WXPFPP_EN".

It will ask you where you want it to be saved, point it to your HDD:\VRMPFPP_EN folder and let it copy it's contents inside that folder.

Do the same thing for the "Bootable CD" folder.

Click to view attachment
Shows what it should look like when you right click on the folder and highlights the line you need to click on.

Click to view attachment
Shows what it should look like when you go to save it and the directory structure on the disk after a save of both folders on the CD. NOTE HERE that I am using an SP2 cd to copy to that location, the Gold and SP1/1a disks will have a different folder name such as "WXPFPP_EN" for the GOLD edition, you'll want to change that folders name before you create the SP2 ISO to "VRMPFPP_EN", or one of the other names if your going to be building a different O/S. You'll also need to make the changes to the CDImage script below but that is beyond this tutorial.

Step 4.

Open the folder HDD:\VRMPFPP_EN and check that you have two folders in there. Rename the WXPFPP_EN folder to VRMPFPP_EN. Now open that folder up, you should see the directory structure that you normally see on your CD.

Step 5.

Run RyanVM Integrator to Slipstream in SP2, add the RyanVM UpdatePack, and any programs you may want to add. This will take a while to do, so take yourself a break for a while while it's doing it's thing...

*You can find the directions for using this over at his forums.
*Your folder your going to be copying to is located at HDD:\VRMPFPP_EN\VRMPFPP_EN if you've done what I have said thus far.

Step 6.

Add your drivers using the directions over here at Unattended.msfn.org. (I reccomend the $OEM$ setup at the root of the VRMPFPP_EN folder.)

Folder structure at this point:
.\VRMPFPP_EN
.\VRMPFPP_EN\VRMPFPP_EN\
.\VRMPFPP_EN\VRMPFPP_EN\$OEM$
.\VRMPFPP_EN\VRMPFPP_EN\i386
(those are the two most important in that folder but search for reasons and how to do it that way technically there will be more directories here but I'm abrieviating this for sake of longevity.)
.\VRMPFPP_EN\Bootable CD

Step 7

Using the script below in the code, create the CDIMAGE.CMD file and put it next to your CDIMAGE.EXE file and run it. Be sure you have made whatever modifications you need first as there will be different names for different O/S's that need to be there.



Step 8.

Now you have an ISO that you can open in a VM and check out to assure it's working, with the exception of the drivers. I reccommend this step but you don't have to do it if you know what you're doing and realise that you're not going to be able to get back to the desktop without going the long route if you don't have a second machine to revise the build on.

Once you have checked out your ISO file, Open ISOBuster back up, click on "File" and then click on "Open Image File" and locate the ISO you just created. From that ISO, copy everything to the root of your USB key using the instructions in Step 3 above.

Step 9.

After the copy process has stopped on the USB Key use "Safely Remove.." to remove the key and after a brief wait, (aprox 10 secs or so,) plug the key back in and see if you don't have XP come up like it would normally if you had inserted it in a Optical Drive.

Step 10.

Assuming it did, remove all optical disks and reboot into your BIOS, (search how to do this for your machine...)

In the BIOS, look for the settings for "Boot Order" change it so that you're booting from the USB-CD, you may have to make a change in your USB settings there to find it.

After you have found it, save and exit the BIOS.

Step 11.

You should have booted up into your installation at this point, skip it for now...
Once back to your desktop, open your VM again and check that it recognises your USB key and try the install through it first. If this works then reboot again and let it run...

If it doesn't run in VM, then you need to go and check that everything you did was correct, checking all your modifications for typo's, etc. Try it from the ISO and if everything works from that, then debug your key's files.

If that's not the case make sure you set the BIOS up correctly and that it is recognising your USB key as a USB-CD, if not you're going to have to find another method to doing this or upgrade your system. (Most likely you need an upgrade to your system.)

Step 12.

You should be at your desktop at this point and able to see that you don't have any or very many updates from MicrosoftUpdate and all your drivers and most if not all your programs should be installed as well as any settings you made during the creation process should be set.

If so, congradulations you're done!


If not, did you use the VM check in the last step?
If not, and even if you did in some cases, go back and reread all the instructions and check everything you did looking for any typos and that everything was saved correctly. Also make sure of your settings that you set everything up correctly in the .sif, inf, ect files as well as placed everything where it's supposed to go. Again even if there's nothing wrong with what you did, you're probably going to need an upgrade to your system. Do a search to debug all of this.

This seems harder than it really is though and a lot of the questions are answered in these forums or over at RyanVM's forums, some cases both. If everything went well for you, congrats you're now a proud owner of a slipstreamed version of your operatng system with the latest drivers, updates, etc that you can modify at any time and keep updated for your system on your USB key. If your doing multi-O/S installs, you should be able to do them on here as well and have more space for those extras that you would have liked to have used if you had a larger DVD to do them on.

VERY interesting.

Did you succeed with the above on real hardware, not a VM?

Can you post details on the hardware you tested that on?

Can you confirm that a USB stick with a CDFS filesystem is seen by BIOS/setup as a CD-ROM drive?

jaclaz

If read somewhere that Vista does a great job at creating Bootable USB drives, but ONLY from within Vista. I'll see if I can find that article.

'nuff

EDIT: Found the article. It describes how to create a bootable WinPE 2.0 USB stick. The stick must be formatted from within Vista. Is that of any use to you?

Yes,
every info is interesting, but maybe Vista and WinPE 2.0 have nothing to do with windows XP, and with installing it from USB.

Why don't you post a new thread with a link to the article in the Vista section?

jaclaz

You needed to format the USB stick with Vista. That's all that Vista was needed for if I remember correctly. Let me look for that article.

Any updates on the methods posted here? Does all USB sticks work though?

Not yet, still have to find the time to "invent" or "find" a way to avoid (or restore) the deletion of files.


Yes.

jaclaz

Setup deletes files at two times:
-end of textmode setup
-end of graphic mode setup: T -1 minutes

Set USB WriteProtect twice.

First \$WIN_NT$.~BT\migrate.infMountedDevices fixes USB drive letter to U: This can be used at PNP time.
Setting is hardware related, export MountedDevices USB setting from local registry.
Different USB Sticks may require different MountedDevices settings. Create different migrate.inf.

Second \$WIN_NT$.~LS\I386\hiveOEM.inf

\txtsetup.sif: add hiveOEM.inf

\$WIN_NT$.~BT\winnt.sif

Install windows.
At T -1 minutes wait a looong time or remove USB stick. Setup reboots then.
No files are deleted at USB stick.

After windows installation USB stick is write protected still.
You may change StorageDevicePolicies to 0 to disable write protection and delete USB stick in device manager.



Another solution might be fbwf (File Based Write Filter Driver): write protect drive letter U:
A XP Embedded user may have more knowledge.

@cdob

VERY interesting!

Any idea for the reason for the "loong" wait?

About the migrate.inf setting, I remember having started (and not actually finished as most of my projects ) looking into the data written into MountedDevices keys, I am pretty confident that a batch that can automate the creation of it can be made.

about:


since the .inf only contains one "directive", cannot it be eliminated changing the line to:

?


jaclaz

Setup tries to delete all files still, but can't delete files.
I've no idea, how setup works internally.

Yes, a batch can convert MountedDevices keys.
This is a job for a Rob van der Woude third party author.

Rember a fixed USB drive letter is not required, but may be nice anyway.

Yes, StorageDevicePolicies could be one line in migrate.inf.
REG_BINARY is easier to read and may get less errors at editing migrate.inf.
And this was a hint, migrate.inf can hold additional entries.

BTW: At PE setupldr.bin read \minint\system32\migrate.inf.

It worked as described, great job cdob, thanks

I didn't keep mounted devices in migrate.inf, just the write-protect entry and the USB device got D, hard drive got C. No files were deleted, to avoid the long wait I removed the USB stick after 2-3 minutes waiting.
However I had to made a little change for the text- mode in menu.lst :

title Phase 1 WinXP Text Mode Setup
map --read-only (hd0) (hd1)
map --hook
rootnoverify (hd1)
chainloader (hd1,0)/setupldr.bin
savedefault 1
boot

title Phase 2 WinXP GUI Mode Setup
map (hd1) (hd0)
map (hd0) (hd1)
rootnoverify (hd1)
chainloader +1
savedefault 0
boot

otherwise I was getting blinking cursor and nothing was happening, with grub4dos-0.4.3-2007-03-16.

@jaclaz- many thanks for keeping this thread alive and all your useful posts, here, in 911cd.net and any other forums

@ilko_t

VERY good!

It seems like we are almost done.

I guess most of the merit has to go to cdob, whose help and knowledge has been decisive, and to porear whose contribution of ideas and testing was fundamental.


While the first of your menu.lst entries does make sense to me, I am still curious how the second one works, as I see it things must have some logic behind, if BOTH the entries work, this:

should be also working if rewritten as:



by the same principle, viceversa, the entry:


should work as well if rewritten as:



As said, the final boot command is unnecessary, and it should be possible to replace:

with:

to avoid copying SETUPLDR.BIN and NTDETECT.COM to the root of the stick.

And, besides, once you have issued a root or rootnoverify command, root is established, and you only need the forward slash, i.e. :


should be functionally equivalent to:


(as in the second menu.lst entry)

I would be nice if you could test the above and make a new post with all steps together, something one could post a direct link to, to avoid other members to jump forward and backward on this longish thread, as is it is causing me headaches, and I already now most of it.

jaclaz

In my excitement I forgot to thank porear , many thanks to him

gives Error 19, cannot mount selected partition


gives the same message

If in command line I type

map (hd0) (hd1)
map (hd1) (hd0)
map --hook - as far as I know it should be done in order to apply and see the changes in command line
rootnoverify (hd1)

find /$WIN_NT$.~BT/setupldr.bin --->result is hd(1,0)

chainloader /$WIN_NT$.~BT/setupldr.bin gives error 19

chainloader (hd1,0)/$WIN_NT$.~BT/setupldr.bin gives the encouraging "Will boot NTLDR from drive=0x81, partition=0x0..."

now booting SETUP is possible, but as far as I remember it will end up with improper boot.ini, pointing to rdisk(1), instead of (0), that's why I stuck with the map --read-only... variant for TEXT mode. This will be first to test.

Honestly GRUB for me by far not so easy to understand, in some commands I just can't see logical explanation why work or why not.
For example in README.TXT:

breaks the rule map (TO) (FROM) and is opposite (or at least not similar) for me as written here
http://www.gnu.org/software/grub/manual/grub.html#map :




I beleive

makes sense to be changed to



This will be second to test and I will report the results with a full step by step guide.

VERY GOOD.

Also, try with "root" instead of "rootnoverify"....

jaclaz

Here are some findings:

-setupldr.bin (renamed in my case as ntldrstp), ntdetect.com and txtsetup.sif must be copied in root, or it simply reboots when chainloaded, tried many options, but all results were either a hang with blinking cursor or just restart.

Some experiments with GRUB, with red color were unsuccessful:


in this case ntldrstp cannot be found

Setup starts, but gives error 14, txtsetup.sif is missing or damaged.

boots GUI mode fine, read only switch shouldn't be needed anyway. It finds ntldr in (hd0,0) and completes the GUI part just fine.


Boots and completes GUI mode fine, ntldr is found in both in (hd0,0) and (hd1,0), but this seems to cause no problems.

ntldr couldn't be found
-----------------------------------------------------------
The last working menu.lst I is:

ntdetect.com, txtsetup.sif and setupldr.bin are copied to root and setupldr.bin renamed to ntldrstp in my case.


It would have been perfect if all this worked on my laptop too, but it did not.
All the test so far were done on ABIT AN7 motherboard with NF2 chipset and a blank, not partitioned IDE disk.

On Dell Inspiron 6000 when I use same menu.lst it reboots when TXT mode is selected. It has 3 partitions with XP Home installed- Dell Diagnostic, System and Dell Recovery. Double mapping didn't work, mapping (hd1,0-2) too, but when I use only:
it works just fine with no drive mapping at all. On the desktop computer using the same entries result in incorrect boot.ini ( rdisk(1) )as I already wrote about. Haven't tested yet will it set the correct entries on the laptop with no mapping.

Is it because of the different BIOS-es and the way they handle USB? Any ideas?

OK, so definitely we need the SETUPLDR.BIN and NTDETECT.COM on root.

A possible "definitive" way out could be:


In the second item if ntldr is found on both disks, it could maybe cause problems, one could use another file as a marker even if it is found in a subdirectory, the "root" will be to the drive, I am not at all an expert in this, but if one cannot find a file that is on the HD and not on the stick, it should be possible to create it with some entry in TXTSETUP.SIF or similar.

Also, maybe there is something "between the lines" of this:
http://support.microsoft.com/kb/312569/en-us

(if we can find an alternative to the "loong" wait and/or the extraction and reinsertion of the key, we would have a potential "unattended" method)

jaclaz

sets root (hd0,0), instead of the proper (hd1,0) as ntldrstp is found on both places, that's why I use root (hd1,0), then chainloader /ntldrstp should be fine, instead of chainloader (hd1,0)/ntldrstp



For now I am interested why the same menu.lst did not work on the laptop, I will try to explain it again.

On the laptop if I use the following:
it causes laptop to restart, the same way as if NTDETECT.COM is not found in the root. Same entries work just fine on the desktop and result in proper BOOT.INI later like


If I use
on the laptop SETUP starts fine, but cannot confirm whether BOOT.INI will be correct, a lot has to be backed up before I can make tests.
If I use it on my desktop PC, SETUP goes fine, but ends up with incorrect BOOT.INI, pointing to
giving hal.dll is missing, note it does NOT use signature(....) this time.

So we have either to find out why it doesn't work on the laptop, or just find a way to correct BOOT.INI after the final phase of TXT SETUP, when I beleive it's created. With rdisk(1) in boot.ini mapping is not possible, because as I saw in \system32\$winnt$.inf it will look for the installation files on disk(1)

This file was the same with both variants of menu.lst. It seems ntldr, setupldr.bin and the TXT mode setup at some point "ignore" GRUB disk mapping in different way and/or stage.

So, why does the laptop reboot ?

Well, who put ntldrstp on the HD?
However in this case (on the stick that is prepared before) one can use another file, such as menu.lst, or in "find --set-root" command or directly a "special" marker file, simply open notepad, and save the file as USBOOTME.1ST on the stick.....,"find --set-root /USBOOTME.1ST" will not possibly get the "wrong" root.



hmmm, it is possible that the laptop BIOS has some incompatibilities with grub4dos.


What happens on the laptop with the "alternate method":


You can try, issuing single command lines from the command line, one by one, grub4dos in this case is more "verbose" and one can hopefully pinpoint the single command that causes an error.

jaclaz

GRUB disk mapping i suppose If single mapping is used file is found on both drives, if double mapping is used it appears only on the correct drive. But double mapping doesn't work, have a look at the RED quotes in my previous post.
This disk mapping in GRUB is really interesting, as I mentioned it appears that when we do single mapping, we "fool" setupldr.bin and/or ntdetect.com which drive is which, but in later stage this is corrected. In GUI mode thi doesn't work the same way.
It also seems that map (hd0) (hd1) results in same information aviable on both drives, like a "virtual" copy or image, at the same time contents of hd1 are not aviable, thats why for the GUI mode double mapping is needed.

I did try single command in GRUB, actually I use that the most and apply changes later in menu.lst, in my tests set--root /ntldrstp did not do the trick, so I prefer to use
.....
root (hd1,0)
chainloader (hd1,0)/ntldrstp
.....

About the laptop- I was using 2GB Buffalo stick, tried to use 1GB Lexar and using the very same menu.lst (with single mapping) worked
Thats where the long Dietmar's thread will comes handy , I beleive setupldr.bin, ntdetect.com and txtsetup.sif must be written first, before copiyng the other files, may be the laptop BIOS can't see the needed files if they are written too late, but that cause no problems to the AN7 bios. Or it just the USB stick size which matters. However on the Lexar I had an old Nlited installation, not the same "pure" as on the Buffalo.
I will test that later today, fingers crossed

Yep. if the image is somehow doubled, the fond --set-root won't work, as devices are scanned in order....

A lot of info is coming out from your experiments, I'll have to study it a bit and do some more tests myself...continue reporting...

jaclaz

Well, the same version of GRUB and the final menu.lst worked on another desktop, testing with older/newer versions of GRUB gave result.
The one I was using 0.4.3 - 2007-03-16 was causing troubles on the Dell laptops, I tested it on Inspiron 6000 and 6400.

Both 0.4.2 - 2006-11-26 and 0.4.3 - 2007-04-12 (latest available) worked just fine with the 2GB Buffalo stick on the Dells
In a next post, if nothings wrong shows until then, I will summarize all the steps.

Problem might be if the destination drive is formatted as NTFS, one could put up a triple boot on the stick with DOS files and this utility:
EditBINI™
This utility will allow you to edit \BOOT.INI in an NTFS partition from DOS or Win9x.
http://www.terabyteunlimited.com/utilities.html

But if the path to the drive is wrongly hardcoded into $winnt$.inf, one would need to use NTFS4DOS, which is free for PERSONAL USE only:
http://www.free-av.com/antivirclassic/avira_ntfs4dos.html
to access the NTFS drive from DOS.

Personally, besides licensing problems for Commercial users, I always prefer the simpler solution so I guess the above could only be an "extreme" workaround, if nothing else work.

I didn't get if you completed the install and if you got with the

the correct C:\ letter on the hard disk (without migrate.inf).

I guess that the setup re-scan the systems and gets again the "HardDisk0" and "HardDisk1" directly from Bios, bypassing the "temporary patch" made by grub4dos.

In a couple VM I tried, the


works allright, most probably one could prepare instead of a pair of menu entries, several pairs, to allow for "strange" BIOS behaviour...


jaclaz

I can confirm that

worked fine for the TXT mode on 5 machines - 2 Dell Inspiron Laptops, 1 Dell Dimmension 5150, 1 ABIT AN7 motherboard and 1 Asus P4R800-V motherboard. The problem with the Dell Laptops was in the version of GRUB I was using - 0.4.3 - 2007-03-16. This was causing PC to reboot when TXT Setup was chosen and single disk mapping was performed. The most recent version 0.4.3 - 2007-04-12 and the previous stable version 0.4.2 - 2006-11-26 worked fine on the same Laptops.

The GUI part I finished only on the AN7 PC and all was fine, proper drive letters, boot.ini etc. Later on I will test the whole process on the ASUS PC.



In the migrate.inf I left just these entries, this was enough hard drive to get every time C, and the USB stick D during the SETUP and the make USB stick read-only during the first stage:
May be just the line HKLM,"SYSTEM\ControlSet001\Control\StorageDevicePolicies","WriteProtect",%REG_DWORD%,1 is enough to set read-only mode for the USB storage, but I haven't tested it.

The rest is just as cdob suggested.


If no mapping is made for the TXT mode, on the ABIT AN7 machine it results in incorrect boot.ini pointing to rdisk(1), instead of the proper rdisk(0).

Tests in Vmware or QEMU wouldn't be relevant, because of the lack of USB boot. If the USB image is used as HD1 XP setup will handle it later during the process in different way than the USB stick.



In GRUB mapping I found that single

results contents of hd0 to be accessible from both hd0 and hd1, for example NTLDRSTP will be found on both drives. Contents of hd1 are not accessible and could be used when we are not interested in the contents of hd1.

does the opposite, the contents of hd0 are this time not accessible, but contents of hd1 are found on both hd0 and hd1. For example NTLDRSTP won't be found from GRUB neither on hd0 nor on hd1 if it was originally on hd0, whereas NTLDR, originally on hd1 will be found on both hd0 and hd1.

During the TXT setup "map (hd0) (hd1)" will be preserved I think up until the last stage, when scanning for partitions and writing the new boot.ini, when the installer finds the new XP installation on hd0, or it scans only fixed drives? No clues why it works this way.

If double mapping is used

this will "swap" the two hard disks, giving access to the contents of both using the new disk number. If we use double mapping, which logically seems the proper one, XP TXT setup complains about missing txtsetup.sif. Why starting it from second hard drive causes that I don't know. Double mapping could be used for the GUI part, when we need XP to be on hd0 and the source files on hd1, but is not needed since the XP installer at some point rescans or resets this information.

Another idea- wouldn't it be better to use a similar to the XP CD approach for the default boot order, to make the hard drive default with 10-15 secs time-out as the TXT mode is used only once, but the hard drive will have to be booted at least twice (or more for custom installation).


edit: we also need to undo the write-protected mode for USB once install is completed, how do we do that?

Yes, that would be nice, but right now I have no idea on how to do it, unless we cycle to another
menu.lst through the "config-file" command, but I cannot see at the moment how to conditionally do that.
If I remember right, there is a feature like this in "Linux" grub, that uses variables, there is this guy, Adrian Raulete, that made this "Grub superdisk" or something like that. It uses this feature to make a very complex multilevel boot menu but last time I played with grub4dos it didn't have this feature, or at least I wasn't able to make it work. I'll have a look at the idea and see if something comes out.


Well, that should be the easiest thing, it should just be a Reg file merged at the end of GUI setup or, if you prefer, on first "real boot" of the newly installed OS.
I am not an expert at all on this but in one or the other "unattended" sections of the board there is info for this.
Maybe cdob might help on this particular thing.

jaclaz

Here is a quick guide how I proceeded with 100% success on ATA hard drives.

1. Format the USB stick, I used HP USB Format tool, because XP format was reported as incorrect in GRUB.
2. Install GRUB MBR on the stick, the quickest way I found is by GRUBINST_GUI for WIN
3. Get the latest GRUB4DOS and copy GRLDR to the USB root.

Create MENU.LST in USB root
This way the default entry is GUI mode, TXT mode must be selected manually. With these GUI entries XP can be installed and booted later from another partition on the hard drive, not only from the first.

4. Backup your current BOOT.INI and in the XP setup folder \I386 run after it's finished restore BOOT.INI

5. Copy two new folders in the USB stick root - $WIN_NT$.~BT and $WIN_NT$.~LS

6. In \$WIN_NT$.~BT modify
WINNT.SIF


and

MIGRATE.INF
If you wish you can preserve your USB storage drive letter keeping the relevant entries in migrate.inf. Note your current USB drive letter and find the line (mine is set to U)
, I found that it's not needed. [Strings] must be present.

7. Create:

undoUSBWP.reg
and

hiveOEM.inf
and place them in $WIN_NT$.~LS\i386

8. Copy TXTSETUP.SIF, SETUPLDR.BIN and NTDETECT.COM from \$WIN_NT$.~BT to root of USB stick. Delete BOOTSECT.DAT (necessary?) and rename SETUPLDR.BIN to NTLDRSTP, or modify the relevant entries in MENU.LST

9. Add the following lines to TXTSETUP.SIF

10. If you use unattended mode for the setup make sure you delete the whole [Unattend] section, otherwise you won't be able to use System Restore and SETUP will not prompt on which partition to install.

I used BTS mass-storage drivers pack, with KTD option and Nlited fully unattended installation, to keep Nlite options copy the relevant entries from the original WINNT.SIF to the new one, don't forget to delete the whole [Unattended] section. [Data] section do not modify except UseSignatures="no". Also copy $OEM$ to \$WIN_NT$.~LS\i386 and OEM (BTS scripts) to the root of USB stick.

Thanks a lot to porear and jaclaz
All credits for the most important part- how to write- protect the USB flash go to cdob, many thanks

edit: Forgot to mention that removing write-protect mode after GUI is finished is also done in steps 6 and 7.
edit2: some typos corrected, txtsetup.sif

On ATA drives I had success on all 3 different machines, but on SATA drives it went nowhere. The SATA drive appears after the USB stick when SETUP detects disk configuration. I've tried different mapping in GRUB to no avail, no mapping at all, and preserving the USB drive letter. In every occasion SATA drive was recognized after USB:


On ATA drives it looks like that:


Continuing installation when SATA drive is second cause XP boot sector and NTLDR/BOOT.INI being written to the USB stick, corrupting the partition table, then SETUP complains about damaged drive D (or U when old mounted devices was used) and a new boot from the stick is not possible. Repairing GRUB MBR fixes boot, but some files are missing. This was tested on 2 different SATA controllers, Sil2112r and SIS Sata. No IDE drives were attached, only one SATA disk.
Any ideas? May be Dietmar's way of installing XP directly on USB and a separate driver for the USB storage could help, I am going to study this option further.

BTW while studying BTS KTD method I noticed the usage of presetup.cmd, which is launched in GUI mode right before anything else. So another way to write-protect the USB during GUI part could be a single line like REG ..... or regedit ... if it's available at that stage. Any ideas when postsetup.cmd is launched? Google returns no results.


edit: About the long wait at T-1- if we find a way to rename the 2 folders on USB, at lets say T-20 or after installing devices, where source files are no longer needed and make post- setup script renaming them back, this may "fool" setup to stop looking for them and avoid the long wait. If anyone has an idea which method could be used for this purpose would be great.

(hopefully) some ideas to solve this part of the problem:

I doubt that partition table gets corrupt.

The MBR code is replaced, that's all.

It should be quite easy to work around the problem (from the beginning, INSTEAD of your step #2):
1) DO NOT install grdr.mbr
2) Install normally the XP MBR and bootsector (i.e. do nothing, the HP utility will do it)
3) add to root of the stick GRLDR
4) add to root of the stick NTLDR
5) Add to root of the stick a BOOT.INI like this:

This way grub4dos is chainloaded through "normal" NTLDR.

Also, you don't need to rename setupldr.bin to ntldrstp.

jaclaz

I thought the same, but the fact is when this happens SETUP starts complaining corrupted drive U (the USB stick) and cannot continue install. If I fix GRUB MBR and reboot GRUB complains about invalid or unrecognized partition table but still is able to find SETUPLDR.BIN, the problem is that SETUP complains about missing files, at least 10-20 files are reported as missing. May be it just partly corrupted of something because of the different ways it's formated and the way SETUP sees USB stick, because of the read-only switch in GRUB, or because of the GRUB mapping, you may have better explanation. Actually its not because of drive mapping in GRUB, I remember that I tested with no mapping at all, simply invoking setupldr.bin and MBR got corrupted again.

This is an option, but SETUP will still place its boot files on the USB stick, as it's seen as the first hard drive and the first active partition, not on the hard drive. If stick is already with NT MBR this may prevent file corruption, but then we well have to place BOOT.INI and NTLDR on the hard drive and also work on the GRUB mapping and invoking the GUI part. Another option is in BOOT.INI to make second entry pointing to the hard drive, thus we can invoke the GUI part from BOOT.INI instead of GRUB. Also a small script or manual copy of NTLDR and a proper boot.ini to the hard drive will be needed.

A way I can think of is somehow to force TXT SETUP to see USB stick as second drive, or removable if it is not seen as such, this will make it place the needed boot files on the hard drive, either by driver or by relevant registry entries placed by migrate.inf.

I rename setupldr.bin because on second partition I intend to place Bart PE files and/or working XP to experiment and it's easier to manage partitions and drive mapping in GRUB, if one intends to use stick solely for XP install it's not needed.

Different user have different needs.
I consider USB WinXP installation as a emergency solution.
This should work at different machines, manually parts are allowed.

My menu.lst part is pretty dumpAs known, this gives a broken boot.ini pointing to rdisk(1).

A "map (hd0) (hd1)" use fixed hdN numbers.
At different machines both source and target may use different hdN numbers.
E.g. a internal card reader may result in different hdN numbers.
And different BIOS use different USB boot handling.
A new unkown machine may get different results to previous experience.
That's not a general solution.

A general working unattended solution would be nice.

In the meantime I use a manually workarround:
I knew false boot.ini entries from the past and will recognice this in future.
I manually edit boot.ini at first reboot.
$winnt$.inf was not edited, false entries are there still.
Recovery console, PE and Knoppix are at this USB stick anyway.


I din't used unattended feature to remove USB write protection.
At first windows boot, I opened regedit.exe and deleted StorageDevicePolicies.

A idea, NOT tested: hiveOEM.infilko_t's winnt.inf [GuiRunOnce] remove WriteProtect makes more sense.


Some fun:Setup is started, textmode does work, first reboot fails.
Broken boot.ini: multi(0)disk(0)rdisk(2)partition(1)\WINDOWS2

Recognice rdisk(2), that's not rdisk(1).
A second USB stick was attached too.
Idea: second USB stick was hd1, internal harddisk hd2.

After removing second USB stick, grub4dos fails: Error 27: Disk read error.
There is a internal SATA ACHI hd with NTFS partitions.
Neither at second second USB stick not hard disk is a /$WIN_NT$.~BT/setupldr.bin.
/$WIN_NT$.~BT/setupldr.bin exist once at hole machine.

chainloader (hd1,0)/ntldr_bt give Error 27 too.

Second USB stick inserted again:Setupldr.bin is loaded, however ntdetect failed.


At the other hand boot.ini signature(de33eaf8) indicates:
Windows setup detected some strange environment and use a fall back settings.
Requested settings ask grub4dos to build a insane mapping: two hds mapped to the same hdX.
That's a broken design. Contrary this may work at all machines or fail at some machines.



I like a fixed USB drive letter still, compare OEM drivers at USB U:
So I created a first version to extract MountedDevices setting.
Copy MkMigratgeInf.cmd to <USB drive>\$WIN_NT$.~BT\MkMigratgeInf.cmd and launch it. This USB drive is mapped to DosDevices U:.
A MIGRATE.INF.TXT is created, open it and read file. Rename file to migrate.inf.

MkMigratgeInf.cmdA XP default reg.exe is expected.

By the way:
A RAM loaded PE image read file \I386\system32\migrate.inf.
Another untesed idea: use migrate.inf for general settings
Create tow similar PE, small registry changes.
Two setupldr.bin: one calls migrate.inf, another calls migrat2.inf.

@ilko_t

Maybe one could use this method:
http://www.msfn.org/board/index.php?showtopic=12566

to execute commands when the GUI part starts.

In the post it is reported that, while regedit.exe doesn't work in this stage, reg.exe does.

jaclaz

Interesting results

I wouldn't think of installing with 2 sticks inserted, exactly because of the GRUB mapping.
Tested your script for migrate.inf resulted in correct entries, however may be adding the write-protect entries will be handy, so we'd have a completed migrate.inf.

About the boot.ini signatures- I agree that it shouldn't be made this way, but as far as I tested it on different machines it worked fine, at least creating boot.ini pointing to the right place.

If we don't use mapping we end up with boot.ini to be modified, an idea how to do it automatically is to place NTLDR and boot.ini on the USB stick, pointing to the hard drive partition with the new installation, invoke NTLDR from GRUB, and at some stage during the GUI part copy NTLDR, NTDETECT.COM and a generic BOOT.INI to the root (if SATA disk is used), and edit BOOT.INI. Presetup.cmd will do the job in this case.
Bootcfg.exe behaves in different way in recovery console and XP environment, how it will work during GUI is to be tested. May be a cmd script would also do the work (I am not into this part at all) or another tool like bootpart may do it for us. Still searching for an automated solution to edit boot.ini, a program or script, started by presetup.cmd.

With SATA disks I still have no luck at all- if it's not a "native" controller, SATA disks are listed as second, after USB stick and SETUP places boot files on the stick rewriting the boot sector. With 2 sticks I tested- Buffalo 2GB and Lexar 1GB when formated by XP I can't boot NTLDR- "disk error, press any key to restart..". If I format it with HP utility they both boot fine, but when TXT setup rewrites boot sector it corrupts some files and makes next boot impossible. Format in Fat16 and 32 makes no difference. Manually editing the stick geometry using methods suggested by jaclaz will be of no use, as I beleive TXT setup will still place its boot sector on the wrong place considering the way it sees USB stick.

I am currently searching for solution how to list USB after non-native SATA if that's possible at all, may be something in txtsetup.sif will help, or driver loaded along with the other SATA/SCSI drivers, but the information I find is quite limited.

Haven't found out yet when exactly postsetup.cmd is launched, may be it will help to rename the source folders temporary avoiding the long wait at T-1. At first boot we rename source folders back. If anyone knows what else could be used to launch cmd script after T-20 or T-15, when setup files are no longer needed, please help

A little offtopic- another way I am working on is also much quicker and universal- USB stick carrying an image of (not necessary) sysprep-ed "generic" XP installations. Different HALs are no issue, 0x7B BSOD is resolved by the relevant CriticalDevicesDatabase entries with the corresponding drivers and services. Intelppm service, causing BSOD on some AMD machines is disabled in advance.

Regards, Ilko_t

@Ilko_t
Don't misunderstand me. I appreciate all your testings and findings.

I'm slitting myself:
At testing machines insane approaches are allowed, e.g. two USB sticks.
All data may be destroyed.
At testing machines I like grub4dos map and boot.ini signature.
I haven't understood BIOS, grub4dos and windows setup behaviour fully.

Contrary a final solution has to work at unknown machines too.
No partiton or data is destroyed.
At unknown machines I like a low risk solution.
Currently that's avoid grub4dos map. Boot.ini may have to be manually edited.
If there is a secure map solution, I happily change my mind and use this solution.

Thanks for migrate.inf scripting report.
First version is more a basic test version. Yes write-protect entries can be added.

I've limited free time: no further testings and no development so far.

@ilko_t

Newish release of grub4dos has introduced a couple new commands:


This could be the way to introduce "automatic" selection of the grub4dos menu.lst entry during first and second boot.

jaclaz

Some more migrate.inf related info:
http://www.911cd.net/forums//index.php?showtopic=19663

jaclaz

I've used this method myself before, successfully. But when you try to install via these same files onto another pc, you get hardware BSODS - so that's why I just use the winnt.exe from dos.

You seem to be missing some crucial files in this method - when i did this, i just used the hp drivekey utility, and then do winnt32.exe and then copy the 2 folders over to my usb drive, along with ntldr (the pe2usb version, but it works with the normal version anyway as your usb key gets treated as a harddrive!), and a file called $LDR$, and boot.ini that points to bootsect.dat). Also you need txtsetup.sif in the root where $LDR$ is and so on otherwise setup wouldn't start for me! I might be forgetting some files here - oh yeah, you need ntdetect.com. (is that all?)

To be honest, i find it much easier installing using winnt.exe.

snowden,
sorry, but evidently it's you that are missing something, like a few months work by several members.

The initial "normal" way by porear you are referring to, due to the deletion of some files (and some other minor things) did work only once.

The new "final" method, thanks to ilko_t and cdob is repeatable:
http://www.msfn.org/board/index.php?showto...1384&st=128
(previous posts are to be considered obsolete by the above one)

As said in the other thread I too find the WINNT.EXE method better, but I personally have on ALL my machine a 1 Gb FAT16 partition as First Active Primary.

And, as said, speaking of nliting, removing WINNT.EXE install support makes the build smaller.

jaclaz

Thanks a lot to porear and jaclaz, ilko_t and cdob

The method that ilko_t described for installing Windows XP from a bootable USB-stick works perfect !
I have used an Apacer HT203 1GB USB-stick and Windows Setup on my laptop took only about 30 minutes !

The GRUB4DOS grldr was complaining about the CHS values of the USB-stick obtained from my BIOS,
but the warning was no problem for beginning Windows Setup.

There were some small differences with the normal setup from CD.

I obtained an extra file NTBOOTDD.SYS in the root of my C-drive,
which is an ATAPI IDE Miniport Driver.

Also in the boot.ini file there was an extra entry beginning with signature(87538753) ,
although UseSignatures="no" was used in the winnt.sif file.
The entry was marked as the default entry and slows down the booting of the computer by 20 sec.

Replacing signature(87538753)disk(0)rdisk(0)partition(1)\WINDOWS by
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS in the boot.ini file and removing the second entry,
solved the problem and now the computer is booting as fast as normally

I understand that the procedure is not yet applicable to SATA harddisks,
but for the many people that use PATA harddisks, it is already an excellent solution

ilko_t wrote on Apr 22 2007 about SATA problem:



In the Help file of the Deployment Tools I saw the following sentence in the
description of the Unattended parameter TargetPath:

"If you want to specify the target drive, you must use the /tempdrive command-line switch
when you run Winnt32.exe

and:

/tempdrive:drive_letter:
Directs Setup to place temporary files on the specified partition.
For a new installation, Windows will also be installed on the specified partition. "

So I think it might be that using the command: winnt32.exe /makelocalsource /noreboot /tempdrive:C:
can help to force Windows Setup to use the C-drive of your SATA harddisk.

I have no SATA drive, so I cannot test the idea ....

@wimb

Happy to hear a story of success!


This is a very interesting report, for two reasons:
1) it confirms that when booting Windows can use NTBOOTDD.SYS even if it is a ATAPI driver, not only SCSI and SATA, I am very interested in this as it is another little step on the road of using the possibility to use ANY driver, as long as it is a Miniport one, to boot.
2) it confirms that the signature sintax works perfectly, though with a delay

What would be interesting, if you could make some tests and report, it would be to understand whether the delay is due to:
a. the "sheer" presence of the signature syntax (hence the need to scan Hard Disk(s) MBR to check it
b. the presence of the Miniport driver renamed as NTBOOTDD.SYS (maybe different timings in initialization that cause the delay)

Proposed testing (given that you are familiar with procedures needed should the system become unbootable):
1. Only re-copy the NTBOOTDD.SYS to root of drive
2. Only re-add the signature syntax line in BOOT.INI
3. Both of the above



I have not any SATA equipped hardware, but I don't think that what you suggest is feasible/useful, as when you run the WINNT32.EXE C: will be almost invariably the First Active Partition of your First Hard Disk, and NOT the USB stick, moreover, if I am not mistaken, executing such a command will modify your "resident" BOOT.INI to start install at next reboot of the PC....


Cheers,

jaclaz

Hi wimb, thanks for posting your results and welcome to the party

In my setup NTBOOTDD.SYS was not used, and I don't remember any delays when signature was present in BOOT.INI, I have no idea why it was used for your PATA drive/controller. Will you post your Motherboard model and what controller it uses along with its Hardware PID and VID, ?

As for the SATA disks, I am still nowhere, after days in researching on i-net and messing with TXTSETUP.SIF I beleive that the order Setup detects disks is hard coded, may be in DISK.SYS or somewhere else, PATA goes first, then USB, then SCSI/SATA. I have a new motherboard to test on with Intel ICH8R and the next few days I will study how Setup behaves when controller is in IDE, AHCI and RAID mode and will report results.

For now I see 4 ways for overcoming SATA drives issue:

1. Make the stick formated (and bootable at the same time) the same way as SETUP will see it during TXT part and write MBR and ntldr/ntdetect.com on it, so even when those are written the information will remain intact, then copy those files to the hard disk using PRESETUP.CMD or any other way.
2. Somehow "force" SETUP not to write this information on the first active hard drive, I have no clue how
3. Somehow "force" SETUP the way it detects the hard drives, or "fool" it to see SATA/SCSI disks as ATA, detecting them before USB.
4. Anything else which one could suggest

As for the long delay at T-1 we could use CMDLINES @ T-12 to lift write-protection, rename the two folders on the stick and later use GUIRUNONCE to rename them back. Due to lack of time I haven't tested this yet and am not sure whether GUI setup would re-read registry information about USB write protect at that stage. I consider it as cosmetic issue and will test it after SATA/SCSI issue is fixed.

@jaclaz - what do you think of 1.- about the formating?
I looked on the new GRUB release, for compatibility reasons for now I prefer to stick with the method I posted- 1 manual selection for TXT setup, the GUI part remains the default selection.

hmmm, I don't get it, you CANNOT copy a MBR from stick to hard disk, the partition entry will be invalid (due to different size and geometry of partition) AND disk signature will be duplicated, which has been proved in the past to be a NO-NO due to the problems it causes in drive letter assignments; can you better elaborate?

I may be wrong, as often happens, expecially when guessing an undocumented or poorly documented feature, but I think the right approach could be to create a second migrate.inf entry for the SATA disk, linking it's first partition to C:, directly from scratch as per these posts of mine:
http://www.911cd.net/forums//index.php?showtopic=19663
http://www.boot-land.net/forums/index.php?...c=2085&st=3

And find a way to write the signature to the SATA drive before starting install.

Signature should not be altered by FDISK /MBR or whatever similar action setup does when booting to prepare the HD.

This would probably lead (through a signature syntax boot.ini entry AND the appropriate SATA driver copied to root as NTBOOTDD.SYS) to make setup correctly attribute letter C: to the SATA drive.

If you could experiment a bit in this direction manually, we will later see if and how it is possible to replicate the procedure automatically, though this would probably mean having grub4dos/grub.exe and some flavour of DOS on the stick, thus, alas, substantially back to square one of the original method 1) through DOS and WINNT.EXE.


jaclaz

You didn't' get me right, SETUP writes that, thus making the stick unusable. Setup writes that using the geometry it sees the stick during TXT mode, which is different than the way its formated by HP format utility for example.
Formating the stick by XP will result probably in the same geometry which TXT setup will see it, and will not corrupt files, but USB stick formated by XP was in my tests non bootable, no matter FAT16/32 ot NTFS.
The idea is to leave TXT setup to rewrite that, and use BOOT.INI on the stick, in this scenario GRUB is not needed (or may be just for the GUI part) and we wouldn't care about improper boot.ini entries, as we could automatically copy a generic one to the hard drive later.

I'm still a bit lost about it.

The rewriting of the MBR on the stick only happens when a SATA drive is present, doesn't it?



Can you use an utility like Dimio's HD hacker:
http://dimio.altervista.org/eng/
(or any other similar one)
to extract:
1) Stick MBR as formatted anew (before starting install)
2) Stick MBR modified by SETUP
3) HD MBR as written by SETUP

and attach them in a .zip file so that I can have a look at them?

And, sorry, I know I seem a bit tough, and maybe I'm becoming a nuisance but can you re-cap for me if:

means that you are running the stick with GRUB MBR and not with the "standard" MBR + NTLDR + Boot.ini with entry C:\GRLDR?

Did you try with the second one above (it is possible that SETUP finds a "strange" code (not geometry) in the MBR and replaces it, what happens if the code is ALREADY a Win2K/XP/2003 MBR?


jaclaz

P.S.: did you also try putting on the stick the appropriate SATA miniport driver renamed as NTBOOTDD.SYS? This might avoid the different order of enumeration of the drives...

jaclaz wrote:

The NTBOOTDD.SYS Miniport Driver is used by the signature(87538753)... entry in the boot.ini file,
and they together cause a 20 sec delay before the Windows logo appears.
In this case removing the NTBOOTDD.SYS file is fatal: Windows won't start due to disk geometry problem.
The signature(87538753) corresponds to the 4 bytes from offsets 1B8h through 1BBh in the MBR,
which are called the Windows™ 2000/XP Disk Signature or NT Drive Serial Number.
For every install from bootable USB-stick they have the same value,
whereas I think that they should change.

see: http://www.geocities.com/thestarman3/asm/mbr/Win2kmbr.htm



The second entry of boot.ini beginning with multi(0)... does not make use of the NTBOOTDD.SYS file.
Removing the NTBOOTDD.SYS file has in this case no effect.
The multi(0)... entry is also the entry normally occurring in boot.ini when installing from CD.

ilko_t wrote:

I have used a Medion Laptop type MD6100 with a Medion Motherboard with Intel Pentium 4 processor.
The Chipset is from SIS: SIS648 CPU to PCI Bridge and SIS963 South Bridge.

How can I determine the PID and VID ?

You can use regedit and explore in the:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI

Or (more simply) use SIW:
http://www.gtopala.com/

or SIV:
http://siv.mysite.wanadoo-members.co.uk/

jaclaz

P.S.:


Yes, but how the "signature number" is generated is not at all clear, not even Daniel B.Sedory, who appears one of the first people to document the feature has a clear take on it.
It is possible that some form of "checksum" is generated thus signature on same system (but in subsequent installs) remains the same.
However "normal" installs appear to change the disk signature ONLY if it is not already present (i.e. 00 00 00 00).