jaclaz

I don't think it is the OS that does that. It is usually a feature of the drive, when you insert a disk (read when you close the tray) it spins briefly to check if a media is loaded, if it finds it continues spinning, if it doesn't find one it stops soon after. JFYI, out of say, 20 Cd/DVD drives that had "mechanical problems" opening/closing the tray, 19 were fixed by simply thouroughly cleaning the mechanics and reapplying a very small quantity of an appropriate lubricant/grease. What I normally use (this is not advertising, just a report) is "Super Lube" a synthetic grease with Syncolon (read PTFE or teflon). jaclaz

Hey Drugwash , you understand that "US europeans" can be read differently from what you meant, do you? A whole new breed of people, still with short sleeved shirts and ties, but more open minded when it comes to nudity? jaclaz

Check you command line for mkisofs against this one (which is known to be generally working): http://www.msfn.org/board/index.php?showtopic=94398&hl= jaclaz

Yes. In "mixed" environments, i.e. when something is powered/connected to one PC and something else is powered/connected to "something else", including another PC, you need to pay attention to GROUND. Connect together the ground of all equipment, or you are likely to get some garbage in hyperterminal. The "derived" guide by CarterInCanada: http://www.msfn.org/board/index.php?showtopic=133387&hl= is remarkably clear/advised. jaclaz

Yep, they do. But the ASUS should have "correct" nx255x63 However this explains perfectly why we had the problem with CHS. If you want, just to make double sure, I can make a MBR with nx240x63 geometry. "See" you when you are back. jaclaz

What are you using to actually write/edit the .bat/.cmd? Maybe it's a problem with character sets. try doing the following: Open c:\test.txt with your ediitor. Can you see the Á or has it become a Beta? jaclaz

It seems like something (unknown) prevents from "properly" creating the filesystem. But really cannot say what. The laptop appears to "like" 0E (LBA) and not 06 (CHS), but using the first64.dat it does boot properly. The first315.dat is identical (apart volume serial) to first64.dat but has added EMPTY FAT tables, so it should behave exactly like first64.dat. It is possible that your laptop is one of the very few ones (I seem to remember IBM ones) that use nx240x63 geometry. However, get back to the condition that was working (as per posted pictures). Now you need to use a hex editor to change the embedded menu.lst in grub4dos: http://www.boot-land.net/forums/index.php?...c=6775&st=5 http://www.boot-land.net/forums/index.php?...=7231&st=25 or grubinst as in here: http://www.msfn.org/board/index.php?showto...134808&st=6 to change the "embedded" menu.lst in grub4dos to make it search for grldr on "floppy" too. (i.e. remove the "--ignore-floppies" from entries) in order to replicate on the Asus the same behaviour of the laptop. For the moment, boot to the ASUS, get to command line and issue these commands: map (fd0) (hd31,0) [ENTER] map --hook [ENTER] root (hd31,0) [ENTER] chainloader /ntldr [ENTER] boot [ENTER] You should get back to the BOOT.INI choices. The other thing to try is to see if, since you have a USBest UT165 controller, the correspondent "manufacturer tool" can "flip the removable bit". The tool should be this one: http://flashboot.ru/Files-file-219.html http://flashboot.ru/uploads/files/public/U...5_1.65.17.0.rar The manual for it should be this one: http://flashboot.ru/uploads/files/public/U...ual_EN_V4.0.rar If it works, the stick becomes a "fixed" device, just like any hard disk, and thus the ASUS should recognize it properly. jaclaz

It greatly depends on the actual model of the stick, a few are simply two plastic shells that you can separate by using a knife (you will probably break anyway the case, but if you are careful with these it can be re-glued together) some are more "tough" and need to be cut/broken. jaclaz

Only things that seems possible at first sight, since you tested almost everything, is that since you are using the .iso bootsector (chainloader (hd32)) it is this latter one that fails, or maybe you are missing a root command. Try chainloading the actual bootmanager in the .iso, like title WinPEx86 find --set-root --ignore-floppies --ignore-cd /WinPEx86.iso map /WinPEx86.iso (hd32) map --hook root (hd32) chainloader /BOOTMGR jaclaz

NO. DO NOT change PCB's. jaclaz

"Search Assistant" sounds like a possibility. jaclaz

And, of course, someone is NOT agreeing: http://www.guardian.co.uk/environment/cif-...gy-kinetic-road The store however has many more "green features": http://www.j-sainsbury.co.uk/index.asp?Pag...amp;NewsID=1095 Today is one of those days that my math does not help me much. One says 30 kW in an hour, the other one says that each car pass produces 0.002 kW/h, i.e. 30000 W and 2 W/h respectively . Thus to have 30000 W produced in an hour, you have an average 30000/60=500 W in a minute, and 500/60=8.333 W in a second. The above should mean that EVERY second 8.333/2=4.166 cars have to pass on the plate. In typical 8 hours/day opening hours, that would mean that 4.166x60x60x8=120,000 cars need to access the parking, ALL passing on the plate. jaclaz

Another way to ponder: @ECHO OFF SET drives= SET separator= FOR /F "tokens=1,2 delims=\ " %%A in ('fsutil fsinfo drives^|more') DO CALL :SET_var %%A %%B SET drives GOTO :EOF :SET_var SET separator=, IF NOT %2.==. SHIFT&SET separator= Set drives=%drives%%separator%%1 GOTO :EOF (doesn't need Delayed Expansion enabled) jaclaz

Well, actually this is more or less (read exactly) what minlogon does. http://msdn.microsoft.com/en-us/library/ms...mbedded.5).aspx Now, a freeware/Open Source minlogon replacement would be a nice thing to have. jaclaz

There are 10 kinds of people....: http://www.oreillynet.com/etel/blog/2004/0...f_people_e.html Possible soundtrack theme: B) It would come out as a hit among geeks. jaclaz

A similar solution to the one by Scr1ptW1zard , possibly simpler : @ECHO OFF SETLOCAL ENABLEDELAYEDEXPANSION FOR /F "tokens=1,2 delims=: " %%A in ('fsutil fsinfo drives^|more') DO ( IF NOT %%B.==\. (SET drives=%%B:) ELSE (SET drives=!drives!,%%A:) ) SET drives ENDLOCAL jaclaz

Unfortunately it seems like the WHOLE image is made of 00's. I am scanning it right now, but in about first 2/3 of it I couldn't find but zeroes. This is NOT "normal". To get to this condition one of the following cases applies: stick has been (accidentally or intentionally) wiped (to wipe a flash memory means writing 00's to it, which for an 8 Gb stick should take several minutes, so you should have noticed it) stick has been "zapped" or "fried" by some overcurrent or overvoltage (but usually when this happens it is the controller that gets fried, see below) something is wrong in the hardware (the controller seems OK, as the stick is recognized by Windows, so it should be the actual flash, but if you are lucky it could also be a "real hardware" failure, such as a cold or broken soldering) I guess that your only remaining thing to try is to "crack" open the stick enclosure and inspect both visually and with a ohmmeter the continuity of tracks and chips's pins. If this check reveals no problems, depending on the value you attribute to the data on the stick, it may be the case to ask a professional to try and take off the stick the flash and mount it on another (identical) stick/controller. Of course you can do this attempt by yourself, but managing surface mounted components (as stick chips usually are) is not that easy for a non-expert and with "rudimental" tools, I guess it depends on your manual skills and experience. jaclaz P.S.: For the record and for other users, the image once compressed, resulted in a 4.7 Mb file, not as initially posted 4.7 Gb.

Well, for a "general search and replace" tool the "reference app" should be gsar http://home.online.no/~tjaberg/ (as opposed to "line oriented" tools like Fedit) jaclaz

NO. (AFAIK) Maybe if you post an example of the FOR loop that you have in mind there could be some workaround. .unsure: jaclaz

Wouldn't Fedit do? Check these: http://www.msfn.org/board/index.php?showtopic=51337 http://www.msfn.org/board/index.php?showtopic=48200 jaclaz

To be very accurate Maxwell Equations DO NOT "govern" anything. http://www.thefreedictionary.com/govern Maxwell theories and equations on electromagnetics are the best known today explanations about the behaviour of EM. EM (like everything else) "governs" itself pretty well. (and did so a loong time before Maxwell was born) jaclaz

the 4.7 GB size of the compressed image is (besides being "huge" ) a good sign that at least some data is still on the stick. jaclaz

Hmm. I wonder what it could be the problem. In the MBR there are these as messages in case of Error: Invalid partition table Error loading operating system Missing operating system In the "normal" FAT bootsector there are these: Invalid system disk Disk I/O error Replace the disk, and then press any key or these: NTLDR is missing Disk error Press any key to restart So it seems like you are erroring out with the latest, which should mean that the bootsector data does not "match" the MBR one. This does not make much sense, unless somehow the stick is seen with a weird geometry, but even then, it shouldn't behave like this. I tried creating an image with your stick data and as expected it boots allright in Qemu, both with 0E and 06 as Partition ID. A further check on your MBR shows some "garbage" between 0x180 and 0x199, and again from 0x01AB and 0x1B8, but I don't think that can be the reason. Could it be because of the non-standard cluster size? I doubt it as well. Can you try using a MBR I prepared on your stick? You can use HDhacker to save it on your stick. Procedure: extract from tulert.zip first1.dat, first64.dat and first315.dat use hdhacker to write it to the MBR of the stick eject and re-insert stick format the stick as FAT16 check with beeblebrox the values copy to the partition the files listed on post #33 try booting from it if it doesn't work, try again with 0E instead of 06 If still it doesn't work, try copying the whole first64.dat file to the stick. You will need to use dsfi (part of the dsfok toolkit): http://members.ozemail.com.au/~nulifetv/freezip/freeware/ unzip in C:\dsfok copy to C:\dsfok\ first64.dat use as the right N is the same as the one seen in hdhacker or beeblebrox eject and re-insert stick try booting from it if it doesn't work, try again with 0E instead of 06 (at least the error message should change) If still it doesn't work, try copying the whole first315.dat file to the stick. eject and re-insert stick copy to the partition the files listed on post #33 try booting from it if it doesn't work, try again with 0E instead of 06 Right now the attachment system is not working for me, please get it from here: http://rapidshare.com/files/250483422/Tulert.zip.html jaclaz P.S.: Though possibly a bit premature, can you try running ChipGenius on that "MicroCenter 4GB" and post Vid/pid and manufacturer: http://www.boot-land.net/forums/?showtopic=4661 Latest should be v3.01: http://dl.mydigit.net/2009/0406/chipgenius.html http://dl.mydigit.net/down.php?a_k=LnppWmp...BQAdQN2dg%3D%3D

No, it's allright. In some cases, actually I cannot really remember when and why, FORMAT changes the already present: 0E -> FAT16 LBA mapped partition to: 06 -> FAT16 CHS mapped partition or viceversa. Empirically, 06 has been found to be "more bootable", but when you have correctly balanced CHS and LBA data, it shouldn't make much difference. I.e. you can read my previous: the accent is on "if it doesn't boot on the laptop", it is possible that any given BIOS: - boots from both "06" AND "0E" - boots with "06" BUT NOT with "0E" - boots with "0E" BUT NOT with "06" compare with this: http://www.911cd.net/forums//index.php?showtopic=21049 On a "good" "wide minded" motherboard BIOS, once CHS and LBA data is "balanced" you can change 06 to 0E at will, but this does not happen always. jaclaz

J.Singleton is not new to this particular topic: http://ieeexplore.ieee.org/Xplore/login.js...thDecision=-203 My guess is that Einstein Theory is not particularly affected by this, at the most an extension to it will be needed: http://www.rp-photonics.com/superluminal_transmission.html jaclaz