jaclaz

NO. The guide uses this one: http://alldav.com/index.php?main_page=product_info&cPath=9&products_id=11 the new version of which is this one: http://alldav.com/index.php?main_page=product_info&cPath=0&products_id=28 Please notice how the word "TTL" is used in the description of BOTH the above. Notice also how on the product you linked to there is NO mention of "TTL" but mention of "UART". Cannot say if it means anything , but the FT232R: http://www.ftdichip.com/Products/FT232R.htm can output different levels, depending on how the board is made: http://www.ftdichip.com/Documents/DataSheets/DS_FT232R.pdf If pin 4 of the IC is connected to pin 17 it is configured for 3.3 V (right for this use) If pin 4 of the IC is connected to pin 20 or however to + 5v CC (possibly wrong for this use) You are of course perfectly free to do whatever you want , but this is NOT what is recommended, please check point #7 of the read-me-first: jaclaz

The screenshots are of no practical use, the .zip files may . Actually a $MFT first sector has the "$.M.F.T." (Unicode) string at offset 0xF2, but if for any reason that string has been overwritten, you won't obviously find it, the "FILE0" is a more generic string that occurs on each sector of the $MFT and thus allows to find also "fragments" of a $MFT. The real problems is that I still have not any idea about the WHY/HOW this mix-up occurred, quite frankly, we are "grasping at straws", hoping that somehow: the $MFT was originally in a "non-standard" position, that it is still there that TESTDISK somehow used (wrongly) in the bootsector the "standard" address As you can see quite a lot of assumptions . jaclaz

How big can the bootsector be? I have a bootable cd which is like 200MB, yet it shows "0 Objects" in Windows explorer. So does that mean that all 200MB of files/folders are in the bootsector? If it's a floppy emulation either 1.44 Mb or 2.88 Mb. If it's a "no-emulation" virtually any size (within the limits of the actual media) though normally the no-emulation bootsector is 2.048 bytes, it can be bigger, a typical example is grub4dos' grldr which can be used as bootsector and is around 220 Kb if I recall correctly If it's a hard disk emulation any size (within the limits of the actual media). But this is about "standards", one can make "special" "non-standard" CD's with lots of variants, including that of hiding any file to the "normal" OS, so there is really no way to know "generally", a specific CD may have been built in a specific way, and another one in a different specific one. jaclaz

Yes and no. It is bootable through a setting which is called "no-emulation". For reference: http://www.911cd.net/forums//index.php?showtopic=21212&st=23 http://www.911cd.net/forums//index.php?showtopic=18306 http://www.911cd.net/forums//index.php?showtopic=17278 Run BBIE on the CD/DVD: http://www.nu2.nu/bbie/ jaclaz

No, it simply means that the found $MFT was created on that date, which translates - IF that is the "right" $MFT - to the fact that the volume was formattted on that day (which I am presuming to be unlikely). Knowing the "history" of that system/drive may give hints to understand if this is likely or not. Continue gathering them, it is possible that the one till now found is part of something else, and that we find later the "real" one. jaclaz

Compare with point #1 and #2 of the Read-me-first: Pretty much a non-target! I see that you have then double-posted, so discussion (if any) continues here: http://www.msfn.org/board/index.php?showtopic=145646 jaclaz

Sectors 1081443~1081643 seem like being NOT the real thing/not usable. Sectors 1083487~1083687 seem better, at offset 50176 (sector 98/200 of "1083585" file) there is a "full" $MFT. Only it seems like having been created on 15/02/2005, would it be possible? jaclaz

If the bootable CD is of the "floppy emulation" or of the "hard disk emulation" type, yes, it's normal, the actual files are inside the bootsectors and NOT in the "normal" filesystem. You need one of the available CD/DVD tools or you can make an image of it and use 7-zip. jaclaz

Well, try again. Take power off from everything, connect the HD normally, see if it has changed it's LBA0 state. If yes, try getting your data back, first thing. If no, try the procedure again from start. It is possible that your drive is suffering from another problem.... jaclaz

A possibility is to access the BIOS (SMBIOS) settings and change them programmatically: http://linux.dell.com/libsmbios/main/index.html http://www.dmtf.org/standards/smbios Some vendors provide CMOS Tokens: http://linux.dell.com/libsmbios/main/security.html#what_cmos Or maybe mod this: http://rayer.ic.cz/romos/romose.htm BUT it's a loooong way, as I see it. Maybe you should ask for help in forums dedidacated to BIOS and BIOS modding.... jaclaz

Or maybe you could try using another Ramdisk, there are several freeware ones. A list is here: http://www.boot-land.net/forums/index.php?showtopic=1507 jaclaz

OT but just for the record: HotSwap! http://mt-naka.com/hotswap/index_enu.htm Maybe a Win9x backport of it or writing something similar is possible? jaclaz

Wayback Machine! http://web.archive.org/ Here: http://web.archive.org/web/20080403025159/unattended.solta.ru/unattended.en.htm jaclaz

It's very strange. The sectors you posted do contain some references to $Quota, $ObjId, $Reparse (i.e. typical objects of a $MFT): http://www.ntfs.com/ntfs-system-files.htm Now, with reference to your posted file: $Quota is on sector #16 which translates to Record #8 (should be Record #24) $ObjId is on sector #18 which translates to Record #9 (should be Record #25) $Reparse is on sector #20 which translates to Record #10 (should be Record #26) Which should mean that the actual $MFT beginning is 24-8=16*2=32 sectors before the chunk of sectors you posted, i.e. 1081543-32= 1081511 (which still makes very little sense) To be on the safe side, try saving 200 sectors (100 sectors before first found occurrence and 100 sectors after it). I.e.: Sectors 1081443~1081643 Sectors 1083487~1083687 etc. jaclaz

Sure, a "loop" that is not closed is not a "loop". See here: By now you should know it by heart, however, read again point #8 AND links within it. You shouldn't be "desperate" check point #14 of the said read-me-first. Don't worry, don't panic, . jaclaz

NO. As cdob said, mapping something in a Virtual Machine has NOTHING to do with USB booting, it may give some hints about the general bootability of a device, but NOT "Usb-bootability". Compare with these: http://www.boot-land.net/forums/index.php?showtopic=8042 http://www.boot-land.net/forums/index.php?showtopic=9688 http://www.boot-land.net/forums/index.php?showtopic=8581 jaclaz

IF I managed to understand your question , the answer is here: http://www.msfn.org/board/forum/157-install-windows-from-usb/ jaclaz

Yep, but there also several apps that may be able to get the filename. But we need a $MFT, for this. http://memberwebs.com/stef/software/scrounge/ http://memberwebs.com/stef/software/scrounge/guessing.html The sector you found is definitely part of the $MFT or of it's mirror. However it's position makes no sense to me, right now. Was the disk originally "Vista" or "Windows 7"? Maybe the $MFT position has been shifted on these systems? And somehow the position was reverted in the bootsector to the default XP ones? Try going on searching and take note of which sectors have this leading "FILE0" tag, maybe we can find a pattern. jaclaz

Check thoroughfully the pop-up when you want to mount a disk or large image file as disk, you can choose how many sectors you want to load. I will re-check the calculations, but maybe we have found somehow the culprit. The $MFT should be there, according to the data in the bootsector. Now what could have happened? Possibilities: the $MFT Mirror was corrupt and somehow you overwrote the $MFT with it BOTH the $MFT and $MFT Mirror were somehow corrupt the bootsector got corrupt somehow and now holds incorrect data about the location of the $MFT more of the above together. I just re-checked (doing also a check with a virtual drive) and the location of the $MFT is correct, as well as the whole first sector of the bootsector. I wonder what can have happened. You can try loading the disk in Tiny Hexer (the whole disk), load just one sector (the MBR), then go to Edit->Find/Replace set the box "Text", in the dropdown box choose "DOS 8 bits" and enter the search text "FILE0" (without quotes, that's FILE with appended a 0 - zero) it will tell you it didn't find it in current loaded sector, press "Yes to all" it will load and scan the whole hard disk until it finds the searched text, it will take a lot of time, be warned. If it is found, please save the sector on which it is found and post it in a .zip, post also the sector number where it's found. If we can understand WHAT happened maybe we may be able to rebuild the structure, otherwise you will have to use file-based recovery, I'm afraid . jaclaz

Which sums up in two steps to: I originally posted before actually connecting properly brain to fingers I now try desperately to find a reason not to admit that I may have been wrong in this case It is just a guess, as much as mine, and, most probably, just like this: The general Rule is NEVER trust anyone, CHECK YOURSELF! http://www.housemd-guide.com/characters/houserules.php To the above you add incomplete, deceiving or plainly wrong information supplied by anyone (possibly in perfect good faith) and you have the 100% probability (certainty) that until you have checked yourself, you cannot know the truth. Just an example, this comes from the pl2303HXD datasheet: and this comes from the pl2303HX one: Now the added sentence "The range can be from 1.8V~3.3V." can be any of these: a "generic" explanation, optional, that applies to ALL pl2303 chips a "generic" explanation, optional, that applies to ALL circuits designed to work in a 2.5 to 3.3V range but 1.8V tollerant a "specific" recommendation, ONLY valid for pl2303HXD AND NOT for ANY other pl2303 chip Instinctively, I personally tend to read it as "there are two power levels allowed, 2.5V and 3.3V.", all the rest being nonsense. VideoRipper has read it as "anything between 1.8 and 3.3V will do (depending on the level of the serial)" and applied the sentence to BOTH the pl2303HX and pl2303HXD (since there is no way to know WHICH pl2303 is inside the stoopid cable adapter). For the record later in the datasheet, there are for BOTH the pl2303HX and the pl2303HXD THREE tables: VDD_325@3.3V Serial I/O Pins VDD_325@2.5V Serial I/O Pins VDD_325@1.8V Serial I/O Pins Which means that Videoripper was right and I was wrong , but mainly means that even on strictly technical documentation it is easy to misunderstand, since data is either partial or misleading or badly worded. The e-bay seller writes in his page: which should mean that the adapter is self-powered from the USB side, and also confirmed it by e-mail to halbarad, but he also writes on the page: Now, if that wire has "VCC 3V TO 5.5V" it CANNOT be connected to the VDD_325 pin (which ONLY accepts 1.8~3.3 V) it could be connected to VDD_5 (USB Port VBUS, 5V Power) but it would be 5V AND NOT 3.3V or it could be connected to VO_33 (Regulator Power Output, 3.3V) but then it would be 3.3V AND NOT 5 V! jaclaz

Well, no, things don't get swapped by themselves, most probably you did not refresh the whatever you were viewing it with after the TESTDISK change, Well, no, usually TESTDISK asks what you want it to do, then reports something and then asks for a confirmation before doing potentially destructive things. I need to know what happens, what TESTDISK reports, as I cannot see your screen from this distance . If you already ran it maybe that is the thing that created the problem. Yep, typo third is row #1, but since the boot has already swithced all you want (eventually) to do is to chqnge the 07 of the hidden partition back to 12. Let's try to sum up: the MBR DATA (the only thing that is actually needed for the moment) seems OK the first sector of the bootsector seems OK the first MFT entry ( the one on absolute sector 26774331) needs still to be checked The only other things that may have gone "beserk" are: the other 15 sectors of the NTFS bootsector (possible, but unlikely) the MBR CODE (but that should be completely irrelevant) For the 1st you can try repairing the bootsector with bootsect.exe. For the 2nd you can restore a "standard" MBR with MBRFIX: http://www.sysint.no/nedlasting/mbrfix.htm OF COURSE, you should always make a backup of the things you are going to change (the two files you saved are already a backup, but you should also backup the other 15 sectors, i.e. access the partition, loading this time 16 sectors in Tiny Hexer instead of the default one, and do the Save as). A seemingly stupid question, have you tried connecting that hard disk to another PC (or after having booted to another OS)? Can it not be that you have something running (or in the Registry) that prevents the mounting of that partiton? jaclaz

Yep , but that used CDIMAGE, and unless you are from MS you can't use it, mkisofs.exe is on the other hand completely free. http://www.msfn.org/board/index.php?showtopic=88660 jaclaz

Which means that the changes you did before are now effective. Well, that's entirely up to you, hidden partitions should stay hidden (they are meant to stay hidden by design). You can use the apps in the given link if you want to temporarily mount it in order to access it, but there should be no reason normally to fiddle with it. The bootsector data seems ok. The $MFT should be at absolute sector (786432*8 + 20482875) if accessing the Physical drive or 786432*8=6291456 if accessing partition. The first thing you should see there is "FILE*" or "FILE0". if opened the whole disk: File->Disk->Goto Sector->26774331 or if opened the partition: File->Disk->Goto Sector->6291456 Test disk should be able to check and fix this kind of errors: http://www.cgsecurity.org/wiki/Advanced_NTFS_Boot_and_MFT_Repair Try running it as per above, and see what it reports. jaclaz

It seems to me like a lot of money to have an enormous computing power (that you won't need, probably don't even know HOW to use) in a crippled 1U server rack-mount. I mean you need some actual reasons, like: I need a rack mounted thingy. I need it in a 1U form factor. I need to do my own (choose one among OS, digital movie, etc...) You can have the "advantages" of: 2.5" SAS drives (fast but expensive) "only" 5 USB ports (of which one internal) Low Profile PCIe slots (far more expensive should you want to add a card) 65.8 dB noise level Lousy video card But you need to put on the other side of the scale also the "disadvantages" (the same as above ) Now, with US$1800 you can have a more than "decent" conventional system, which is more easily upgradable and serviceable. If you got that server for, say US$ 1000 or an earlier model for US$ 250 at a garage sale that would be a possibility, but not for that amount of money (btw you don't say with how much storage space are you getting it, a typical 300 Gb 10K 2.5" SAS is around US$250 each). A "normal" 3.5" 500 Gb 7200 SATA is around US$80, as a reference. jaclaz

I am missing the reason for the LCISOcreator.exe. A batch to launch a .vbs that launches mkisofs.exe.... You could also add a .hta in the middle (just for the fun of it): http://mysite.verizon.net/hartsec/make.htm Or a Auto-it tool: http://www.solriche.co.uk/files/mgiso/mgiso.htm Seriously, you could ask, say, gunsmokingman to add the choices to the .vbs (and also remove the unneeded parts, getting rid of the batch) or, say, Yzöwl to add the mkisofs commands inside the batch (and get rid of the .vbs),right now there is an unneeded complication, as I see it. jaclaz