jaclaz

It seems like the SD card gets two Parent Id's. The Migrate.inf (rightly) gets 7&d7f206a&0. This ParentIdPrefix is "understood" by the "AsusEee" rightly, but evidently NOT by the "Acer5738". My guess is that it's something BIOS related. Or maybe the "Acer5738" uses a different way to enumerate devices. What happens, once the XP - one way or the other - is installed on the "Acer5738"? What ParentIdPrefix does the SD card gets on the "Acer5738" already running XP? Still the same 7&d7f206a&0 ? Use this "updated" batch: @ECHO OFF ::migrate2txt.cmd rudimental batch to extract ParentIdPrefix from migrate.inf file ::by jaclaz ALPHA 0.02 Release 7th November 2009 ::supports both "removable" and "fixed" devices SETLOCAL ENABLEDELAYEDEXPANSION SETLOCAL ENABLEEXTENSIONS SET TEXT= SET SOURCE=%1 IF %SOURCE%.==. SET SOURCE=%~dp0MIGRATE.INF&SET CLeanSource=MIGRATE.INF IF NOT defined CleanSource SET CLeanSource=%~nx1 IF /I NOT "%CLeanSource%"=="MIGRATE.INF" GOTO :MIA FOR /F "tokens=* delims=" %%A IN ('MORE %SOURCE%^|FIND ",00,"') DO ( SET UNICODE=%%A ) SET UNICODE ECHO. SET SPACESUNICODE=%UNICODE:,= % FOR %%? IN (%SPACESUNICODE%) DO ( IF NOT %%?.==00. ( CALL :bin2txt %%? SET /P Var=!s!<NUL SET TEXT=!TEXT!!s! ) ) CLS SET UNICODE ECHO. SET TEXT="%TEXT:@=&%" SET TEXT=%TEXT:§=?% SET BEGIN=%UNICODE:~0,8% IF NOT "%BEGIN%"=="5C,00,3F" GOTO :Fixed SET TEXT ECHO. SET Prefix="\??\STORAGE#RemovableMedia#" SET BEGIN=%TEXT:~0,28%" IF %BEGIN%==%Prefix% SET ParentIdPrefix="%TEXT:~28,11%" SET ParentIdPrefix&GOTO :EOF :Fixed SET DiskSignature="%UNICODE:~0,2%%UNICODE:~3,2%%UNICODE:~6,2%%UNICODE:~9,2%" SET DiskSignature ECHO (as seen in a hex editor viewing the MBR) GOTO :EOF :bin2txt Set s=%1 For %%A In ( 23# 26@ 2D- 300 311 322 333 344 355 366 377 388 399 3A: 3B; 3D= 3F§ 41A 42B 43C 44D 45E 46F 47G 48H 49I 4AJ 4BK 4CL 4DM 4EN 4FO 50P 51Q 52R 53S 54T 55U 56V 57W 58X 59Y 5AZ 5B[ 5C\ 5D] 5F_ 61a 62b 63c 64d 65e 66f 67g 68h 69i 6Aj 6Bk 6Cl 6Dm 6En 6Fo 70p 71q 72r 73s 74t 75u 76v 77w 78x 79y 7Az 7B{ 7D} ) Do Call :DoPairs %%A GOTO :EOF :DoPairs Set _=%1 Call Set s=%%s:%_:~0,2%=%_:~2,4%%% Goto :EOF :MIA ECHO File MIGRATE.INF not found! GOTO :EOF Is the SD card partitioned, right? If the "Acer5738" thinks that the SD card is a "Fixed" Hard Disk, INSTEAD of ParentIdPrefix it will use Disk Signature in the MBR to identify it. It costs nothing to try adding to MIGRATE.INF a mapping for the Disk Signature as "V:\" and see what happens. Read the thread that "started it all": http://www.911cd.net/forums//index.php?showtopic=19663 Add to MIGRATE.INF these lines: HKLM,"SYSTEM\MountedDevices","\DosDevices\V:",0x00030001,\ ww,xx,yy,zz,00,7E,00,00,00,00,00,00 Replacing the ww,xx,yy,zz values with the ones you can get by peeking with a hex/disk editor in the MBR or using a tool like MBRfix to read the SD card signature. jaclaz

Do you have a bootfix.bin file? jaclaz

Were you blindfolded when looking? To re-cap: the HD accepts TTL level signals a USB-to-TTL or a RS232-to-TTL or a USB-to-RS232 AND a RS232-to-TLL interface is what is needed there are commercially available (or it is remarkably simple to autobuild) such interfaces, this thread is FULL of links to various models Most cellular phones, including Nokia ones, are also programmed through a TTL level interface. Thus, if you ALREADY have one of those cellular phone cables around and you don't use it anymore, it costs you nothing to see if it works. Buying a new one is NOT advised because: you have to open it and while doing so there is a probability you will break it there are several types of these cables some work, some DO NOT, some have NOT the "right" drivers, and when you buy one of them there is no practical way to know if it's the "good" type besides, some of these cables get their power from the USB port, whilst some get it (if I may one of the stoopidest ideas I've ever seen in my life ) from the actual phone battery, so you have to connect an additional battery to replace the power normally drawn from the phone There are SEVERAL posts in this thread about this issue, most notably an illustrated one here: http://www.msfn.org/board/solution-seagate...-page-1756.html More generally, the various tutorial are to be used as a cooking recipe should be: if you are a professional cook, or you have some experience in the field, you can use the recipe as a base and change doses and ingredients and vary cooking time, result will probably be edible. if you are not expert at this, you should not change anything and do exactly as it is written in the recipe you chose. This said there are as well SEVERAL reports of success using various original and non-original CA-42, a couple examples: http://www.msfn.org/board/solution-seagate...-page-1805.html http://www.msfn.org/board/solution-seagate...-page-1833.html Common point is that due (generally speaking ) to the lack of experience of users, when there is a report of failure it is sometime difficult to say whether a given cable is the problem or it is the way the user connected it (or failed to connect it) or whatever. jaclaz

NO, he is saying that IF the problem is one of the two detailed and IF the APPROPRIATE equipment has been used following PROPERLY the instructions, it has worked in a few THOUSANDS of cases. Swapping boards CANNOT work, unless a far more difficult procedure is used (involving soldering and desoldering on the board) AND the boards are really identical. You: basically: bought a cable that is not the "best" advised solution, and possibly is also one of the NO GOOD ones either managed to break it or the thingy was DOA: "connecting the tx to the rx cable produces no echo in hyperterminal either" don't want to buy another cable This does not count as a report of the unbricking not working, as you have a DEAD cable/not working equipment. jaclaz

I would try to check what the Maxtor utilities have to say first thing, it could well be a dead drive, after all. You can find them (together with a bunch of HD tools) in UBCD: http://www.ultimatebootcd.com/ Then I would try the unlocking tool for oldish TiVo's: http://www.weaknees.com/maxtor_powermax.php Please do understand that the "locking mechanism" may not be the same for all DVR's, so unlocking it may work or fail, even if the drive is functional. jaclaz

Well, NOW you should see WHY: 1 problem=1 thread=1 method=1 solution (hopefully ) would have been faster and is advised. Happy this one is solved. jaclaz

Almost. You need only one "mkmigrateinfxx.cmd" either the one that is in the original topic or the latest version linked to. The small batch I posted should be called migrate2txt.cmd as in: (again to avoid confusion) If you copy the mkmigrateinf.cmd to the stick you do not need to specify the drive letter of the tick itself, otherwise (as an example if you put it in C:\batches\) you need to specify the USB stick drive letter. All the rest is OK. jaclaz

I do believe you, rest assured. PRELIMINARY STEPS: Open a drawer. Put inside the drawer the 2G stick AND the SD card. Close the drawer. Lock it. Put the drawer key in a self addressed envelope and send it via snail mail to yourself. The above are to avoid confusion. REAL STEPS : get latest mkmigrateinf.cmd http://www.msfn.org/board/index.php?act=at...st&id=27356 copy it somewhere insert the 8G stick (you should have not any other ones around) take note which drive letter it gets open a command prompt and run mkmigrateinf.cmd <driveletter_of_the_stick>, example: mkmigrateinf.cmd G: it should produce a migrate.inf file verify (using my batch or whatever) the ParentIdPrefix within it replace the existing migrate.inf on the 8G stick with the one produced IF it matches what was said before jaclaz

[sarcasm] This HAS been asked before, and the answer has been all the times: Why do you think people found this difficult method if simply exchanging the boards would work? It has been also put into music by Bob Dylan: [/sarcasm] [serious] You would have TWO not working drives, and it is even possible that when you return the board borrowed to the drive where it was, you will still have TWO not working drives. DO NOT do it! [/serious] [sarcasm] It depends, this method does not do anything to existing partitions, as long as they were originally formatted in a month without the "r" in it's name (it's urdu name of course) and that were NOT partitioned with full moon. [/sarcasm] jaclaz

Surely NO. The code I posted was just a quick and dirty hack to show what ParentIdPrefix is written into a given EXISTING migrate.inf file. You posted: "a" USB_history.txt "a" migrate.inf file Each migrate.inf file (as made by mkmigrateinf.cmd mkmigrateinf2.cmd) contains one and one only ParentIdPrefix. Rather obviously the migrate.inf that goes on a device MUST use the ParentIdPrefix of that device if you want the device to get letter U:. What I suspect, and that till now you completely failed to help finding out, is that you have on the 8G stick a WRONG (i.e. with a different ParentIdPrefix) migrate.inf. Since you keep doing the three card shuffle: http://en.wikipedia.org/wiki/Three-card_Monte with sticks and methods, it is very easy that files were exchanged. What you should do is to make sure that the migrate.inf on the 2G sticks uses the ParentIdPrefix of 7&1554d726&0 and that the 8G uses the ParentIdPrefix of 7&d825748&0 (as resulting from the USB_history.txt file you posted). The small batch migrate2txt.cmd I posted should be copied to the same directory on the stick where migrate.inf is, then you open a command prompt and run it from there. The result should be the actual ParentIdPrefix that is inside the actual migrate.inf on that stick. Hope the above is clearer. jaclaz

You are still going for "statistical results" instead of trying to pinpoint (and hopefully solve) a single problem at the time....:whistling: However the Acer5738 appears as troublemaker. The info you posted however is incomplete without knowing which info is in the migrate.inf that you used with each device, quite obviously you managed to produce a "right" migrate.inf for the 2G stick, that gets U: on all systems but apparently failed with the 8G one. jaclaz

OK, the 2 Gb is a Phison (and you don't want to touch it since it works allright), the 8 Gb is a Skymedi. Both are re-branded with Vid 0951 (Kingston) and Pid 1607 and Pid 1623 respectively (Kingston internal model designation). If you go to a machine where the sticks were connected and open with Regedit the key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR\ You are likely to find keys named something like: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR\Disk&Ven_Kingston&Prod_Data_Traveler&Rev_1.00 or HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR\Disk&Ven_Kingston&Prod_Data_Traveler&Rev_ and in a sub-key with the name of the serial number, most probably, and respectively: \5B82050053DD&0 \00137297175CF971862F0A39&0 (the above is pretty much unuseful, as we already know this data from the USBhistory.txt you posted, but now you know how it works, more or less) 2Gb ParentIdPrefix=7&1554d726&0 8Gb ParentIdPrefix=7&d825748&0 The migrate.inf you posted is for a ParentIdPrefix=7&d7f206a&0 which corresponds to the drive H:\ (Generic- Multi-Card USB Device) in the USBhistory This may be of use: @ECHO OFF ::migrate2txt.cmd rudimental batch to extract ParentIdPrefix from migrate.inf file ::by jaclaz ALPHA 0.01 Release 6th November 2009 SETLOCAL ENABLEDELAYEDEXPANSION SETLOCAL ENABLEEXTENSIONS SET TEXT= FOR /F "skip=7 tokens=* delims=" %%A IN (MIGRATE.INF) DO ( SET UNICODE=%%A ) SET UNICODE ECHO. SET SPACESUNICODE=%UNICODE:,= % FOR %%? IN (%SPACESUNICODE%) DO ( IF NOT %%?.==00. ( CALL :bin2txt %%? SET /P Var=!s!<NUL SET TEXT=!TEXT!!s! ) ) CLS SET UNICODE ECHO. SET TEXT="%TEXT:@=&%" SET TEXT=%TEXT:§=?% SET TEXT ECHO. SET Prefix="\??\STORAGE#RemovableMedia#" SET BEGIN=%TEXT:~0,28%" IF %BEGIN%==%Prefix% SET ParentIdPrefix="%TEXT:~28,11%" SET ParentIdPrefix GOTO :EOF :bin2txt Set s=%1 For %%A In ( 23# 26@ 2D- 300 311 322 333 344 355 366 377 388 399 3A: 3B; 3D= 3F§ 41A 42B 43C 44D 45E 46F 47G 48H 49I 4AJ 4BK 4CL 4DM 4EN 4FO 50P 51Q 52R 53S 54T 55U 56V 57W 58X 59Y 5AZ 5B[ 5C\ 5D] 61a 62b 63c 64d 65e 66f 67g 68h 69i 6Aj 6Bk 6Cl 6Dm 6En 6Fo 70p 71q 72r 73s 74t 75u 76v 77w 78x 79y 7Az 7B{ 7D} ) Do Call :DoPairs %%A GOTO :EOF :DoPairs Set _=%1 Call Set s=%%s:%_:~0,2%=%_:~2,4%%% Goto :EOF Cannot say why the migrate.inf resulted for another device. jaclaz

So, if I get it right: everything goes well with the 2 Gb stick everything goes wrong with the 8 Gb stick everything goes wrong with the SD card Let's for the moment FORGET about the SD card, we will get there later (or if you prefer, please talk with me about the sticks and talk with cdob about the SDcard, everyone has his own "specialities" - or at least sometimes different approaches) You still have the 2Gb stick, do you? If yes it would be interesting to have the output of Chipgenius: http://www.boot-land.net/forums/index.php?showtopic=4661 http://www.mydigit.cn/chipgenius.htm for both sticks AND the result of running mkmigrateinf.exe: http://www.msfn.org/board/profiles-directo...819-page-9.html http://www.msfn.org/board/forcing-system-d...973-page-7.html on a system with BOTH sticks connected. jaclaz

The "do not unplug" actually means "always boot from the USB stick". In a "normal" setup you just reboot between steps, leaving the USB stick in. In a "special" setup, instead of rebooting you switch the PC off, take the USB stick off, do whatever you need to do on it on another PC, then re-plug it and then switch the PC on again, booting from the modified stick. BUT you can modify the BOOT.INI adding the additional entries BEFORE even starting the install procedure. jaclaz

Well, NO. I INSIST that "there is always a solution" IF the asking member PROVIDES a clear, detailed, report of what he did. Look, we are at post #10 in this thread and not ilko, not myself have a clear idea of what the heck is the problem. You seem to jump back and forward from USB_multiboot10 to cdob's RAM based method completely faling to properly report the steps you have taken. They may be very clear in your mind , but rest assured they are not in ours, possibly because wre are a bit thick , but maybe also because you failed to explain the issue. Why don't you forget anything you've posted till now and make a new post reporting in order all the steps you taken, the problems you had, etc., etc., I am sure you already did so in fragments, but we seem unable to put all the fragments together properly. jaclaz

You are reading "this" and "this" is the XP install one, nothing less, nothing more. If the question is "is it possible to multiboot from USB choosing among several .iso images?": The UBCD is possible and documented. The Memtest also. Start reading here: http://www.boot-land.net/forums/index.php?showtopic=5041 BUT read here also: http://www.boot-land.net/forums/index.php?showtopic=8944 There is not a definite "windows 7" report/tutorial/howto: http://www.boot-land.net/forums/index.php?...=5041&st=26 http://www.boot-land.net/forums/index.php?...ic=9038&hl= http://www.boot-land.net/forums/index.php?showtopic=9076 If you are "windows 7" oriented you may want to try the workarounds and contribute to the solution, or experiment with "this" porting the method to Windows 7. jaclaz

I see that you are new to this, it's common practice. psychological warfare against stoopid hardware: disassembling it a few times really scares it, but you may also want to have a mallet or large hammer handy and start singing something like "How would I love to smash this stoopid thingy with this large hammer I happen to have here" to the tune of your preferred song. The effect is that usually things start working again ..... A chainsaw has also proved to be a very good intimidating method, but it's a bit noisy and hardware won't fall for it if it isn't running. jaclaz

What was it? How it was solved? (just out of curiosity. jaclaz

Then, if you have nothing to lose, I would first try re-flashing the original firmware. jaclaz

I hope AFTER having thoroughfully backed up the recovered data. Or did you took your chances one time too much? Really cannot say if repeating the "unbricking" procedure with the new firmware will give any "advantage". jaclaz

Visual example: http://www.llamma.com/xbox/Repairs/thompson_dvd_tray.htm jaclaz

What is sometimes difficult to explain is that a License to use software the possession of the actual media on which the software is stored the redistribution of non-redistributable software Are three different things, in the specific Microsoft case: the license may be : "full" i.e. you are entitled to use a single instance of the OS on "any" hardware "OEM" i.e. the validity of your license is limited to a single instance of the OS on a single specific machine, to which the license is tied "VLK" (improper term, but widely used) in which the license is for a given number of machines the media may be: "Full", a normal installation CD/DVD "OEM", a normal "OEM" disk, i.e. identical to the above but with different keys or "specific OEM" like the ones Dell or HP gives/gave, and/or with specific provision to only work on the given machine "VLK", (again improper), a "normal" installation disk, identical to the first but with different keys NON-existant, like the recover CD/DVD's some OEM's give or the contents of the "Recovery partition" those OEM's that wish to save 0,05 US$ of a CD/DVD NON-existant , like other OEM's that give you the possibility to create an actual install CD/DVD from a "recovery" or "hidden" partition the downloads rule are rather simple: any download NOT from Microsoft or one of their partners is NOT "original", but the "general" EULA for the OS is often superseded by single licenses that actually allow for redistribution The point is that you can find on the internet (excluding warez and torrents ) a number of apparently "legit" (and most probably actually so) sites, software houses and what not that put inside their products or as part of "customer support" or whatever entire or rather "full" chunks of the OS files, just as an example this thingy here: http://www.boot-land.net/forums/index.php?...ic=9133&hl= much to my surprise turns up as containing a rather "full" PE 2.x .iso How can one say if that is legit or not? However what really counts is the actual number and type of License you have: 1 machine=1 license 2 machines=2 licenses 3 machines=3 licenses ... 5 machines=5 licenses ( or 1 "VLK" license for 5 machines) .... For OEM licenses it is: 1 machine=1 license for the specific hardware ... jaclaz

CD/dvd drives can be made in very different ways. Basically the mechanism that lowers #2 has not enough force to work when the retaining action of the magnet is added. Usually (but it may not be the case of your particular CD/DVD drive) it is due to some dirt (or clogged with dirt or simply "hardened" grease/lubricant) somewhere in the sliding parts. As well ususally completely and thoroughfully cleaning ALL sliding parts and adding a very minimal amount of lubricant is enough to make the drive functional again. In some cases there is wear that produces some dents in the sliding parts that need to be smoothed off with very fine sand paper or the like AND polished. The good ol' CD repair FAQ gives some hints: http://www.repairfaq.org/sam/cdfaq.htm jaclaz

Actually a SCSI 320 15K is not that bad : http://en.wikipedia.org/wiki/SCSI and remember that you usually get what you pay for (talking of new drives), as an example: http://www.superwarehouse.com/Seagate_Chee...356SS/p/1538711 http://www.superwarehouse.com/Seagate_Barr...813AS/p/1538714 Of course if you are looking at price per Mb, SATA wins hands down, expecially on the large sized hard drives that are becoming common nowadays. The size of buffer and rotational speed may make a difference: http://faq.storagereview.com/tiki-index.ph...formanceFactors Try going here: http://www.storagereview.com/Testbed4Compare.sr choose "Average Write Access Time" then check a "Seagate Cheetah 15K.4 147 GB" and a "Seagate Barracuda ES with NCQ (750 GB SATA)" and click on "head to head comparison". Repeat for any couple of drives you would like to compare. jaclaz

You'll have to find your way yourself, but check on boot-land for posts by member online, he did some work with Truecrypt encrypted sticks, of which cannot say how much and if it can be "ported" to your idea: http://www.boot-land.net/forums/index.php?showtopic=5315 http://www.boot-land.net/forums/index.php?showtopic=5397 http://www.boot-land.net/forums/index.php?showtopic=7342 http://www.boot-land.net/forums/index.php?showtopic=8096 It would much easier if you would use grub4dos password protection features: http://www.boot-land.net/forums/?showtopic=2984 http://www.boot-land.net/forums/index.php?showtopic=4718 jaclaz