jaclaz

This is very nice. Yes, but you see, under XP diskpart or disk management won't allow the partitioning, and you need a third party tool anyway, be it a "RMPREPUSB like" utility or the Cfadisk/dummydisk driver or anyay something "designed" to have the stoopid stick properly partitioned and bootable. I don't remember having noticed any problem with "drive number" in the BPB, but as said it is perfectly possible that it does create problems. That's why I said : I mean, we do know that in order to set the stoopid variables, the RC needs to access ONLY some very limited parts of the Registry: it is very possible that bootcfg looks for "something else". For testing purposes, try copying a "whole" Registry to the "\whatever\System32\config" directory (but probably also some keys in it needs to be changed) Sure , not at all a problem for this use/purpose of this project, which is anyhow reserved to people that know where their towel is.

It doesn't work this way. If I ask you to do something, there are REASONS why I ask you to do that particular thing (and NOT another thing) and I would appreciate if you could: do what I ask you to do do NOTHING else report EXACTLY what you did and the result you had My crystal ball is (again) out of tune and I cannot know what is your current setup unless you describe it EXACTLY, COMPLETELY and FULLY. The DTIDATA tool screenshot you posted lately shows an incorrect partitioning, that may cause DATA LOSS in some cases/when some tools are used. Of course you are perfectly free to use the disk "as is" . WHICH version of WinsetupfromUSB withGUI are you using? The Beta 1.0-7 has a rather complex mechanism of booting through different .lst files. The settings you need to modify (if possible to solve this issue with a simple Edit) are AFAICR either in winsetup.lst or the various 1.lst, 2.lst, etc. jaclaz

Forget about it (for the moment), we will find and fix that when we will have solved the "other" problem. Any difficult part in: In first line you have: No/32/33/NTFS/41/5/740/2048/11888640 and in second line: No/41/6/740/FAT 32/254/63/1023/11890688/419471360 Change first line to: No/41/6/740/FAT 32/254/63/1023/11890688/419471360 Change second line to: No/32/33/NTFS/41/5/740/2048/11888640 Is the above difficult? ANYWAY, DO NOT DO IT, your current partition data is also invalid. Redo from start: Use ONLY Windows 7 Disk Management. Delete EACH and ALL partitions. Create a new partition, around 6 GB in size, partition it as NTFS, make it ACTIVE. Create a new partition, around 200 Gb in size Exit Disk Management. Use either of the mentioned FAT32 formatting apps to format the 200 Gb partition (drive). Verify that you can write and read files on both partitions. Use the partition tool to EXCHANGE the data in first two lines. Reboot and check that you can still write and read on both partitions. Copy a movie or whatever to the FAT32 partition and test if "usb divx reader" works with the disk. jaclaz

You are perfectly right about the bizzarreness of having the docs only in the stable and as well about the fact that the info is not much highlighted (please read as NOT highlited at all). As often happens the Beta should have led quickly to a "new stable", but we are still at Beta 7. About the .exe I am not so sure. I mean the idea of having a stable and an experimental beta should be that people should ONLY use stable at first attempt(s) and only later try the beta. The MS system sweeper is nothing but a (dumbed down) WinPE 3.x, so, yes, it will "conflict" with *anything* BOOTMGR/BCD based. See here: http://reboot.pro/14487/ If you want multiple Vista or 7 based thigies, you may want to take another "path", see the above and: https://sites.google.com/site/rmprepusb/sweeper https://sites.google.com/site/rmprepusb/tutorials/multiisoimdiskautounattend (and there are more similar on the RMPREPUSB site) You need to take the whole thing in a "historical" view, the "Install Windows from USB" was once named "Install Windows XP from USB", that was (is) the tricky part. Installing Windows 7 from USB is relatively easy, though finding a way to manage it through a .iso wasn't actually straightforward : http://reboot.pro/9076/ but if you only use/have 7 and one or more PE's the pointed to approach is probably more suited to your needs. BTW, another NOT highlighted piece of info on first post of the thread reads: that also brings you to the RMPREPUSB site, though to an older approach. Things are ever-changing and it is difficult to keep things together and in a "tidy and ordered state" .... jaclaz

Happy you made it. jaclaz

Are you familiar with a hex/disk editor? Or can you use this thingy here: http://www.dtidata.com/ntfs_partition_repair.htm or a similar app. The idea is to try and see if we can "trick" the "usb divx reader" into accepting the partition even if it is not "first" on disk. Most of the times these kind of thingies look for the partition that is in first entry of the partition table (no matter if it is actually first partition on disk). So you can try the following: create a 6 Gb partition NTFS crete a 200 Gb partition FAT32 run the tool and jolt down partitions data edit the partition table, copying 2nd entry contents over 1st one and 1st entry contents over 2nd one see if the "usb divx reader" sees the FAT32 partition now. jaclaz

Verified. Debug has no direct disk access under any of NT/2K/XP and latrer OS. I start to think that there is nothing capable of accessing a disk sector in "default" MS OS install so, it's a dead end. jaclaz

On WHICH environment? Maybe you are trying to use a WinPE 3.0 instead ofa WinPE 2.x? (read just a few posts above yours) jaclaz

Yes, but you are missing the point. For some reasons (that we are trying to understand) grub4dos DOES NOT recognize *ANY* partition but the first one as validly formatted (or if you prefer as containing a valid filesystem). This means that there is no sense in forcing grub4dos to search in second partition, since right now it CANNOT ACCESS it. The 200 Gb size is HUGE. You can try (as an experiment) to reduce the size of first partition FAT32, so that it is around 120 Gb. It is possible that grub4dos (or your BIOS) does not, for any reason, provide correctly 48 bit LBA addressing, so anything above the 48 bit LBA limit: http://www.48bitlba.com/overview.htm becomes "a suffusion of yellow". You can use (again WHICH WIndows are you running?) any of: http://tokiwa.qee.jp/EN/Fat32Formatter/ http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm to format the partition under Windows (definuitely 2K/XP, cannot say Vista or 7). jaclaz

To the user (and expecially to the newbies) there is no "real" difference between the "stable 0.2.3" and the Beta 1.0 - 7 (the latter has a different internal mechaninsm and some added features) so the recommendation on first post: still stand. You should get familiar with the "general idea" which is detailed in the mentioned docs, then the "transition" to 1.0-7 should be a snap... jaclaz

The second, third and fourth partitions are NOT formatted with a filesystem grub4dos recognizes. The fact that they do have the "partition type" set to (respectively) 0x07, 0x83 (which BTW is NOT "empty", but the partition ID for the Linux native partition) and 0x07 only means that that entry is written in the partition table, but the "filesystem unknown" means that grub4dos doesn't "recognizes them". Are you sure that the first is "exFAT"? The partition type is 0x0C (which is FAT32 LBA) and the version of grub4dos you are using DOES NOT support exFAT. Anyway, leave (for the moment) ANY other tool alone. Connect that hard disk to your Windows (which version, BTW?) machine. Try opening the disk with Explorer, does the second (apparently NTFS) get a drive letter? Can you see it's contents? If yes, copy them to some other disk/drive, then run the FORMAT command on that partition and after it has finished, copy back to it the files. Copy back first the files in root, like NTLDR, BOOT.INI NTDETCT.COM, GRLDR, etc. How big is the first FAT32 partition? Could it be that it *somehow* "pushes" the second anf following ones "beyond reach" of gub4dos? (it is definitely not a grub4dos limitation, but it may be a BIOS one) Try again and see if now running the geometry command the output changes. jaclaz

I do not remember the problems you describe with simply partitioning/formatting a USB hard disk (i.e. something that is seen as "fixed") with XP, but I may well be wrong. This is very neat, I will remember this! Luckily this wasn't necessary for me, I was able to access both C:\ and the USB stick and copy a file over. I can see how this trick can be useful though. Just a guess, mind you, but if you have a "fake" windows install on the booted USB device (see above), if you use BOOTCFG to add it (and NOT the real one) the ARCpath should be correct: http://support.microsoft.com/kb/291980/en-us Since you are into experimenting, another thing that you may want to check is whether the use of the debug.exe (that comes with XP) is possible to do some "sector manipulation". A rough example is here: http://www.911cd.net/forums//index.php?showtopic=7233 http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/debug.mspx?mfr=true If a batch file is not considered "third party tool" under your "Rules", it may solve the "formatting problem" and/or the "loader name", that is IF debug allows writing to sectors under XP and/or Windows 7. Another option (lame, I know) is to make a copy of SETUPLDR.BIN renamed to BOOTMGR and one renamed to NTLDR and when you run Recovery Console, issue a FIXBOOT command. But even this "cosmetic" change won't change what I see as the "real" issue, that of Renaming a "basic system file", reasons here: http://reboot.pro/2362/ http://reboot.pro/5209/page__st__6 jaclaz

No, you still have to ground the TTL thingy to the hard disk (the third wire besides Tx and Rx) to be on the safe side. The idea is that the ground "0 level" of the PSU is connected to the USB port ground, the USB port ground is connected to the USB-TTL thingy ground and the USB-TTL thingy ground is connected to the hard disk "third pin" ground. On the other "side of the loop, the ground "0 level" of the PSU is connected to the (black) wire part of the hard disk power connector. Since the "third pin" ground is (internally to the hard disk PCB) connected to the (black) wire part of the hard disk power connector, the loop is closed. In theory, if ONLY one power source (the PSU) is used, the "third pin is not *necessary*, but since it costs nothing (or next to nothing) to connect it too, why risk having a Hyperteminal full of garbage characters? As always, remember : jaclaz

But this happens because the TARGET drive is USB connected, doesn't it? I mean, have you tried to have that same SOURCE stick using (on the Toshiba) the USB hard disk as TARGET? I.e. that should be EXACTLY the situation when you need to run the usbbootwatcher service: http://www.911cd.net/forums//index.php?showtopic=22473&hl= Of course not, but the Qemu VM is (or can be set) as plain a PC hardware can be, i.e. standard VGA and "Standard Dual PCI IDE Controller", and that would be compatible (if you have the option in BIOS) to "IDE compatibility mode". jaclaz

WHY? I mean, it is already complex enough to install from "normal" media TO USB device and to install FROM USB device to "normal" media, and you are trying to install FROM USB device TOUSB device directly? I like people that like to live dangerously! Anyway, we need to separate this thingy in two. Forget about: WintoFlash USB Multiboot 10 usboot.org Try using WinsetrupFromUSBwithGUI to create an install USB stick. Test that it works by trying it in Qemu (+Qemu Manager). Then start reading here: http://www.911cd.net/forums//index.php?showtopic=22473&hl= (the WHOLE thread, not just first post) It may work, or it may not , there are probably several factors that can contribute to the success of the attempt, mainly timing problems. Some are listed here: http://reboot.pro/14427/ (and links within) Still, the mentione XP image approach by Wimb might be more starightforward. jaclaz

I am not sure to get what the problem is. If I get it right, you installed the XP TO the USB hard disk (and to do this there is NOTHING connected to Wintoflash, WinsetupFromUSBwithGUI or USB Multiboot 10)? (or at least the above is your final GOAL) Why don't you try a suitable app, which in this case is either the usboot.org thingy: http://www.usboot.org/tiki-index.php or -maybe better - the Wimb's tool: http://reboot.pro/9830/ jaclaz P.S.: Cannot say about anyone else, and particularly about jacklaz, jaclaz is NOT feeling insulted.

VLK license only available to business. nlite not licensed for Commercial use. Do I see an oximoron here? jaclaz

Just for the record: IF you work with windows 7, you can use bootsect.exe /NT52 allright (and have the VBR invoke NTLDR) Since you boot anyway to Recovery Console, nothing prevents you to run BOOTCFG: http://commandwindows.com/recovery-console-commands.htm You may need a "fake" Windows installation , something similar to my "no more CATCH22" trick, though. Reference: http://www.911cd.net/forums//index.php?showtopic=20983&st=25 jaclaz

Yes, AS LONG AS you power the drive with the SAME PSU of the computer to which you connect that USB-TTL converter. Otherways you will need to GROUND the "other" PSU to the device (and GND of disk). And of course BEFORE the above, you need to install the driver and verify the adapter through a loopback test. Since you seemingly omitted to read the read-me-first, NOW could be the right time: Do also read the FGA's: jaclaz

Somehow, you have either a botched install of grub4dos (UNlikely) or a non-standard second partition. The screenshot you posted actually says that. It is possible that it is a Qemu related problem, but, again, UNlikely. What the HECK is the second harddisk with size 0 bytes? (which also gives an error - of course) Try using Qemu-manager which is easier to configure than Qemu "alone": http://www.davereyn.co.uk/download.htm Try putting a copy of the GRLDR on first (FAT32) partition and to it's command prompt run: geometry (hd0) [ENTER] and post results. jaclaz

SET %OLDEST%=%%A Sets the VALUE OF the OLDEST variable to have the VALUE OF FOR loop variable A. SET OLDEST=%%A Sets the OLDEST variable variable to have the VALUE OF FOR loop variable A. Or, if you prefer, the actual variable is called "OLDEST" and "%OLDEST%" is expanded to the VALUE it was SET to. Apart from this, the FOR /F needs a modified command.com (actually a CMD.EXE). See here: http://www.computerhope.com/forhlp.htm http://reboot.pro/2392/ jaclaz

...back to square #7 : jaclaz

Partially disassembling laptops (if needed) and THOROUGHFULLY cleaning the fan and all air ducts/intakes/etc. is part of the "standard maintenance". I have seen more than one laptop where a little bit of thermal paste between processor and heatsink made miracles, as "original" tends to dry up (and same applies to GPU) jaclaz

How can we know? This amount (more or less ) to: I frimbled the card, then trockled it, and I get wintryqs instead. Please : Post an EXACT, DETAILED description of what you did, AND an EXACT, DETAILED description of the disk error(s) you get. Compare with: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/problem-report-standard-litany.html jaclaz

As a side note, DELL Oem Cd's have been re-known to be a PITA. This may (or may not) be related, when you create a BartPE from a DELL Oem CD, you need some fixes, cannot say if the same may apply to a "setup from USB". Some info here: http://www.911cd.net/forums//index.php?showtopic=15138&st=29 http://ubcd4win.com/forum/index.php?showtopic=14452 jaclaz