jaclaz

Difficult to say. Since you are working on an image (and you can always make a new image exactly as the one you have now in your hands - or at least this is the idea), you have nothing to loose in writing the changes and use some other tool on the image. Most probably, now that you have recovered the "base directory structure" it would be possible to recover manually the pointers to their contents, but is not something that you can learn from a couple posts on a Forum (or that I can teach you quickly). Your best option as I see it, is to throw at the semi-recovered image any tool you can find. jaclaz

Another non-Rusian speaking, but apparently the issue/solution is the following: a LCD display screen has been replaced the replacement screen has a much lower brightness than the old one brightness adjustment to max is not enough Apparently inside the screen there is a programmable chip, let's call it a "flash" that holds settings. You need to read the old settings from the "old screen" and re-program them on the new one, by using a hardware flash programmer for 24S02 series chips. jaclaz

Yep, the procedure is correct. This way you have: a completely blank first FAT a second FAT in which First sector is blank and all the others remain the ones from the "old" image Now it all depends on how much of the second FAT has been overwritten by fbinst. (and also how the data was organized on the "lost" partition). TESTDISK might be able to make some sense from it: http://www.cgsecurity.org/wiki/Advanced_FA...pair_FAT_tables You can also try to leave both First and Second FAT (i.e. overwrite first 63+32 sectors only) with the ones from the freshly created image and try again TESTDISK, and then some other data recovery program. PHOTOREC is still an option, if anything at a "higher level fails", expecially if the drive wasn't much fragmented. jaclaz

Start Sector is 61432560. Now use MKimg/MBRbatch to make on a NTFS partition a new SPARSE image (it will occupy a bunch of Mb only): http://www.boot-land.net/forums/index.php?showtopic=3191 http://www.boot-land.net/forums/index.php?showtopic=5000 Size: 61432560x512=31,453,470,720 Geometry: 255/63 Format as FAT32 LBA (0C). While the image is mounted, check with tiny hexer the FAT32 bootsector. You have in the image 63 hidden sectors+ (possibly 32) Reserved sectors + 2 x (possibly 15352) sectors per fat table. You need to extract from the new image: the hidden sectors (63) the reserved sectors (32) the sectors for first FAT table (15352) first sector of second FAT table (1) Verify the above values with the ones of the image you created, 63+32+15352+1=15,448x512=7,909,376 bytes Overwrite first 7,909,376 of the 30 Gbish image of the "formatted" hard disk with those extracted by the brand new image. Then run TESTDISK on the resulting image. It is possible that you may able to recover a number of files this way. jaclaz

It seems to me everyone is making this more complicated that needed. We are talking of a simple dual booting between XP and 98. There is no actual "need" for grub4dos or any of the other "advanced" bootloaders. NTLDR can manage the thing easily. You might need bootpart as a useful tool: http://www.winimage.com/bootpart.htm Read the appropriate guide here: http://thpc.info/dualboot.html here: http://thpc.info/dual/dual_xp_2k_nt.html or here: http://thpc.info/dual/dual_9xme.html jaclaz

Yes. No, it won't affect a file based recovery, as long as you can verify that what TESTDISK has found really resembles what you had before. But it is advised that you anyway image the first (missing) partition, you only need some 30 Gb (which I hope you have somewhere available. An explanation of the situation, and of the problems it caused (and their resolution) fbinst writes roughly 8 Mb of data for it's peculiar partitioning scheme. What is lost is: MBR (and Partition table) 1 sector hidden sectors (usually 62) FAT32 bootsector and hidden sectors (possibly 32) First and probably part of second FAT table. for such a volume, fat should be around 15352 for each table If my estimation is correct: 63+32+15,352+15,352=30,799*512=15,769,088 Overwriting 8 Mb should leave most of the 2nd copy of FAT "as it was". Partial recovery of a FAT table is not straightforward, but it should be possible. If you post as an attachment the MBR as it is recovered by TESTDISK (or the DATA within it), a good way is to use Tiny hexer and my PTview Structure Viewer: http://www.boot-land.net/forums/index.php?showtopic=8734 and save the .htm Or use HDhacker to save first sector of PhysicalDrive: http://dimio.altervista.org/eng/ and compress it in a .zip archive. I may be able to give you a couple of hints on what to do/where to look for the partial FAT. The amount of success you will have with PHOTOREC (or other file-based recovery) greatly depends on the level of fragmentation your drive had and on size of the files that were on it, and it could be an additional attempts once (and if) some files are recovered through a "fixed" FAT table. But we need to have that 30 Gb or so data imaged, as we need to change some DATA in it, and it may make things worse. jaclaz

Also: http://www.ext2fsd.com/ jaclaz

First thing: DON'T PANIC (assume the above to be written in large, friendly letters) Then, read here: http://www.msfn.org/board/usb-access-problem-t133933.html to get a "general" idea of the needed steps. Then try using TESTDISK on it. It is possible that the thing is simply dead, buit it is as well possible that it is only a partitioning/formatting problem that can be solved. IMAGE the stick with dsfo/dsfi or other app BEFORE any attempt on it. Another suitable app is this one: http://www.boot-land.net/forums/index.php?showtopic=7783 jaclaz

CATCH22 : Everyone can ask how to become a hacker. If you ask how you'll never be able to become one. jaclaz

They probably won't work. Both BootIce and RMPrepUSB can make "normal" ZIP-like partitioning/formatting. fbinst uses a "redundant" approach, similar, but different , from the "triple MBR" one (which may work in this case): http://www.boot-land.net/forums/index.php?showtopic=7932 http://www.boot-land.net/forums/index.php?...c=7932&st=6 Triple MBR: http://www.boot-land.net/forums/index.php?showtopic=7507 In other words, both BootIce and RMPrepUsb partition/format as "pure ZIP", the fbinst approach formats/partitions at the same time as "HD/Floppy/ZIP", in several places, "triple MBR" formats/partitions as "HD/Floppy" in several places. jaclaz

Yes/No. All that dummydisk.sys (or cfadisk.sys) does is "filtering" a "Removable" device to let it appear as "Fixed". In other words, it would be the solution if you had success with the USB HD but failed with the USB stick as it does nothing more than "mask" the USB stick as if it were a USB HD. Or, viceversa, if you succeed with the USB stick but fail with the USB hard disk you can rdummydisk to reverse the "masking". But if both "Removable" and "Fixed" fail, the reason should be somewhere else. jaclaz

Right now the stick can be mapped as (hd0,0) or (hdn,0). Translation: the stoopid BIOS reads as FD the USB stick "normally" partitioned/formatted <- it would be nice to understand how/which method it uses, I suspect it automatically "hides" a number of sectors apparently the particular fbinst formatting allows to workaround the issue fbinst "more compatible" formatting is enough to let the setup (once mapped by grub4dos) to read it as HD at least this should be the case if SETUPLDR.BIN+NTDETECT.COM go searching biosinfo.inf in \$WIN_NT$.~BT\ It is possible that the behaviour is similar to the old "compatible jumper" real ZIP disk drives had (read also the snippet about BIOS dependant hiding of first sectors): http://www.win.tue.nl/~aeb/linux/zip/zip-1.html Next move/suggestion to setup it as to start the install is yours. jaclaz

Yep, You should be past the initial problem. \$WIN_NT$.~BT\ (and \$WIN_NT$.~LS\) is the "normal" path for a drive seen as HD, just like it is \ (root) for a floppy device and \I386\ on CD. jaclaz

Are you trying to "sell" us a modified version of a tool we developed? Comeon, the tool you linked to is an old version of this: http://www.msfn.org/board/install-xp-usb-t111406.html with a couple non-redistributable files added, PERFECTLY UNNEEDED, as well as step #4 in your "tutorial". jaclaz

YES. http://homepages.tesco.net/J.deBoynePollar...no-answers.html Is your internal laptop drive a Seagate 7200.11? Or the equivalent Maxtor model? Haven't you got the doubt that you are asking, besides the wrong question also in the wrong place? Do you really think that the same solution for a specific Seagate/Maxtor desktop model can apply to a a Western Digital Laptop drive? And that people that try helping in solving the first problem will have all the answers for all the problems of all hard disk drives in the world? Have you tried to reseat the drive? The error you are having means, rather obviously: that the DATA connection between the motherboard and the hard disk is interrupted. This can be due to: bad cables (if any) bad connectors badly seated drive (connectors not making good contact) drive PCB burned laptop HD controller burned The only thing that you can do, before taking the PC to assistance, is to remove the drive and re-insert it. If the above fails, you can try with another drive, just to make sure that the laptop/cables/connectors are OK, and that the problem is in the hard disk. jaclaz

Good, then you can have in menu.lst entries: title NTLDR map (fd0) (hd0) map --hook root (hd0,0) chainloader /ntldr title SETUPLDR.BIN map (fd0) (hd0) map --hook root (hd0,0) chainloader /setupldr.bin title UNHOOK map --unhook Try re-adding the floppy contents and see what happens with second entry. Then you can try re-starting from where we were stopped by the (fd0) result: http://www.msfn.org/board/bios-seeing-usb-...79-page-12.html jaclaz

NO, I am actually leading. So you can now: What happens? jaclaz

Just convince yourself that your external hard disk is inside the PC, and treat it exactly as you would an internal one. The good ol' way is always having one primary and one Extended with 1 or more Logical volumes in it. But since you are going to encrypt a partition, I would create two primaries + the extended, this way you can easily make the second Primary bootable if needed. I would personally suggest to make a greater number of partitions/logical volumes in the extended, a 995 Gb partition is biggish and any operation you may later need to do on it (defragging/imaging/data recovery , etc.) will take AGES on an external (I presume USB) bus. jaclaz

Can you post the exact procedure you are following? Maybe there is something in it. jaclaz

Yep , it is just a term that has not be "standardized" since it is the result of the grub4dos command root, I would call it "grub4dos root" and it's value is represented not by "the root of the stick" but by "(fd0)". (I had no way to know if it was represented by something else, like (hd0,0), as an example) What happens if you type instead: and press [TAB] ? What happens with: map (fd0) (hd31) [ENTER] map --hook [ENTER] root (hd31, [TAB] What does it complete to? root (hd31,0) ? If yes, press [ENTER] chainloader / [TAB] can you see the tag file, and the other files on the stick? jaclaz

We are one step ahead. Not very far from before, but seemingly in the right direction. Now NTDETECT.COM is apparently not a problem anymore. The: is (unlike what it seems), good news. If you boot from the stick, when you are on grubd4dos, press c for command line and just issue: root [ENTER] What is the result? Unfortunately right now this: seems to me a "truism". Add to the stick a "tag" file, say "mystick.tag", an empty (0 byte) .txt file renamed will do. Reboot and run: find --set-root /mystick.tag [ENTER] root [ENTER] What is the result? jaclaz

What about gooogie? : http://www.gooogie.co.uk/?gid=502952&h...20four%20wheels jaclaz

You mean you used it just because you had it? I had to wait weeks before finding the right occasion: http://www.msfn.org/board/googel-t138944.html for this : http://www.msfn.org/board/googel-t138944-page-35.html Kids today: http://www.boot-land.net/forums/index.php?showtopic=1908 jaclaz

Just checking. Some motherboards may treat "small" sticks as "floppy" and "big" sticks as "hd", the "switch is usually around the 512 Mb size, so it is not your case if the 1 Gb stick is seen as floppy as well. On the other hand a smallish stick can more easily "fit into RAM" should we attempt a ramdisk approach. I am not fully sure to understand the behaviour you describe, as it is very different from past reports of people who had similar "floppy only" issues that I can remember, like th thread I linked you to. jaclaz

No. It's ok. jaclaz