jaclaz

The "normal" sequence at power on is AFAICU something along the lines of: read *something* from the onboard ROM spin up read *something else* from the actual disk platters present to the BIOS query some data If the disk does not spin up it simply cannot read part of the information, it gets into a "busy" or BSY state and as such the BIOS won't detect it. The symptoms could be - with the same possibility - a stuck bearing or a head stuck. If the first, in some rare cases it can become free with either percussive maintenance or with the "freezer trick". If the second it is more likely that it can be freed with some percussive maintenance BUT it is very likely that you will have a head crash. To have an idea of the force that is needed to free a stuck bearing (if really stuck) check this: And this to understand what happens with stuck heads: jaclaz

Well, what you asked a few posts above was: The answer is yes, two suitable applications (for two different OSes ) were suggested to you. Whining about how much earthlink supposedly sucks and what they should provide as feature to their users may possibly result in something if told to them. jaclaz

Just for the record, under LInux there is Napalm: http://www.scarpaz.com/Napalm/ A window app having (among others) a similar feature is this one: http://www.poptray.org/ jaclaz

Well, maybe looking in it's License (the one that you have to read BEFORE ticking "I accept" when installing), would help: jaclaz

From what you report that drive does not spin UP. Check if it does first thing: If it does not, the ONLY possibility you have (VERY, VERY, VERY risky for the integrity of the drive) is some "percussive maintenance": In a limited (very limited amount of cases, holding it in a vertical position may be enough to allow initiating the spinning. jaclaz

I have no idea , ideally you should try by steps: CHKDSK CHKDSK /F CHKDSK /X (only Windows 2003 and later) I would "bet" on CHKDSK /F, but it is possible that CHKDSK only is enough. Another test would be simply UNmounting the volume and re-mounting it. I would try first with MOUNTVOL (available since NT or 2K) On Server 2008 and 7, another approach could be setting offline the actual disk: http://reboot.pro/8200/page__st__39 If you prefer, I suspect that the reboot is not vital but having CHKDSK check the volume or Mount Manager re-discover it should be enough for the new MFT reservation to be enabled. And yet another test could be defrag. jaclaz

Happy there is (yet another ) happy bunny in the basket. http://www.msfn.org/board/index.php?showtopic=128727&st=10 jaclaz

Sure . The idea of an example is that of an example. IMHO, not that of a "refined" solution. jaclaz

Then you have an example to work on. jaclaz

Do you want to remove it or change it to something else (and if this is the case) is the something else "fixed" or variable? I.e. C:\program files\GnuWin32\bin\www.slv.dk\Dokumenter\dsweb\Get\Document-1413\_K_ENR_1_6_en.pdf should become: 1_6_en.pdf <somethingelse>1_6_en.pdf Example (remove _K_ENR_ only ) @ECHO OFF SETLOCAL ENABLE EXTENSIONS FOR /F "tokens=* delims=" %%A IN ('DIR /B /S *.pdf') DO CALL :rename "%%A" GOTO :EOF :rename SET filename=%~n1 SET Newfilename=%filename:_K_ENR_=% ECHO %1 ECHO "%~dp1%Newfilename%%~x1" GOTO :EOF jaclaz

If I get it right, what you are wanting to build is - more or less - a "car PC", only you will use it in your dining room instead. So, this might be the right place to get some ideas: http://www.mp3car.com/vbulletin/ jaclaz

It seems to me perfectly "natural". You have an EMPTY volume. You tell the OS to expand the MFT zone. It finds a lot of free space ("on the right") to expand the MFT zone, it does it. Of course there is NO need whatsoever to reformat. The tests should be made with a "filled" volume (actually all is needed is to have a few files right after the previously set MFT reserved zone. But in this case there will be no need to reformat, most probably the files will be moved "further on the right". A nice experiment could be instead of rebooting to run CHKDSK on the volume. Tools mentioned here may come handy: http://reboot.pro/15086/page__st__25 jaclaz

Have you followed to the letter the instrutions in the thread: particularly: The file TEE.BAT is exactly where it should be inside the .zip, and I see no reason why it shouldn't be there when the achive is unzipped. jaclaz

Well, actually 786432 is a reather largish number to have those properties. 64x1024=65536 would do as well. If I recall correctly (though not as low as the above) wWin2K used a much lower address for the $MFT. As I posted earlier (corrected, there was a lapsus calami), on an 8 Gb volume in XP the MFT goes to And we have: 786432*8=6291456 6291456*1=6291456 3145728*2=6291456 1572864*4=6291456 Quick test just made: Image Bytes/ Sectors/ $MFT $MFT Offset size Cluster Cluster Cluster (sectors) 1 Gb 1024 2 349525 699050 2 Gb 2048 4 524288 2097152 3 Gb 4096 8 262144 2097152 4 Gb 4096 8 262144 2097152 5 Gb 4096 8 262144 2097152 6 Gb 4096 8 786432 6291456 The "switch" is between 5 and 6 Gb. jaclaz

I guess there is a misunderstanding. I am not saying that a same volume size with different cluster size will always hold the $MFT @#786432. I am saying that the *normal*, default NT format will tend to create the $MFT @#786432, or, if you prefer, that *all* NTFS volumes/bootsectors I ever examined had the $MFT @#786432 in the bootsector field, starting form a certain size. It is very possible that this "fixed address" behaviour is not cluster #786432 x 4 kb (default cluster size for a rather largish range of volume size): http://support.microsoft.com/kb/140365/en-us but rather offset 786432 x 4096=3,221,225,472 or sector 6,291,456 and that this is not affected by cluster size. You can check this directly (instead of using Ultradefrag) by checking the 16 bytes @offset 0x30 in the bootsector and multiplying for cluster size (single byte @offset 0xD) or using (as an example) tiny hexer that has a built in Structure Viewer for NTFS bootrecord (and optionally using my INCOMPLETE - but working for theis NTFS fielsds - one): http://reboot.pro/8734/ jaclaz

Interesting report! : JFYI : http://support.microsoft.com/?id=961095 Translated from MSish to layman's terms: Seriously, now, my experience with the location of $MFT is different, when a given size is reached the offset becomes "fixed" to cluster #786432 or 0xC0000. jaclaz

My personal preference is for dd_rescue: http://www.garloff.de/kurt/linux/ddrescue/ used TOGETHER with dd_rhelp http://www.kalysto.org/utilities/dd_rhelp/index.en.html the latter is very well documented and extremely simple to use, in practice it takes the manual intervention out from using dd_rescue directly. jaclaz

I really don't want to make a case out of it , but really, if your friend used "plain" dd on a disk that has problems, he cannot be this great Linux expert, as *any* Linux user knows (or should know) about two specific dd versions for recovery: ddrescue: http://www.gnu.org/software/ddrescue/ddrescue.html dd_rescue: http://www.garloff.de/kurt/linux/ddrescue/ jaclaz

From what you say there must be some issue with making the USB stick bootable, and/or in the copying of the files. The blinking cursoer is typical of a "wrong" setttings in the bootsector, (wrong CHS values) and this can in some case be a fault of the HP USB utility. Can you try making the stick bootable with RMPREPUSB with grub4dos, verify it boots on your machine and then try running the "special program" on it? It doesn't make sense that it doesn't boot, the thingy should work (to create the bootable stick) oon *any* machine, not necessarily on the intended targeted server. jaclaz P.S.: EDIT: out of curiosity I did a quick check. The thingy I got contains a "plain" .iso image of a Linux system. I managed to run it in QEMU allright, not by directly loading the .iso, but using a grub4dos boot floppy with this menu.lst entry (parameters got from isolinux.cfg): title stupid HP root (cd) kernel /SYSTEM/VMLINUZ media=cdrom rw root=/dev/ram0 ramdisk_size=121260 init=/bin/init loglevel=3 ide=nodma ide=noraid pnpbios=off usrramfs=1 splash=silent showopts initrd /SYSTEM/INITRD.IMG boot I presume you can do the same on USB stick using the settings in syslinux.cfg. Then it seemingly hangs on udevd, after having printed "this is not a supported server", and It takes forever to load (several minutes), but eventually you have an option to run the update for EITHER: Flash SATA drive models - GB0250C8045, GB0500C8046, GB0750C8047 Flash SATA drive models - GB0250EAFKF, GB0500EAFJH, GB0750EAFJK, GB1000EAFJL Tthe first choice seemingly runs CP010461.scexe and second CP010456.scexe (these are files that are in the .iso under COMPONENTS) BTW the documentation says: and that the HD controller has to be set as "IDE" and NOT to "SATA" or raid. I guess you need to find a friend with some Linux knowledge and understand if these files can be run from a "plainer" Linux or if the firmware can be extracted form those .scexe files. Good hints are here: http://lackof.org/matt/hacking/proliant/Debian-ProLiant-Guide.html Most probably the good guys at HP ask you to download a huge installer only to have it execute the 4 (four) batch lines in usbcreator.cmd: xcopy %1\*.* %2\ /e /k move %2\system\initrd.img %2\ move %2\system\vmlinuz %2\ move %2\usb\syslinux.cfg %2\ that should equate to: copy whole contents of CD to USB stick (in root or possibly in a folder \boot\) then move to the same (root or folder) initrd.img, vmlinuz and syslinux.cfg.

If I were you I would remove point D) as soon as you can. jaclaz

You may find this of interest: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/problem-report-standard-litany.html jaclaz

WHICH EXACT USB installer? WHAT EXACTLY are the unpacked contents of that thingy? jaclaz

NOTHING. I will translate: EITHER your friend used dd wrongly OR the whatever he dd'ed was all 00's OR an unknown error happpened OR your actual disk is all 00's. I don't really want to somehow take advantage of your misfortune till now, BUT if you quickly review this thread you will see how it goes like this: saman0suke: I need help and advice for .... jaclaz: first thing you should use tool A using it along procedure B saman0suke: OK, I used tool A with procedure C then jaclaz: well, as said you should use tool A along procedure B saman0suke: OK, I had a friend using maybe tool D along an unknown procedure, here is the result jaclaz: result is no good Your turn. jaclaz

Yes. NEITHER ! Yes. NEVER, NEVER, NEVER, for ANY reason attempt to write a firmware that is NOT specifically targeted for the device UNLESS you are told to do so by: a representative of the manufacturer someone that really knows on the SPECIFIC device and whom you can trust blindly You want the HPG6 from HP: http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c01612429 You may want to explore the possibilities of the OFFLINE update utility: jaclaz

You are not going to get very far if the recovered data is like this. The file you posted consists of ONLY 00's. I hope that this is only somehow "a glitch in the matrix" and that the rest of the file actually contains data . You should first thing calculate the MD5 of the image file you have in your hands and compare it with the result of using this: http://www.edenprime.com/software/epAllZeroHashCalculator.htm A suitable tool to calculate the hash on the image is http://www.nirsoft.net/utils/hash_my_files.html jaclaz