jaclaz

No. You mistyped something. You just have established root on that volume, so it does exist. root (hd0,0) chainloader +1 should work. Anyway it doesn't matter, it was just a test to "jump over" the MBR code, if for any reason it had issues. The checking is "flawed" not because it is in any way "wrong" (it is not) but it relies on the behaviour of the BIOS, and a large number of BIOSes are "badly" coded or "non standard". jaclaz

Well, try using PHOTOREC ("companion" of TESTDISK): http://www.cgsecurity.org/wiki/PhotoRec apart the name, it will attempt to recover *any* file. Photorec attempts to determine the file type, in some cases it may get the "wrong type" (and consequently the file may not open properly or be not recognized by the "appropriate" software. A good idea would be to re-scan the recovered files with TRiD: http://mark0.net/soft-trid-e.html which has a more accurate "detection" engine. About filenames, consider that most "office" files do have some "metadata" that normally include the filename with which they were saved. If the filenames are important, you can scan them with a suitable program and recover this "metadata" (how exactly depends on the exact file types) Roughly, and on "Gb size" of the filesystem (FAT32), there are 2 sectors of FAT per MB. So, if the stick was "labeled" as 8 Gb, the beginning of 2nd copy of the FAT tables was likely around sector 16000, if it was 16 Gb, around sector 32000 and if 32 GB around sector 64000, which means that (in the hypothesis that you were actually very near the real physical size of the stick and what happened was a "wrap-around" of the 19 Mb), if the stick was 32 Gb, the second copy should be "intact", if 16 Gb it is "likely", if it was 8Gb there are very little or no chances. Having a look at the the image with Dmde: http://softdm.com/ won't do anyway any harm. jaclaz

I will try again (last time ): does 0.4.4 2009-16-10 version work? It is not difficult, a yes or no would be enough, though of course knowing (if no) if it behaves the same as the 0.4.5.c version would be nice. The error about the hard disk image is "normal", it depends on the way you made the hard disk image. *any* "real" hard disk image (in the sense of image of a"real" hard disk) and *most* hard disk images (if built without using some "special" care) will have some UNindexed space at the end. What grub4dos is trying to tell you is that the data on the MBR and in the PBR(s) of the volumes "cover" only 263088 sectors while your image is larger than that. You can "truncate" the image at the correct size. The DOS errror with EMM386.EXE is likely to be UNresolvable if not by doing several different tests. WHY do you need such a large DOS image (around 135 Mb)? jaclaz

The kernel has nothing to do (it is never involved in this part of booting) only NTLDR or the actual NTFS filesystem may have to do with the issue, but sincce the same worked in the VM, you are right it is a "hardware" connected issue. jaclaz

Yes and no. What happens, if it is one of the "fake" sticks I was referring to, is that data copied to it (once the "real" capacity of the stick is reached) "wraps around", overwriting the initial part of the stick. Since this area (initial part of a - I presume - FAT32 formatted) stick holds the FAT tables, it greatly depends on two factors: how big were the original FAT tables how many data has been copied to the stick "beyond" it's real size which sums up on "how many of the FAT tables is still there". There is still anyway the possibility to recover some data as "files" (i.e. recover not the filesystem but only it's contents), you will get most of the data (losing the filenames) unless there is "heavy" defragmentation. Without further data (what were the contents, wif you have only a few files that you are interested in, how big was the last copy operation on the stick) cannot say more about the suggested way to proceed. jaclaz

You are welcome. The issue here is that the file you posted is NOTHING like it should be. I will (exceptionally for you) take my crystal ball out of it's (dark red) velvet wrapping and tell you what I can see in it : you bought a largish (let's say 16 or 32 Gb) stick on e-bay or however on the Internet and not in a shop you payed for it a very convenient price you used the stick for some time without any issue, until one day (possibly today) you copied to it a few files - likely some .pdf's and .xls's and filled it up above around 2Gb suddenlly you cannot access it anymore Let me know how much of the above is correct and (this is the MAIN thing) approximately how big (roughly) were in total the set of files that you copied to it just before it wasn't anymore accessible. jaclaz

Change this: title Part 1 Install OEM XP - Text Mode map --mem /WinVBlock.IMG.gz (fd0) map --mem /WinVBlock.IMG.gz (fd1) map /dellsp4.iso (0xff) checkrange 0x80 read 0x8280 && map (hd0) (hd1) checkrange 0x80 read 0x8280 && map (hd1) (hd0) map --hook chainloader (0xff) title Part 2 Install OEM XP - GUI Mode map /dellsp4.iso (0xff) checkrange 0x80 read 0x8280 && map (hd0) (hd1) checkrange 0x80 read 0x8280 && map (hd1) (hd0) map --hook chainloader (hd0)+1 TO this: title Part 1 Install OEM XP - Text Mode map --mem /WinVBlock.IMG.gz (fd0) map --mem /WinVBlock.IMG.gz (fd1) map /dellsp4.iso (0xff) map (hd0) (hd1) map (hd1) (hd0) map --hook chainloader (0xff) title Part 2 Install OEM XP - GUI Mode map /dellsp4.iso (0xff) map (hd0) (hd1) map (hd1) (hd0) map --hook chainloader (hd0)+1 You should be able to get a little further (maybe). OR (better) instead of using the menu.lst, use command mode (on the second part) entering commands one by one on the command line and pressing enter after each one: map /dellsp4.iso (0xff) map (hd0) (hd1) map (hd1) (hd0) map --hook Here, instead of: chainloader (hd0)+1 Enter: root (hd0,0) You should get a confirmation message with some relevant data on the partition on the hard disk, if yes then: chainloader (hd0,0)+1 you should get something like "will boot NTLDR...." now enter: boot What happens? Please report the output of the above commandsbesides a description of what ahppens and if it hangs at which command it does so. jaclaz

Well, first thing you should make a copy of the stick. I.e. do what was already suggested in post #11: (this thread is quite oldish and some tools have changed but that post is still valid) To identify the \\physicaldrive number open Disk management, the boot disk (the one on which you C:\ normally is) will be disk 0, if you only have the USB stick (besides the bootdisk) it will be disk 1. (if you are in this "standard situation", i.e. without other disks and without one of those multi-card reader, the stick wiil be disk 1) Disk manager may (please read as will) ask you to "initialize the disk" (because of the missing 0x55AA), DO NOT let it do this. http://reboot.pro/12253/#entry106759 Or you could use datarescuedd, which is GUI and easier to use: http://www.datarescue.com/photorescue/v3/drdd.htm then use the dsfo to extract first 100 sectors (supposing the "full" stick image is C:\mystick.img dsfo C:\mystick.img 0 51200 C:\USB_100.img compress C:\USB_100.img in a .zip file and attach it to your next post. Once you have the image and posted the initial snippet, will see what we can do. jaclaz

, my hard drive is 7200.12 while all of these topics are entitled 7200.11.. therefore my main concern at this point is to figure out what tools suitable for my drive in case I'd have to buy them online, I'd need to order them as soon as possible because of the LONG shipping time.And believe me, I'm not setting around waiting.. I'm searching the web trying to find topics about the same drive, or 7200.12 drive. The same tools. Here we have a (actually the ONLY one) report of success wiith a 7200.12 that actually started the whole procedure thinking he had a 7200.11...: jaclaz

Nice to see you peeking around from time to time. About the adapter (and of course this is NOT an advertising of any kind) it seems like I found a good candidate (which does include a "Seagate" connector): at a "fair" price (depending on from where you manage to get it). jaclaz

Yep , the point being that if you want to "replace a string of text in a file", a tool designed to "replace a string of text in a file" often is more suited than using a "generic" (scriptable) command processor (as when using it, it may hit some limit or anyway take more time/resources than a, specific, dedicated, tool). As you might well know, I do believe that the simplest solution (for simple problems) is a bunch of lines in a batch (and I do have my part of fun playing eith them batches), but when you are trying to do something that is not simple and you have a command line, specifically designed for the specific chore, external tool, then it's usually better to use it . jaclaz

No. It is actually DEPRECATED (by me). Which you would have already learned had you READ the "Read-me-first": particularly point #10 AND the FGA's: particularly #6 BTW the whole idea of the above threads is to : jaclaz

The only explanation that I can find is that *somehow* your initial attempt (post #1) with TESTDISK produced a "wrong" MBR and/or PBR. The standard NT NTFS drivers finds *something* wrong and decides that the volume needs to be formatted. Dmde more or less "ignores" them, analyzes the filesystem, finds the "real" $MFT and thus lists all your files "as they were". (then some may be there and some may be in the missing part and thus unavailable). TESTDISK finds the (wrong) values it initially wrote and reads an "empy" $MFT. Dmde is not very "easy", let's see if I can guide you into checking the data. Once you have loaded the $MFT (open Dmde, choose the image, search for NTFS), you should have on the left pane [All Found], if you expand it clicking on the + sign, it should read the $MFT and show everything that has been found. Besides each file or directoryyou should have again a + sign. Double click a directory (where you know one suitable file should be), the contents of the directory should appear on the right top pane. Choose a (small) file of which you know the beginning of the contents (like a text file or a small program or a zip file), ideally use for the test something that belongs to the original XP install (and that thus it is likely to be in the first 134 Gb). In the lower pane you should see the hex dump of first sector of the file (if it is there, if it is not, try with another file that you can "recognize the beginning" and that "is there") and, in the first line something *like*: The LBA value is the absolute address of that sector, the vol.sec is the relative address within the volume. Do post these values. How much is LBA-vol.sec? i.e.: 89021727-89021664=63 in the above example. This would confirm that he volume starts at offset 63. How much is vol.sec/clus? i.e. 89021664/11127708=8 This would confirm that cluster size is 8 sectors. Then, do something "crazy" make a new backup of both the MBR and of the PBR (better have another copy), then open the image in tiny hexer and: access the MBR sector and fill it with 00's access the PBR sector and fill it with 00's Run again Dmde on the image with the 00ed MBR and PBR and see if the results on the same file are the same as before. jaclaz

...but you cannot read . First post of this thread: Read ATTENTIVELY point #1. Then start a new thread, if needed, and ONLY AFTER having searched for 7200.12 info (that you won't find in this thread which is ONLY about the 7200.11), you know, like this one, last active a lot of time ago, like yesterday: page__view__findpost__p__1014387 actually already containing links to "all we know" about the 7200.12. jaclaz

And gsar doesn't work for it, right? jaclaz

Oww, come off it! I do believe that you managed to find a way to break that limit What I wonder is : HOW OFTEN this happens WHY the good MS guys didn't (as they often do for much serious matters) say "it's by design" Back to your finding: What is the actual GOAL of that snippet (obviously it is not that of ECHOing a long string of comma delimited numbers to the screen)? Are you really sure that you need a XP CMD.EXE (and thus - to be "kosher" - an additional license besides the 2K one) to reach that goal? (or there are workarounds or different methods to achieve it still using the 2K CMD.EXE)? jaclaz

What about reading the help AND the link I posted earlier? http://diddy.boot-land.net/grub4dos/files/install_windows.htm#windows1 You: DO NOT want a line like C:\grldr.mbr="Grub4Dos" in BOOT.INI DO NOT want a file C:\grldr.mbr DO want a line like C:\grldr="Grub4Dos" in BOOT.INI DO want a file C:\grldr Then, you DO NOT want (when experimenting) a menu.lst file BUT you use command line instead. WHEN you add the set of commands that you already tested on command line to a menu.lst entry you DO NOT need the final "boot" command. WHICH exact version of grub4dos are you using? (among the two I suggested you, NOT the one you had before) Try again chainloading directly grldr (and NOT grldr.mbr), cannot say if it will change anything, but let's first start with the "proper" way, OK? If 0.4.4 2009-16-10 doesn't work, try with 0.4.5c-2012-06-19, or viceversa. There could be an incompatibility with the NT 4.00 NTLDR (but I cannot recall anything about it ) just for test you can replace it with *any* NTLDR from Windows 2K or XP, that are all tested. It could be an issue with the (old) version of NTFS filesytem NT 4.00 uses, since you have a floppy, try putting a copy of the grldr on the floppy (still for experiment only). jaclaz

Just in case: http://dictionary.reference.com/browse/only Of course having a line in batch longer than 2047 characters is very common, as an example, you cannot have this command: DIR /B C:\a senselessly long directory name containing\another pretty much unusefully and stupidly named directory\which is nothing but a container for another directory that contains at least another directory\which in itself is a container\possibly the matrioschkas were not invented by the good Russian guys, but were originated in Poland\but actually the idea of a path is that of being easily accessible and normally the contents of a file goes inside it and not in it’s tiitle nor in the path to it\though of course everyone has his (or her) right to freedom I find it very rare than any NT4 or Win2K (please read as Windows 2000 Professional Edition or Windows 2000 Server Edition) user has ever seen in real life a longer than (say) 200 (at the most) command line – nor I have ever seen a command line tool that – when enclosing ALL available parameters and switches has ever reached that length – so all in all if you use absolute paths to call a tool that is residing on a 256 long path and having BOTH a source and target among it’s parameters – you manage to get at the most WHAT 800 characters – let’s double it to 1600 and you still have 400 + 47 characters before hitting this limit\just for your info at this point (including spaces) we are around 1300 characters before this backslash\so we can continue writing senseless directory names that noone will ever use (in his right mind) in real life if not to prove a completely senseless point about the max length of the command line that the NT and Win2K will be able to accept\you see I made my point in much less than 2047 characters so I have to continue writing this \I wonder why the good MS guys instead of saying it’s by design which is what they normally do on actually relevant bugs took instead the time to fix it – as I see it this happened only because they found this by chance in the source code of CMD.EXE and in order to get a pat on the shoulder or however make himself more visible the anonymous programmer which found it managed to make a bug submission and solve it working properly in NT and 2K. jaclaz

On other news, Meanwhile in Italy: http://www.macworld.co.uk/digitallifestyle/news/?newsid=3404468&pagtype=allchandate Meanwhile in Cupertino: Back on topic, I don't remember this one being cited http://seattletimes.com/html/businesstechnology/2019168601_microsoftballmer16.html IMHO this is not LSD or peyote, it is downright Salvia divinorum : http://en.wikipedia.org/wiki/Salvia_divinorum jaclaz

The idea of the original "fix" guide was that a given (very minor) issue in the firmware made a drive data unreadable. What happened is detailed and documented, basically the firmware entered in a kind of "loop" without exit. So you have a perfectly "sound" disk drive which firmware has entered a loop. A way was devised (or actually somehow was "leaked" from the pro's) that allows to exit this loop. Since a later firmware has been corrected and avoids the entering in that loop, it is a simple equation: if before the firmware update, the drive bricked itself you have this new equation: Once every possible existing on earth drive (with the initial "bad" firmware) was either "recovered/fixed" or sent back to seagate for replacement or thrown away in despair, people started to try the same fix on *any* drive showing the same symptoms, and in some cases the fix worked (but we have NO idea on what caused the issue and if the "reset" actually fixed it or simply allowed to "tempirarily hide" the symptoms). Compare with Aspirin : jaclaz

Still you don't need the :End label, the implied :EOF is good enough. jaclaz

Well, you should use a newer version of grub4dos. What is recommended (by me) if you are going to use a 0.4.4, is version 2009-10-16 (which is latest 0.4.4 series): http://reboot.pro/16641/ or (better) the newest "Featured" from the grub4dos homepage: http://code.google.com/p/grub4dos-chenall/downloads/list HOW are you loading grub4dos? I will presume like this: http://diddy.boot-land.net/grub4dos/files/install_windows.htm#windows1 You NEVER (when experimenting) use a pre-made menu.lst entry, you use command line, pressing "C" to get to the prompt and entering commands one by one, this is because this way you get feedback from grub4dos related t the last command entered, thus, in case of issues you know WHAT exactly casuses it. Usuallly (but of course in no way "compulsory") floppy images are given .ima extension, whilst hard disk or partition images are given .img ones. Memtest is "easy". find --set-root /memtest.ima map /memtest.ima (fd0) map --hook chainloader (fd0)+1 rootnoverify (fd0) boot The above sets of commands (once tested working become a menu.lst entry as this: (you never need a boot command on a menu.lst as it is implied, i.e. automatically issued if EOF is reached or another "title" entry is foun in the menu.lst) The MS-DOS 6.22 in a hard disk image is more complex. Is it a hard disk image or a partition image? (i.e. is it's first sector a MBR or a PBR)? Assuming the first: find --set-root /msdos.img map (hd0) (hd1) map --hook map /msdos.img (hd0) map --hook chainloader (hd0)+1 boot jaclaz

No. (wrong reason) In the best case, IF a recovery procedure succeeds, what you have in your hands is a half-@§§edly repaired disk, "fixed" along an undocumented procedure that contains, besides a lot of guessing, some (white) magic. The only use of such a disk drive (besides it's utility as a door holder) is - once it has passed both short and long test from Seagate (and if it passes them) as a secundary or tertiary backup media or for experiments, you can't call it "storage" as it's reliability is "unknown" (in the sense of "even more unknown" then that of a new, working hard disk). In order to save some 80 bucks you are going to spend (possibly) some 20 bucks for the tools and spend several hours (most of them in a state of utter frustration). If you declare that you do it "for fun" and/or "for the sake of experimenting" and to learn something new, then it's OK . However, yes , if there is a delay when booting and then the disk is not seen by BIOS it is very likely a BSY state. In practice the BIOS "calls" the device on the end of the SATA cable with the intention of starting a conversation of the type "Hi, sorry if I am bothering you, I think we haven't met before, I am the BIOS of the PC, who are you? A sata disk? Yes? Which make? Which model?" (BIOSes tend to be friendly but nosy ) but the disk has forgotten the handset/earpiece off the hook and what the BIOS gets is a busy tone . We don't have a "tested procedure", only partial reports and a couple links. You should read ATTENTIVELY the Read Me First for the 7200.11 (as some "general ideas" are in common: then the CarterinCanada's guide (again aimed at the 7200.11): http://www.mapleleafmountain.com/seagatebrick.html and finally this thread (and links in it): jaclaz

Yep , It is a (cute ) "thank you bunny" connected to: jaclaz

So, if I get it right, you have your DiamondMax23 (please read as Seagate 7200.12) in BSY state? And it became so during a firmware upgrade performed when booted from CD? And before that the "running in Windows" utility failed? Are we talking of these?: http://knowledge.seagate.com/articles/en_US/FAQ/213911en http://knowledge.seagate.com/articles/en_US/FAQ/210091en jaclaz