lilas

@jaclaz Thank you. The referenced tools from Nir Sofer look very good, I will try them.

@jaclaz Thank you for the interesting detailed explanations. For a plain man point of view, the registry entries are really a mess :-). > After a lot of inserting and removing sticks, the Registry gets cluttered and should be cleaned. I believe this is my problem, since I plug/unplug a lot of USB keys and hard disks. Is there a tool for this, or I have to do it manually, and how?

I finally find a bypass to my problem by making all removable USB key into fixed disk, using Hitachi microfilter. http://www.boot-land.net/forums/index.php?showtopic=7512

I found this problem which is for me related to my original problem. Strange problem with MountedDevices, drive letter not memorized I have two USB keys of same manufacturer, same model, same capacity. I partitioned them and formatted them with FAT32. USB_key_a and USB_key_b are removable USB keys. Each has its own disk signature (seen with mbrfix /drive n readsignature), different volume lables, and of course different serial numbers. 1) USB_key_a plugged in USB_port1 : drive letter set to M: 2) USB_key_b plugged in USB_port1 : drive letter seen as M: ! So I changed to N:. Unplug it. 3) USB_key_a re-plugged in USB_port1 : drive letter seen as N: (instead of M: as set in step 1) !). Reset drive letter to M:. Unplug it. 4) USB_key_b re-plugged in USB_port1 : drive letter seen as M: ! So I changed to N:. Keep it plugged. 5) USB_key_a plugged in USB_port2 : drive letter seen as E:, set to M:. Good, so I have both M: and N: active at the same time. So USB_key_a = M:, and USB_key_b = N:. OK, unplug both USB_key_a and USB_key_b. 6) USB_key_b plugged in USB_port2 : drive letter seen as M: ! So it looks like XP depends also on the USB port number for assigning drive letter? Other quesions: 1) What are the meaning of the entries in MountedDevices? It looks like non removable disk has shorter GUID values (disk signature + checksum in boot sector?) than removable devices? What are the meaning of values stored for GUID for removable disks? Same question for DosDevices data for removable disk (like M: and N: are much longer). 2) Why there is a confusion between M: and N: drive letter? I also experience XP disk management hang (MMC) at opening when there are seemingly confusion on the drive letters. And in some cases a BSOD with stop code 0x0A IRQ_NOT_LESS_OR_EQUAL on plugging these USB keys. Thank you in advance. Following is sample of my MountedDevices. G: is CD-ROM, M: and N: are removable USB keys, C: D: F: are internal fixed disks, the other are USB HDD. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices] "\\DosDevices\\C:"=hex:3a,19,a2,c3,00,10,10,71,02,00,00,00 "\\DosDevices\\D:"=hex:3a,19,a2,c3,00,a0,96,3a,0f,00,00,00 "\\DosDevices\\F:"=hex:3a,19,a2,c3,00,d4,1f,02,0a,00,00,00 "\\DosDevices\\H:"=hex:85,51,9f,ed,00,7e,00,00,00,00,00,00 "\\DosDevices\\J:"=hex:67,74,b7,24,00,cc,4d,51,13,00,00,00 "\\DosDevices\\K:"=hex:67,74,b7,24,00,34,93,43,73,00,00,00 "\\DosDevices\\L:"=hex:67,74,b7,24,00,ac,f1,56,16,00,00,00 "\\DosDevices\\P:"=hex:67,74,b7,24,00,c4,1b,1c,04,00,00,00 "\\DosDevices\\Q:"=hex:67,74,b7,24,00,7e,00,00,00,00,00,00 "\\DosDevices\\R:"=hex:f8,7d,df,dd,00,7e,00,00,00,00,00,00 "\\DosDevices\\S:"=hex:7b,17,c6,1f,00,7e,00,00,00,00,00,00 "\\DosDevices\\T:"=hex:f4,63,90,70,00,82,00,00,00,00,00,00 "\\DosDevices\\W:"=hex:67,74,b7,24,00,de,42,4f,0e,00,00,00 "\\DosDevices\\X:"=hex:9b,ba,df,dd,00,7e,00,00,00,00,00,00 "\\??\\Volume{910999dc-7ba2-11de-95ed-806d6172696f}"=hex:3a,19,a2,c3,00,10,10,\ 71,02,00,00,00 "\\??\\Volume{910999dd-7ba2-11de-95ed-806d6172696f}"=hex:3a,19,a2,c3,00,d4,1f,\ 02,0a,00,00,00 "\\??\\Volume{910999de-7ba2-11de-95ed-806d6172696f}"=hex:3a,19,a2,c3,00,a0,96,\ 3a,0f,00,00,00 "\\??\\Volume{910999e0-7ba2-11de-95ed-005056c00008}"=hex:f4,63,90,70,00,82,00,\ 00,00,00,00,00 "\\??\\Volume{910999e1-7ba2-11de-95ed-005056c00008}"=hex:67,74,b7,24,00,7e,00,\ 00,00,00,00,00 "\\??\\Volume{910999e2-7ba2-11de-95ed-005056c00008}"=hex:67,74,b7,24,00,c4,1b,\ 1c,04,00,00,00 "\\??\\Volume{910999e3-7ba2-11de-95ed-005056c00008}"=hex:67,74,b7,24,00,de,42,\ 4f,0e,00,00,00 "\\??\\Volume{910999e4-7ba2-11de-95ed-005056c00008}"=hex:67,74,b7,24,00,cc,4d,\ 51,13,00,00,00 "\\??\\Volume{910999e5-7ba2-11de-95ed-005056c00008}"=hex:67,74,b7,24,00,ac,f1,\ 56,16,00,00,00 "\\??\\Volume{910999e6-7ba2-11de-95ed-005056c00008}"=hex:67,74,b7,24,00,34,93,\ 43,73,00,00,00 "\\??\\Volume{910999e9-7ba2-11de-95ed-005056c00008}"=hex:9b,ba,df,dd,00,7e,00,\ 00,00,00,00,00 "\\??\\Volume{910999eb-7ba2-11de-95ed-005056c00008}"=hex:f8,7d,df,dd,00,7e,00,\ 00,00,00,00,00 "\\??\\Volume{910999ec-7ba2-11de-95ed-005056c00008}"=hex:7b,17,c6,1f,00,7e,00,\ 00,00,00,00,00 "\\??\\Volume{910999ee-7ba2-11de-95ed-005056c00008}"=hex:f7,7d,40,70,00,7e,00,\ 00,00,00,00,00 "\\??\\Volume{091f4b14-7bf9-11de-95ef-005056c00008}"=hex:25,89,08,6e,00,7e,00,\ 00,00,00,00,00 "\\??\\Volume{f3873349-7d0a-11de-95f1-005056c00008}"=hex:5c,00,3f,00,3f,00,5c,\ 00,53,00,54,00,4f,00,52,00,41,00,47,00,45,00,23,00,52,00,65,00,6d,00,6f,00,\ 76,00,61,00,62,00,6c,00,65,00,4d,00,65,00,64,00,69,00,61,00,23,00,37,00,26,\ 00,32,00,65,00,32,00,33,00,34,00,34,00,35,00,38,00,26,00,30,00,26,00,52,00,\ 4d,00,23,00,7b,00,35,00,33,00,66,00,35,00,36,00,33,00,30,00,64,00,2d,00,62,\ 00,36,00,62,00,66,00,2d,00,31,00,31,00,64,00,30,00,2d,00,39,00,34,00,66,00,\ 32,00,2d,00,30,00,30,00,61,00,30,00,63,00,39,00,31,00,65,00,66,00,62,00,38,\ 00,62,00,7d,00 "\\??\\Volume{f387334a-7d0a-11de-95f1-005056c00008}"=hex:5c,00,3f,00,3f,00,5c,\ 00,53,00,54,00,4f,00,52,00,41,00,47,00,45,00,23,00,52,00,65,00,6d,00,6f,00,\ 76,00,61,00,62,00,6c,00,65,00,4d,00,65,00,64,00,69,00,61,00,23,00,37,00,26,\ 00,62,00,30,00,35,00,62,00,30,00,33,00,64,00,26,00,30,00,26,00,52,00,4d,00,\ 23,00,7b,00,35,00,33,00,66,00,35,00,36,00,33,00,30,00,64,00,2d,00,62,00,36,\ 00,62,00,66,00,2d,00,31,00,31,00,64,00,30,00,2d,00,39,00,34,00,66,00,32,00,\ 2d,00,30,00,30,00,61,00,30,00,63,00,39,00,31,00,65,00,66,00,62,00,38,00,62,\ 00,7d,00 "\\DosDevices\\G:"=hex:5c,00,3f,00,3f,00,5c,00,49,00,44,00,45,00,23,00,43,00,\ 64,00,52,00,6f,00,6d,00,48,00,4c,00,2d,00,44,00,54,00,2d,00,53,00,54,00,5f,\ 00,44,00,56,00,44,00,52,00,41,00,4d,00,5f,00,47,00,53,00,41,00,2d,00,55,00,\ 32,00,30,00,4e,00,5f,00,5f,00,5f,00,5f,00,5f,00,5f,00,5f,00,5f,00,5f,00,5f,\ 00,5f,00,5f,00,5f,00,5f,00,5f,00,5f,00,48,00,52,00,30,00,35,00,5f,00,5f,00,\ 5f,00,5f,00,23,00,34,00,26,00,31,00,39,00,39,00,61,00,63,00,62,00,61,00,33,\ 00,26,00,30,00,26,00,30,00,2e,00,31,00,2e,00,30,00,23,00,7b,00,35,00,33,00,\ 66,00,35,00,36,00,33,00,30,00,64,00,2d,00,62,00,36,00,62,00,66,00,2d,00,31,\ 00,31,00,64,00,30,00,2d,00,39,00,34,00,66,00,32,00,2d,00,30,00,30,00,61,00,\ 30,00,63,00,39,00,31,00,65,00,66,00,62,00,38,00,62,00,7d,00 "\\DosDevices\\M:"=hex:5c,00,3f,00,3f,00,5c,00,53,00,54,00,4f,00,52,00,41,00,\ 47,00,45,00,23,00,52,00,65,00,6d,00,6f,00,76,00,61,00,62,00,6c,00,65,00,4d,\ 00,65,00,64,00,69,00,61,00,23,00,37,00,26,00,62,00,30,00,35,00,62,00,30,00,\ 33,00,64,00,26,00,30,00,26,00,52,00,4d,00,23,00,7b,00,35,00,33,00,66,00,35,\ 00,36,00,33,00,30,00,64,00,2d,00,62,00,36,00,62,00,66,00,2d,00,31,00,31,00,\ 64,00,30,00,2d,00,39,00,34,00,66,00,32,00,2d,00,30,00,30,00,61,00,30,00,63,\ 00,39,00,31,00,65,00,66,00,62,00,38,00,62,00,7d,00 "\\DosDevices\\N:"=hex:5c,00,3f,00,3f,00,5c,00,53,00,54,00,4f,00,52,00,41,00,\ 47,00,45,00,23,00,52,00,65,00,6d,00,6f,00,76,00,61,00,62,00,6c,00,65,00,4d,\ 00,65,00,64,00,69,00,61,00,23,00,37,00,26,00,32,00,65,00,32,00,33,00,34,00,\ 34,00,35,00,38,00,26,00,30,00,26,00,52,00,4d,00,23,00,7b,00,35,00,33,00,66,\ 00,35,00,36,00,33,00,30,00,64,00,2d,00,62,00,36,00,62,00,66,00,2d,00,31,00,\ 31,00,64,00,30,00,2d,00,39,00,34,00,66,00,32,00,2d,00,30,00,30,00,61,00,30,\ 00,63,00,39,00,31,00,65,00,66,00,62,00,38,00,62,00,7d,00

@jaclaz > And the little app by Uwe Sieber: didn't work? I did not try it although it seems interesting. Because it is not "portable" : it requires an installation with new service created, and some setting which is not common (machine-specific)

@jaclaz > I would rather look for problems in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USBSTOR, but of course I may be completely off-track. Thank you for your reply. I looked into this key and did not see anything abnormal, there are entries for vendor id/product id for the USB HDD/keys I plugged in the past. How can I see that there is a problem? Do you know the meaning of MountedDevices entries type 2 (beginning with #)? I did not see any relationship with other entries types. For old entries of type 2 that are not found in type 4, I assume I can safely delete them. By the way, the only workaround I found to change drive letter is to rename the key of type 4 (changing for example \DosDevices\E: into \DosDevices\U: , instead of using the mmc/disk management that would hang.

Hello, I have the following problem: I am running XP SP3. 1) As soon as I plug an USB Hard disk, everything is OK (drive letter assigned, files access etc...). I can start disk management (mmc, dmremote, dmadmin), but I cannot change the drive letter assigned to the USG hard disk. It hangs. I have to unplug by force the USB HDD, then kill the mmc.exe/dimremote.exe to recover). The problem is reproducible at will. 2) As soon as I plug an USB key, , everything is OK (drive letter assigned, files access etc...). But I cannot start disk management, it hangs forever. I have to close the disk management window, and again kill mmc.exe and dmremote.exe. In the registry, under HKLM\System\MountedDevices I have 4 types of entries : 1) Default 2) Entries that look like #{10bd8f26-4567-11de-9d7d-005056c00008} (REG_BINARY) 3) Entries that look like \??\Volume{10bd8f25-4567-11de-9d7d-005056c00008} (REG_BINARY) 4) Entries that look like \DosDevices\C: (REG_BINARY). Questions: Entries type 1) and 4) seem OK for me. For type 4), the binary value is apparently the disk signature of the HDD/USB HDD with the assigned drive letter. 1) What is the meaning of entries type 2) and 3)? 2) Can I safely remove all entries of type 2) and 3) ? Could this fix my original problem? Thank you.

Thank you for your hint. The problem is now fixed. Explanations: I used first a removable USB key with the program. Once it works, I copied all the files to a USB HDD and rerun the program which correctly detects the fixed USB HDD. By pressing GO there are 3 choices. I chose the SYNC option (this is the problem): this option does NOT update the txtetup.sif file, even if I delete it. From your post I use the third option (Cancel button) to delete the two $WIN_NT$.~BT and $WIN_NT$.~LS directories. This time the txtetup.sif is created and has rdummy.sys and now it works. Suggestion: maybe txtsetup.sif should always be updated regardless of the option chosen ? Other question : I use USB HDD key with multiboot capability. The program did patch setupldr.bin to avoid collision with /minint/setupldr.bin (UBCD4Win) and txtsetup.sif at root. I also have ERD commander 2005/2007 setupldr.bin that was patched to resides inside \ERDC and \ERD7 directory respectively. Now it no longer works due to presence of txtsetup.sif at root. I assume I have to patch some specific location of txtsetup.sif to notsetup.sif ? Edit: answer to my own question: yes, one occurrence of txtsetup.sif has to be changed to notsetup.sif to avoid collision.

Thank you, but I did not see concretly how to add the rdummy.sys to make it works. I did check the option to force removable disk but with bad result. Does the program do anything for me? Could you please provide more details, thank you.

Hello, I tried WinSetupFromUSB version 0.2.1 and it works very well. One question : if I use an USB HDD instead of an USB key, the USB HDD is seen as fixed disk, and on XP setup the internal IDE hard disk where XP will be installed to as seen as D:. Does it means that after installation D: is the system drive letter ? How it would happen if I remove the USB HDD and boot from the internal disk? I would like to have C: as system drive for the XP to be installed to the internal disk. Is it possible? Thank you.

This is not correct. Two examples: 1) Linux: USB stack is loaded using first BIOS USB with initrd/kernel (less than 5MB). Then the USB stack uses protected-mode USB 2.0 to exploit the hardware in high USB 2.0 speed. 2) XP/Vista: as with Linux, but without RAM disk in normal booting. This explains also slow boot on some machines with BIOS USB 1.x booting (although with USB2.0-hardware capable). Then afterwards the loaded OS will exploit the USB2.0 through drivers.

@Chozo4 Thank you for all your replies. I used the Maximum-Decim Native USB drivers version 3.3. How can I find the 2.24 drivers version? Hotplug is not a requirement since probably can plug them before booting. What I expect is to be able to boot form USB hard disk, and use it USB 2.0 speed. Thank you in advance.

Hello, Does anybody succeed in booting Win98SE (with Maximum-Decim Native USB 2.0 drivers) from external USB hard disk ? With the original drivers, I can get it boots OK, but only with USB 1.1 speed and without any hot plug/unplug recognition. Once applied the USB 2.0 drivers, Win98SE hang after few disk accesses at logo screen. No problem when I pulled back the hard disk out of its USB enclosure and put it back as internal IDE hard disk.

@spacesurfer Thank you for your tutorial. What I understand: XP (hd0,0), Vista is (hd0,1) and BartPE is (hd0,2). I have a question : Since E: is active, when booted with grub4dos in the menu.lst I did not see the makeactive directive for (hd0,0) partition. So when booting Vista (hd0,0), C: will not be assigned to (hd0,0) but to (hd0,2). Is is correct? And then it would cause problem to Vista. Maybe same problem when booting from XP (hd0,1). Am I missing something?

Acronis has a product called Acronis® Universal Restore : http://www.acronis.com/enterprise/products...al-restore.html

Here are other links: Fix for Disappearing CD-rom/DVD-ROM drives: http://support.microsoft.com/default.aspx?...US;q314060& http://www.theeldergeek.com/restore_missin...r_dvd_drive.htm There is a ready made .reg file, just click on it (much easier than using regedit): Missing CD/DVD Drive http://www.dougknox.com/xp/utils/XP_CD-DVD-Fix.zip

Personally ImDisk does not cause any problem, it does not create new physical hard drive (no partition). The problem was with vdk. Even if you close the drive (vdk close 0 e.g.) the associated physical drive remains listed and is seen by other utilities (vmware, drive snapshot) but they cannot access them (drive not ready). The only clean way is to uninstall vdk (vdk remove). By this way, all the physical drive descriptors are removed.

A tool to test your USB key (speed...): http://www.flashmemorytoolkit.com/

The problem is solved now, since with usb_prep3.cmd no more automatic logon. You have to manually logon. I used administrator, but maybe UserXP should be OK too. Yes, maybe mksparse to use at least (quicker). Possible, but the stick must be > 4GB due to the size of Vista DVD (almost 4 GB) and XP CD (could be bigger than 750 MB due to custom addons, service packs, slipstream etc..)

Found in jaclaz"s binifix.cmd: ECHO ERROR ECHO DefaultEntry is %DefaultEntry% ECHO. ECHO The rdisk value is ALREADY 0 ECHO You don't want me to set it as -1, don't you? PAUSE Excellent error catching! On real hardware rdisk(-1) would have bad consequences! :-)

Some statistics: XP installation duration: 45 min on my system On my same system, Vista Installation steps: Copying Windows files 2 min Expanding files 16 min Installing features 0 min Installing updates 1 min Completing installation 0 min Total: 19 min (+15 min on first startup (completing installation)). Apparently the gain over XP is by using the WIM format (install.wim about 2.5 GB), so less files copied, and file expansion is faster.

Some quick report: - 8GB key cannot be formatted FAT16. - Even after reformat with FAT32, 8GB hi-speed key is very slow during setup file copy (5 min to have only 10% copy complete). - Using low-speed FAT16 4GB key freshly formatted, setup file copy is lightening fast (20 s to get 10% complete, total duration (100% complete) = 5 min) ! No problem in the 3 steps (text mode, GUI mode, logon/start XP). And on third reboot, I did see now the icon user, so a force logon must be done (excellent), which will update boot.ini on the installed HDD and update the USB key (directory rename etc...). - \$WIN_NT$.~LS\$OEM$\useraccounts.cmd is modified to add some personalized commands (install extra programs), instead of chaining several .cmd in cmdfiles.txt. Curiously if I put my commands BEFORE the original lines (user account creation) it works better. Putting them AFTER causing some problems like gdiplus missing etc... It appears that it is related to user account creation. - By the way I chain the test with Vista installation from USB key: no problem so far. The key has to be bootable, with Vista bootmanager (bootsect /nt60 or using diskpart or using grub4dos to invoke bootmgr). The USB key content is a copy of the Vista DVD (almost 4GB). Again, congratulations to all the team, I am satified with current function. @jaclaz ktp is my other nick on other forum :-).

OK, after resetting ntldr attribute on my USB key, and after unmount all drives (vdk, ImDisk...) and unplug all drives, and replug USB key, I got associated physical drive letter. Then the script executes smoothly without errors and my key is prepared. So it remains to test in on real hardware, but normally success will be there. Report later. Edit: I tried this time with hi-speed 8GB key formatted FAT32, but curiously this time the file copy by setup is very slow, much slower than with 4GB key formatted FAT16 ! So I interrupt the process and rebuild the 8GB formatted with FAT16. Report later.

@wimb I tried the usb_prep3.cmd. Changes observed as looking at source: \usb_prep3\$OEM$\useraccounts.cmd no more autologon \usb_prep3\boot.ini multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="2. GUI Mode Setup Windows XP, Continue Setup + Start XP" /FASTDETECT \usb_prep3\usb_prep3.cmd + some other changes for nLite set xp_type=Home / Prof - RyanVM \usb_prep3\undoren.cmd \usb_prep3\ren_fold.cmd take into account drive letter E F G H I J K L Recommendation: \usb_prep3\makeBS3.cmd: maybe to upgrade from ::<Release 0.03 ALPHA 05/August/2007 to jaclaz's latest version: ::<Release 0.07 ALPHA 01/October/2007 Now the script usb_prep3.cmd got some problems at execution. Adding BTS DriverPacks if they were used .... Lets copy everything to the USB drive, may take a while ( about 5 minutes ) Press a key to continue... N:\txtsetup.sif N:\NTLDR Access denied Add entry in BOOT.INI to launch TXT Mode Setup .... A needed file is missing File U:\setupldr.bin is missing Press a key to continue... missing file 1) Access denied N: tempdrive U: USB key The acess denied is during copy from n:\ntldr to u:\ntldr which already exists in my key (I upgrade the key by re-executing the script, so no new reformat on the key done). And u:\ntldr has read-only, hidden, system attributes on it, hence problem. 2) A needed file is missing ECHO Add entry in BOOT.INI to launch TXT Mode Setup .... CALL makeBS3.cmd %usbdrive%\setupldr.bin /a "1. TXT Mode Setup Windows XP (Never unplug USB-stick) " 3) File U:\setupldr.bin is missing Error 2) and 3) are mysterious, but after some investigation I found out that my USB key does have a drive letter but do not have a physical drive number (\\.\physicaldriveN in dsfo/dsfi notation). For example ptedit32 did not see the disk (nor HDHacker of course, nor dsfo/dsfi/mbrfix). So probably MakeBS3.cmd failed due to this. This situation arrives sometimes on my machine, apparently due to a lot usage of vdk/ImDisk, mount external USB HDD plug/unplug, QEMU, VMware etc... I have to reboot to get a clean situation where plugging the key does create a new corresponding physical drive letter. Other remarks: 1) We probably need a kind of execution log (maybe simply by just capturing all usb_prep3.cmd output (stdout/stderr) with "tee" (tee.exe under Win32), e.g. usb_prep3.cmd | tee usb_prep.log), so that by browsing the log problems can be spotted easily (and for audit/history also). Without the log, some script (like MakeBS3.cmd uses cls command so the output is cleared in the window command prompt, so even if I have a big screen buffer, I cannot use copy-paste to report/indicate needed messages output). 2) (optional) Maybe the script must check for errors (errolevel), mostly in copy/xcopy commands and stop execution on errors. My mentioned errors above are fatal for me. With the log in point 1), this is less important. But I agree that user of this script is a normally a technical person so he/she should be aware of those errors, and the script not being a GUI application cannot handle all error situations. 3) Probably we need to ensure that all important files copied/modified (mostly in root: boot.ini, ntdetect.com, ntldr, setupldr.bin) could already exists with read-only, hidden, system and hence to handle them correctly (reset all the attributes first). 4) Maybe offer the option to delete the temporary image tempimage.img (after the dialog to accept unmount the temporary drive). Summary: - I will re-experiment after reboot to get physical drive number associated with USB key - I will temporarily reset ntldr read-only, hidden, system attribute on my key. - I will re-experiment the script and report here.

@ilko_t OK I understand and agree with you. My separate Step 3 entry in boot.ini of the key is useless since the key as you said will still be rdisk(0). Note that the logon is important to rename and change the ini entry to z-1. Since in my installation after GUI setup I do not see any logon, I access directly to the desktop (maybe with a default user ?). So after checking that boot.ini and folders are not changed/renames, I do a manual close session and then logon as administrator. And then I did verify that c:\boot.ini is well changed (z-1), and the two folders on the USB key are renamed back correctly. Question: is it really z-1 or hard coded to zero (since z=1?). What happens if I install to another partition then the first partition? also maybe on another disk than the first disk, e.g. HDD2 (USB key, HDD1, HDD2) ? Could you confirm that these cases are covered ? Also is there a project to install Vista from USB key, or is it already covered? As far as I understand, it seems that for Vista it is easier, since normally you prepare/format the key under Vista (diskpart/bootsect), copy all the files from Vista CD to the key, that's all. Is it true?