Robou

I need some time to grasp what you published and as 1st- I'm colorblind and need someone to point out the difference between bold and red and 2nd- My house is occupied with guests from Greece and Finland who's interest is far from computers and USB-sticks I'll be back in a few days.

@Jaclaz: Ooooh miss Scarlet, I don't know nothing about no births and no babies. But you were right to point out that I pointed out that there WAS some identity. It just doesn't stick for some reason. @Ilko: Here it is. All for science's sake. Issue/problem: As far as I'm concerned it is an issue now. With your help it has been solved as a problem. It's you who have a problem, because building the Migrate.inf your way obviously has a flaw. Be it brought to daylight by an obscure SMI flashdrive bought somewhere in the outskirts of Spain. After I brought it back to the real world through MkMigrateInf it acts like a charm, no 2 GB barrier at all! For the time being, let's forget about this barrier, it probably just happened as a result of all the messing around. If it shows up again, i'll post, less naïve as I started this ordeal. Migrate_ListUSB.7z

With the original migrate.inf it is D: With the fabricated one it is U: Worthy of your love?

@ Ilko: It is confusing, I agree, the more because I try to make a logical story out of a whole bunch of activities late at night with some booze on the side. But D: is the first available drive letter. So whenever a flashdrive is plugged in it is assigned D:. A second simultaneous one becomes assigned H:, which comes next as available. Now all the drives are unplugged. If I replug SMI, formerly known as "Unknown" (to make things easier!) it always claims D:, even when it has been H: before, whereas any other drive returns to H:. Between every test I cleaned the registry with Devcon and restarted. @ Jaclaz: Sure it is fun. Unknown territory! It would be more fun if the links would work, Firefox complains the redirection will never complete for the Russian site. But I get the idea and make the bastard act as it should in this context. Only then I'll use it for garbage. I'm convinced that everything I experience is far from normal. Normal is what I learn from all the posts concerning this subject. But nevertheless, obviously these occurences can happen. I'm also convinced that all your knowledge as published in your posts will eventually get me out of problems. So please, consider this as purely experimental. I feel ashamed by calling all this attention.

Unknown seems to have some identity: Device Name: +[x:]+USB Mass Storage Device(General USB Flash Disk USB Device) PnP Device ID: VID = 090C PID = 1000 Serial Number: 5&&167ABEC4&&0&&4 Revision: 1100 Device Type: Standard USB device - USB2.0 High-Speed Chip Vendor: SMI Chip Part-Number: SM321~SM325 Product Vendor: (N/A) Product Model: (N/A) But please, don't give it too much thought. As a matter of fact, I'm on the verge of putting all of the PQI's and this one aside because so much formatting and testing has been done with them that I don't trust them any more for a serious job like this. And it may very well be that with a decent modern controller the 2GB barrier is gone. But nevertheless, I learned a lot, the cfadisk integration will be tried out soon but I probably will stick with my "crowbar" solution as in USB.7z because it can be switched back after the job and the OS will act as normal again. BTW, if used in a batchfile it is advised to add some ping's between the lines and at the end, it may take some time for the second partition to become available.

@ilko: "Unkwown" reports no serial number. The computer has not been set to ignore it. So apparently this is what breaks assigning the drive letter to "U" and beyond. Aside: It may be desirable to add one or two letters, as some MSCR's contain three devices and can't easily be switched off (notebooks). Any flash drive gets D: assigned, unless a second one is plugged simultaneously, then the next available letter is used. Replugging this second one after a restart makes it return to it's assigned letter. Thanks for pointing to Uwe Sieber's site. I'm using his USBDLM for years now. @cdob: This testing happens on a MS-7207V2, my garbage bin, although on a brand new ASUS-based notebook my confusion started. I must agree, not very trustworthy BOISes, but the MS-7207 has been eating everything so far. I used 900MB for storage, enough for the XP-source and some initial stuff like DP's. Both: I didn't go into the cfadisk matter for being too tired, tried the dummydisk way, which seemed pretty straightforward. But it didn't work, even put Dmmydisk.sys in Dosnet.inf, doublechecked the typing, but it never showed up in the installation. So I took the crowbar and initiated the first script with the commands as in attachement. It does the job, the second partition shows in seconds and I can go on. I'm glad I mentioned this problem-to-come, both your responses saved me days of digging into a technique I'not familiar with. The phenomenon of the 2GB still exists, I could work around it thanks to your great help, but if either of you wants me to check things out I'll be glad to, if it were only out of curiosity. Off topic: The "Unknown" was bought by a friend of mine in a photoshop in Spain, as medium for emptying her cameracard. (Don't ask.) Being back home she asked me to download the pictures on her computer, on which, as with all my installations, anything about autorun had been switched off. The flashdrive contained an autorun.inf and about the meanest trojan possible, which turned out to be widely spread in Spain by that time. It was easy to make the drive switch owner. Now here is my punishment! USB.7z

Weird it is.. Both the flash drives were checked with RMUSBPrep for true size. They act the same on two different computers. The driveletter is D: in the Mounted.7z, persistent after replugging. As for the extended partition, this turned out not to be necessary after all, because a second primary partition wasn't seen at setup so no drive letter interfered. I'm thinking of integrating the Hitachi filter driver (cfa) and check for the correct drive letter in the script after install. The only hassle is editing the .inf for every individual flash drive. So changing the removable bit could be a better idea, but then the extra drive letter will show up during setup and may cause problems. I'll try it out. Unless you have a brainwave...

You are very attentive, thank you for that. I already composed the following post, you were ahead of me: I just discovered that, even when formatted with NTFS, the partition on the stick holding the installation source shouldn't be over 2GB. At 900MB, no Overrides, PQI acts flawlessly, "Unknown" still is assigned D:, wonder how come they act so differently. My only problem now is to put an extended partition on the PQI holding a logical partition (in order to avoid a mess in driveletter assignment) which in turn holds all the stuff needed to copy over during installation. Matter of finding out and changing scripts, I hope. Rest the question why "Unknown" doesn't confirm to the migrate stuff. For the moment I'm more curious than desperate, what may change when I don't succeed in putting a second partition on the PQI. And answer your post, after installing XP with the "Unknown": The PQI, which caused the BSOD, I had the same suspicion about, so I reformatted it with the HP program and ran different test, amongst them chkdsk, no problems. Being larger than 2GB turned out to be the culprit. The installation finished, I attach the exported .reg from the new installation, more accurate than from "any" computer, I think. Mounted.7z

Thought I did. Must have missed the final click.Logs.7z

For years it's gone well, Nlited XP installation with DP and updates integrated. RMUSBPrep NTFS, 2 partitions, then WinSetupFromUSB. This installed beautifully on a pre-partitioned harddrive with three primary partitions by means of a lot of scripts and .reg files. In this way it finished with a System drive, a Data drive and a Misc drive, the latter for all the to-do installation sources and being FAT32, fully accessible.. The 2GB Sandisk Cruzer I used became too small for the purpose so I decided to use a bigger one, had some PQI's laying around and a unknown brand. None of them does the intended job: With the PQI's the initial start of Windows gives a BSOD as Unmountable_Boot_Volume with stop error ED and the undefined one is mounted with drive letter D in stead of U,V or W, which renders it unusable because my scripts expect C, D and E for the hard drive partitions. The Sandisk acts as expected with exactly the same procedure and computer. The versions of WinSetupFromUSB differ only in the fact that Beta7 works with a Asus-based laptop as was meant by the developer (Except for the hybrid video of course, but this is a matter of DP). RMPrep was tried with many possible combinations of Filesystems and Overrides, reducing size if appropriate. Two logs are in the attached archive: One for the PQI and one for the unknown brand. After days of struggle I sincerely hope someone can tell me where I'm goofing. It should be me, nowhere I found a clue to similar problems. I suspect the firmware in the sticks used. But then, there's no problem in booting.