jaclaz

But quite a few deers and a whole lot of inflatable elks decoys (in other words balloons) - that's behind what those d@mn ferrets were hiding , together with many, many other little mammals . jaclaz

Heck , the first rule of " What is behind the green glass door?" is: you DON'T talk about the zoo! And I can see only raccoons and no ferrets in it. jaclaz

No you don't. The code you posted (which maybe you also additionally mis-typed) is NOT the same as the one cuudulieu had. This thread is for 7200.11 ONLY . The above info is written ALL OVER the place, and EXPECIALLY on the read-me-first: The fact that cuudulieu thoughtlessly posted in this thread does not mean that you can do the same. BTW, had you actually read the advice given him at the time, you would have followed it directly: And maybe you could have found this thread: Start a NEW thread, posting the DETAILS of what you did. DO NOT assume that your problem is the same cuudulieu (or anyone else) had or has or will have. If you are lucky, and I mean REALLY lucky, someone will give you (hopefully) a solution. jaclaz

You may want to try the UNofficial SP5. http://www.msfn.org/board/forum/130-hotstream/ http://www.softpedia.com/get/System/OS-Enhancements/Microsoft-Windows-2000-Unofficial-SP5.shtml jaclaz

No. The general idea is that you have a valid source as .iso and the programs "transforms" it for USB usage. If the source misses the drivers, the target also will. (there are other ways/utiluties/whatever to do this) If you are making a "specific DELL (model xy)" USB stick, ONLY meant to install windows XP on the given make/model, you just integrate the specific drivers, otherwise you integrate the Mass Storage section of the BTS driverpacks: http://driverpacks.net/ http://driverpacks.net/docs/beginners-guide-windows-xp (BASE+Mass Storage) so that you will cover most (if not all) common hardware. jaclaz

You don't pay a fee to post links. When giving a reference Post a Link, so that noone has to guess WHAT the heck you have been following. This is the topmost sticky in the Forum (currently): This is the bottommost sticky in the Forum (currently): This is the USB_multiboot.cmd thread: that you are NOT allowed to abbreviate to "MD" or "MB", it is called USB_multiboot.cmd (since you have your new fingers, you have to train them ,and a little exercise in typing FULL names will do them good ) I won't risk finding within the latter thread the "bottom most sticky on the list" WHATEVER have you attempted, forget it. (temporarily). Just get RMPREPUSB here: http://sites.google.com/site/rmprepusb/ http://reboot.pro/7739/ (or from within the WinSetupFromUSB with GUI): and run it as Kelsenellenelvian showed you (if you behave, we will arrange to allow you abbreviating it to Kel ) jaclaz

Have you integrated the SATA drivers for that Dell (if it has a SATA disk)? jaclaz

I take it back , it was a goof, a miss and a misstep (like there are many), but still no guilt nor remorse. jaclaz

There must be something "wrong" with the post counter, you are still at 1. (as it was yesterday, that's why I posted asking, a new user with one post saying it was his second post is "strange" ) Most probably posts made in this Introduce yourself! section do not count. Now I see your "actual" post: jaclaz

Yep, human nature is very similar at all latitudes . You are welcome. jaclaz

you mean no fools ? jaclaz

...and peeps with too much free time, but no noobs... jaclaz

If I were you I would (provided that you have FULLY imaged that drive and have thus a "way back"): unhide the now hidden partition (so that it gets a drive letter) verify that it is first partition of first hard disk verify that i tit there are the \sources\boot.wim and boot.sdi files run the SetAutoFailover.cmd ]with command (provided that the unhidden partition is D:\ ): SetAutoFailover.cmd /target D: /wim /nohide as seen in the given link: http://blogs.msdn.com/b/winre/archive/2007/01/12/how-to-install-winre-on-the-hard-disk.aspx jaclaz

Any source for this procedure? Hot swapping PCB's is not something "usual". See if anything in here: http://files.hddguru.com/download/Datasheets/Samsung%20Service%20Manuals/ can be of use. jaclaz

Good. One more happy bunny in the basket: http://www.msfn.org/board/index.php?showtopic=128727&st=10 I would like to give you an explanation (if there was one). Problem is that I do not know. (or don't know for certain). Possible causes: whatever a different way the BIOS interrogates hard disks (as compared to the way the USB controller does - piloted by the protected mode WIndows driver) a timing problem with spin-up (that could be caused by "sticky" bearings or by something "wrongly set" in the drive firmware) a failing (or partially failing) PC PSU that simply cannot get enough "juice" to the HD motor or PCB at the exact fraction of second it is needed (or again here "sticky" bearings) a failing (or partially failing) PC on-board SATA controller (or other parts of the motherboard) a (partially) botched windows install a defective SATA cable The usual troubleshoot path is to test the device on ANOTHER PC, and see how it "behaves". It is also possible that it was a "transient" problem that once the drive spinned up and was connected through the USB "vanishes" and doesn't happen again.... See above, likely and easyness of fix depends on cause the above are in (supposed) decreasing difficulty/complexity of solution/fix. Actually in these cases the real bad news are that the idea of living next (hopefully ) 50 or more years with someone beside you daily reminding you the time you destroyed all the family's photos and how you were so d@mb and did not make a safe backup on another disk, etc. is really appalling. The good news are that I will tell you only once the THREE golden Rules: BACKUP Backup again on another media While considering the above - and the implications of them, do BACKUP your data jaclaz

Which one is the query? Whatever it is, I can hereby certify that your post above has been read by at least one (human) being. Welcome to the forum. jaclaz

NEVER, and I mean NEVER do that "for fun" , for all we know the procedure could create problems on an otherwise "good" drive. Yes, it may happen. The usual way out is to put the disk in a USB enclosure and try it on an already booted system by hot-plugging it. If no BSOD happens, you can usually perform a "normal" (assuming that a drive letter is actually assigned and that it is "E:"): CHKDSK E: then, if it suggests to run with the /F parameter: CHKDSK E: /F then, and only then, try a: CHKDSK E: /R But, since your primary goal is to recover the most data on it, I would anyway, BEFORE running CHKDSK with ANY parameter, I would do a RAW image of it, and see what can be found on it with DMDE: http://softdm.com/ and make a copy of the DATA you can access before attempting the filesystem repair. jaclaz

@crazydrive The usual advice (for any given method) is: NEVER introduce ANY change of ANY kind when testing THEN, once succeeeded, ONLY introduce one change at the time Introducing more than one change makes impossible (or very difficult) to trace back which one creates the problem. There is NOT one reason on earth to update the driver, and definitely NOT when experimenting. Start again from scratch, use the provided version of driver, DO NOT change the .iso path, DO NOT introduce any variation of any kind. Report. This way - even if it doesn't work - it will be easier to find the problem. jaclaz

A standard eSata connector provides NO power. There exists the eSATAp connector, but it is not widely used (expecially on the "drive enclosure" side - average "low cost" hardwre you can find "round trhe corner", on recent laptops it usually is): http://en.wikipedia.org/wiki/Serial_ATA http://en.wikipedia.org/wiki/ESATAp So you should verify that: your laptop actually has such a port the enclosure you want to by actually has such a provision Please also take into account that a number of motherboards/laptops and/or drive controllers may (by themselves or by the coupling) provoke a delay to the power actually delivered to the motor switching on, so that you cannot boot from them unless you power them before booting the PC. jaclaz

NO. NO. No risk to give unrelated advice this way, short and effective. jaclaz

Yep , but maybe we must find a way to have a current list and update it at each added post , to avoid making a mess with repetitions. I have no idea how this can be done in practice (in a handy way, I mean). jaclaz

What is the sense of the user NEEDS NOT to press F6 (unless he wants to) The above is written in first post. It is AFAIK plain English. As said, you may: believe the above NOT believe it Then: try it for yourself and see what happens But you cannot make guesses unless you know in detail how SETUP behaves AND have already tested the app. Now which hidden message may cdob want to convey? If you boot once from USB HOW MANY TIMES would the menu.lst entry be used? On the other hand, if you need to boot once from USB, may it imply that a re-boot is needed? TRY the thingy and see if a reboot is needed. Try reading AGAIN: http://reboot.pro/9076/ A summary (or synopsys) for you, in two sentences: it cannot work UNLESS someone finds a way to re-map the .iso there were contrasting reports, because people had ALSO the windows 7 .wim files extracted and thoughtlessly and falsely reported success The present thread is NOT about Windows 7, it is about "Install XP from a RAM loaded ISO image", let's stop talking about Windows 7, OK? jaclaz

I can find a mere two: Here and hare but since BOTH are repetitions, they don't count. The good news are that also Core, Cure and More are repetitions The bad news are that Sure is also a repetition So, unless I am mistaken , we shoud go back to Sura.... sorry jaclaz

The Synopsis is: try it, it works. The long story is: you cannot ask questions that you don't have the background enough to formulate properly/understand their answers. Mind you there is nothing "bad" in this , and obviously no offence intended, but you see, it took three posts to get to the point that the .iso is unmodified (this is plain English and needs not a particular background). How many will be needed to get that the F6 floppy is mapped to memory by the bolded lines: the above menu.lst entry is NOT crypted, but if you don't know/understand grub4dos syntax, you won't get that. If you don't know how windows install works, you will never get beyond the fact that the floppy disk image is NEVER booted. And these are details. You need to know what a "F6 floppy" is, how it works, how the XP setup works with it, in order to understand the method. In other words, you are basing most of your questions on a non-existing (or definitely confused) base of knowledge, so that they make very little sense and cannot be answered properly. It is a difficult and complex matter, let's say "very advanced". To tackle "base" concepts, you need an "elementary" previous knowledge of the things involved. To tackle "advanced" concepts, you need at leaste a "basic" previous knowledge of the things involved. To tackle "very advanced" concepts, you need at least an "advanced" previous knowledge of the things involved. This is how it works, sorry. This method uses BOTH Firadisk AND Imdisk. WHAT is then the sense of this? NO. Also remember that it is an EXPERIMENTAL driver, as clearly stated in the initial post. Firadisk development forum/threads: http://reboot.pro/forum/94/ http://reboot.pro/8804/ http://reboot.pro/9328/ No, I didn't, I stated that the Windows 7 install is completely different, which means ANOTHER thing, the general idea may work, but the details won't, and thus this method as-is won't work.. WHO said that one exists? AFAICR/AFAIK it doesn't: http://reboot.pro/9076/ jaclaz

HOW it is set? "Fixed" or "Removable" (I will tell you, without teamviewer, only through my crystal ball, that is "Removable" ) But you did not re-partitioned/formatted it with RMPREPUSB. On some BIOSes of the "bad BIOSes" group, it has been found that an entry for a (fake) second partition is needed for the BIOS to map the device as "Hard Disk" with USB sticks marked as "Removable". It may also be a completely different problem. Succeeded in WHAT? How EXACTLY was grub4dos installed? What EXACT version of grub4dos was tested? The space bar is normally the hot-key to boot the grub4dos MBR before the "previous MBR".: --hot-key=K if the desired key K is pressed, start GRUB before booting PREVIOUS MBR. K is a word value, just as the value in AX register returned from int16/AH=1. The high byte is the scan code and the low byte is ASCII code. The default is 0x3920 for space bar. See "int 16 keyboard scan codes" below. It should only make sense if --boot-prevmbr-first was used. --boot-prevmbr-first try to boot PREVIOUS MBR before the search for GRLDR. --boot-prevmbr-last try to boot PREVIOUS MBR after the search for GRLDR. It could be a timing problem of some kind? (but it doesn't make much sense, a stick has no delay in access, and anyway, IF the usual Try (hd0,0): .... etc. was shown, access to the device was available). Unfortunately "a bunch of lines" is again not a good enough description/report. jaclaz