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

MakePE3: jaclaz

Something like these: has been installed on that PC. Cannot say more, up to you to find which program it is. jaclaz

Naaah, you first... jaclaz

If this is what you need you can probably find it here: http://www.partitionsupport.com/utilities.htm You can use FINDPART FINDFAT, CHSDIR or CYLDIR utilities. Something that may be of help is this batch: (probably needing to be fixed/adapted/whatever, as it was left in a semi-abandoned state before testing/bugfixing could be carried) jaclaz

OK, maybe I am getting an idea of the situation (though I am not entirely sure HOW that could have happened ). So, given that there are THREE parts of the filesystem (let's say conventionally "thirds"), first "third" physically before the $MFT and second "third " after the end of it and before the $MFTmirror, and third "third" after it till the end of the volume. Are files in ALL "thirds" displaced by the same amount of sectors? 1985*512=1016320 which is at first sight a "strange" number 1985+63=2048 and 2048*512=1048576 sounds more "like it". Let's start thinking in terms of "Lego blocks". We have 7 "main" blocks: bootsector (16 sectors in size, but the ONLY meaningful one for this is first one) "first third of data" $MFT (size depends on overall size of volume) - normally this is at LCN 786432 dec "second third of data" $MFT mirror (first 4 records of $MFT if I recall correctly) - normally this in the middle of the volume i.e. Size_in_sectors/cluster_size/2 third "third" of data backup bootsector (after the end of the volume, i.e. outside the filesystem but within partition space) All addresses are relative to beginning of the volume, so (and I am not sure to have it right) if you have a file that should be at Absolute sector (say) 10,000, you instead find it at Absolute sector 8,015, you need to have the beginning of the volume (actually the bootsector or block #1 above) 1,985 sectors BEFORE. If it's the other way round, i.e. you find the beginning of the file that should be at Absolute sector 10,000 on Absolute sector 11,985 you need to have the beginning of the volume 1,985 sectors LATER. In other words, you need to check: the current MBR entry for that partition the current bootsector that you can find at the first sector of address specified in the above the backup bootsector that you can (possibly) find on last sector of the partition, i.e. in last sector of address specified in the above Then: Verify that bootsector and backup bootsector are the same. Verify that at the "other" theoretical address, i.le. if "current" is at Absolute sector 63, check at Absolute Sector 2048 or, viceversa, there is another bootsector (with different data). Correct the MBR to set the partition start at the correct offset. If you can post these sectors (make a RAW copy of each of them, name them meaningfully, compress them together in a .zip file) I can have a look at them and give you some more "exact" help. A tool suited for this kind of checks is tiny hexer (optionally making use of my "Structure viewers" for it), reference: http://reboot.pro/8734/ but you can of course use any disk editor you are familiar with. jaclaz

Another (italian) happy bunny in the basket! In the meantime, jaclaz

Well, he also got a reply on the "other" forum, that strangely reminds me of this : http://www.metacafe.com/watch/824477/6_volt_battery_hack_youll_be_amazed/ A VID=8888 PID=8888 as well as VID=6666 PID=8888 or similar are "typical" of "fake" USB sticks. Someone also submitted test results here: http://usbspeed.nirsoft.net/?pdesc=UDISK+USB+Device&vid=34952&pid=34952 (plese do note the Write speed of that 32 Gb stick ) Most probably the only way to know what is inside it is to actually and physically open the stoopid stick, example: http://www.myblog.bloggybloggy.com/fixing-hacked-usb-memory-stick-08-04-2008/ jaclaz

I am not sure to get what the problem is. If the data is accessible, the easiest would be to backup the data, re-format properly and restore. The $MFT and $MFT mirror can be *anywhere* as long as their location is correct in the bootsector. The bootsector is first sector and cannot be moved. The bootsector backup is last sector (actully outside the filesystem) and cannot be moved. Changing contents of the $MFT is tricky business (and simply FORGET about doing it "manually"), Can you expand on the actual problem? jaclaz

The links you posted are invalid. Please just run ChipGenius and post a screenshot of it. DO VERIFY the link you post by clicking on it after you posted the message! jaclaz