jaclaz

@ragnargd I presume this originally inspired you: http://thpc.info/dualboot.html EasyBCD (which BTW by now is not anymore free) uses (senselessly) .Net, but much worse than that, uses grub4dos, "renaming" it as "neogrub" (and pointing to the help/references of GRUB legacy). There are several ways to make a triple boot 7/XP/9x system, the mentioned guide is suitable (though using unneededly and only in order to make it "easy" the EasyBCD tool) for a multi-partitioned single disk. Since you are using several devices (it is not clear to me whether you are using 2 or 3 SSD's, one is for 9x and there are other 2 for 7 and xp or just another one for xp/7 "together" ) there are simpler/better ways (and several different options). Only the triple booting alone would need a separate (longish) thread as well as having 9x running on a modern hardware (and with more than 1 Gb RAM) - as a matter of fact such of these long topics already exist. Very loosely the situation is the following, you have: an (oldish) OS that uses NOT a bootloader and NOT a bootmanager (9x) a OS (XP) that uses a bootloader that can double as (limited) bootmanager (NTLDR) a OS (7) that uses a bootloader that can double as (limited) bootmanager (BOOTMGR) optionally a (good) bootmanager that does not double as bootloader (grub4dos - or the "renamed" neogrub) optionally other sets of tools (MBR loaders, redirecting bootsectors and what not) There are more possible combinations of them than you can possibly want to know, out of all the possible ones you made your choice ("right" or "wrong" doesn't really matter ) which is OK (as long as it works for you) the point beiing simply that other people may want/need (and can have) a different approach that is more "suited" for them. jaclaz

Didn't you ALREADY get a possible solution to this? http://reboot.pro/17636/ jaclaz

So you get OEM PCs with Win7 until 2014. http://www.zdnet.com/how-to-skip-windows-8-and-continue-using-windows-7-7000001734/ Spot the differences : Fictional conversation (Phone call or e-mail exchange) #1 that will happen in - say - January 2013 (in the case Windows 8 sells not as good as expected): Fictional conversation (Phone call or e-mail exchange) #2 that will happen in - say - January 2013 (in the case Windows 8 sells very well): jaclaz

The code is right, the .iso is not, and - besides - you are in the wrong place. This is "Install Windows from USB", although some of the methods do use grub4dos, it is NOT titled "grub4dos" or "grub4dos support forum" or "since a few guys that use grub4dos hang around here feel free to ask any questions about grub4dos". You: FORGET about getting an XP recovery iso from the internet go here: http://reboot.pro/ Where you will find SEVERAL different threads/ways/methods to boot a XP recovery .iso from USB ("flat", as ".iso" and as ".img") after having MADE yourself the Recovery Console. This is one (that contains also several links to related threads): http://reboot.pro/5316/ BEFORE it, please read these two: http://reboot.pro/8944/ http://reboot.pro/5041/ jaclaz

Yep, so why don't you use a smaller disk image mapped to --mem (which will be loaded faster AND will live you more RAM free AND will give you no issues with EMM386)? This was the idea of the questions about "size" of the image.... You can have a second image mapped "normally". You can even try having the same image mapped another time (without --mem), in which case you can use copy or Xcopy from DOS to save to it Or you can try using a dd port to dos to image the drive mapped in --mem before rebooting. An oldish one should be here: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/gnuish/ in gnufut21.zip: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/gnuish/gnufut21.zip (there may be several other programs suitable) jaclaz

Actually the "original" code is "the right one". For *any* reason that BIOS does not detect "properly" the device Cylinder number. How big is the device? Grub4dos detects 9729*255*63*512=80,023,749,120 (roughly 80 Gb) The BIOS is limited seemingly to 1023*255*63/512=8,414,461,440 i.e. the last CHS limit of around 8 Gb The check before the remapping: checkrange 0x80 read 0x8280 && map (hd0) (hd1) checkrange 0x80 read 0x8280 && map (hd1) (hd0) map --hook Is to avoid the remapping if - fr any reason - the (Hd like) USB device is not mapped as first disk (this might happen in, say, 1% of cases or less), the device one boots form is first device in (still say) 99% of cases. Removing the check: map (hd0) (hd1) map (hd1) (hd0) map --hook is valid for this (fictional) 99% of the cases but it will fail in the remaining 1%. The suggested "manual command": is not "strictly needed" (it is only a good habit to "establish root and verify the filesystem is accessible" before actually booting from it),it makes a lot of sense if you later chainload the bootsector of that filesystem: chainloader (hd0,0)+1 since root has already been established, you can replace the above with: chainloader +1 From the result of the test it seems like the drive is mapped correctly (as drive 80), but something is "wrong" with establishing (or mantaining) current root. There should be - in theory - no need to establish a root to a volume if affterwards you chainload the MBR of the device (and not the PBR/bootsector of the volume). What happens is probably that the: rootnoverify (hd0,0) BUT, using instead: root (hd0,0) should be good also, somehow "resets" the size (number of cylinders) issue. You should try again the set of commands Steve6375 suggested BUT on command line (that should be ALWAYS used when troubleshooting) to better understand which exact command provokes the posted warning. The last two commands (before the "boot" needed on command line) should all work the same: root (hd0,0) chainloader (hd0)+1 root (hd0,0) chainloader (hd0,0)+1 root (hd0,0) chainloader +1 rootnoverify (hd0,0) chainloader (hd0)+1 rootnoverify(hd0,0) chainloader (hd0,0)+1 rootnoverify(hd0,0) chainloader +1 BUT, what may happen if you remove the check (as in the set of commands I suggested for tests) AND the BIOS doesn't map the USB device as first disk (1% of the cases)? The exchange takes always place, thus the internal disk becomes second disk and the USB device becomes first one. Since you chainload the MBR of the first device (which is the USB device), then you simply loop back to the grub4dos menu. At which point you can highlight the menu entry you were trying booting press "e", edit the menu.lstremoving the two disk re-mapping lines and try booting it again. The "queer" part is that you reported that the "first" part of the booting (that also contains the same checkrange commands) does work allright, so either the mapping of the imaged to the floppy disk devices or some timing problems or the difference between first boot (I presume a cold one) and the second (a warm one) seem to play a role in the issue. jaclaz

They are incomplete, which is another thing. I suggested you to try "A" or "B", what you posted (unless I missed something ) was: I tried "A" and it doesn't work (hanging at "A20 Debug: C806 done! ...") I tried "C" and it does work. It is not "by design". And it is not even an error, it is a "Warning". If you calculate EXACTLY the size of the disk image, counting the "default" 1 head (63 sectors) of "hidden sectors" (comprising the MBR) + the EXACT size of the partition on it (respecting the head/cylinder boundaries that FDISK or more generally any MS partitioning software up to XP/2003 do respect when making the partitions) you won't have that warning. Compare with: http://reboot.pro/?showtopic=3191 http://reboot.pro/9033/ Additionally (and this somehow and very loosely "connects" to the question about the size of the image) the BIOS used by Qemu (BOCHS one) is very "picky" and will use - depending on the size of the hard disk image that you create - an "orthodox" geometry, which in your case is a n/16/63 one, unlike the one you will have on *any* common "real" hard disk, which will be a m/255/63 one (and this may create some issues). Yes, the question was aimed to understand if you could make it smaller and try mapping it to --mem and/or using memdisk for it. You can try making the image with a different geometry, try loading it to --mem or with memdisk, try replacing EMM386 with another memory manager. jaclaz

It must be a very sophisticated piece of electronics.... WHY? [1] WHY? [2] This: (with all due respect ) sounds to me a lot like: I have not even the faintest idea on how to properly setup a multiboot system with Windows98, XP and Windows 7, by pure chance I found an app that *somehow* does what I needed, thus I recoomend everyone to use this method. This simply makes no sense : WHY?[3] WHY? [4] Mind you, you have all the rights in the world (and even one more) to have your opinions and report your experiences, but when you "recommend" or say "don't do this" or "You shall not" , there should be some (possibly "sound") reasons behind these statements. jaclaz

Anyone noticed how the image: effectively inspires something new, futuristic and never seen before... You know, like: http://fineartamerica.com/featured/fifties-retro-zero-charles-ragsdale.html or: jaclaz

No. You mistyped something. You just have established root on that volume, so it does exist. root (hd0,0) chainloader +1 should work. Anyway it doesn't matter, it was just a test to "jump over" the MBR code, if for any reason it had issues. The checking is "flawed" not because it is in any way "wrong" (it is not) but it relies on the behaviour of the BIOS, and a large number of BIOSes are "badly" coded or "non standard". jaclaz

Well, try using PHOTOREC ("companion" of TESTDISK): http://www.cgsecurity.org/wiki/PhotoRec apart the name, it will attempt to recover *any* file. Photorec attempts to determine the file type, in some cases it may get the "wrong type" (and consequently the file may not open properly or be not recognized by the "appropriate" software. A good idea would be to re-scan the recovered files with TRiD: http://mark0.net/soft-trid-e.html which has a more accurate "detection" engine. About filenames, consider that most "office" files do have some "metadata" that normally include the filename with which they were saved. If the filenames are important, you can scan them with a suitable program and recover this "metadata" (how exactly depends on the exact file types) Roughly, and on "Gb size" of the filesystem (FAT32), there are 2 sectors of FAT per MB. So, if the stick was "labeled" as 8 Gb, the beginning of 2nd copy of the FAT tables was likely around sector 16000, if it was 16 Gb, around sector 32000 and if 32 GB around sector 64000, which means that (in the hypothesis that you were actually very near the real physical size of the stick and what happened was a "wrap-around" of the 19 Mb), if the stick was 32 Gb, the second copy should be "intact", if 16 Gb it is "likely", if it was 8Gb there are very little or no chances. Having a look at the the image with Dmde: http://softdm.com/ won't do anyway any harm. jaclaz

I will try again (last time ): does 0.4.4 2009-16-10 version work? It is not difficult, a yes or no would be enough, though of course knowing (if no) if it behaves the same as the 0.4.5.c version would be nice. The error about the hard disk image is "normal", it depends on the way you made the hard disk image. *any* "real" hard disk image (in the sense of image of a"real" hard disk) and *most* hard disk images (if built without using some "special" care) will have some UNindexed space at the end. What grub4dos is trying to tell you is that the data on the MBR and in the PBR(s) of the volumes "cover" only 263088 sectors while your image is larger than that. You can "truncate" the image at the correct size. The DOS errror with EMM386.EXE is likely to be UNresolvable if not by doing several different tests. WHY do you need such a large DOS image (around 135 Mb)? jaclaz

The kernel has nothing to do (it is never involved in this part of booting) only NTLDR or the actual NTFS filesystem may have to do with the issue, but sincce the same worked in the VM, you are right it is a "hardware" connected issue. jaclaz

Yes and no. What happens, if it is one of the "fake" sticks I was referring to, is that data copied to it (once the "real" capacity of the stick is reached) "wraps around", overwriting the initial part of the stick. Since this area (initial part of a - I presume - FAT32 formatted) stick holds the FAT tables, it greatly depends on two factors: how big were the original FAT tables how many data has been copied to the stick "beyond" it's real size which sums up on "how many of the FAT tables is still there". There is still anyway the possibility to recover some data as "files" (i.e. recover not the filesystem but only it's contents), you will get most of the data (losing the filenames) unless there is "heavy" defragmentation. Without further data (what were the contents, wif you have only a few files that you are interested in, how big was the last copy operation on the stick) cannot say more about the suggested way to proceed. jaclaz

You are welcome. The issue here is that the file you posted is NOTHING like it should be. I will (exceptionally for you) take my crystal ball out of it's (dark red) velvet wrapping and tell you what I can see in it : you bought a largish (let's say 16 or 32 Gb) stick on e-bay or however on the Internet and not in a shop you payed for it a very convenient price you used the stick for some time without any issue, until one day (possibly today) you copied to it a few files - likely some .pdf's and .xls's and filled it up above around 2Gb suddenlly you cannot access it anymore Let me know how much of the above is correct and (this is the MAIN thing) approximately how big (roughly) were in total the set of files that you copied to it just before it wasn't anymore accessible. jaclaz

Change this: title Part 1 Install OEM XP - Text Mode map --mem /WinVBlock.IMG.gz (fd0) map --mem /WinVBlock.IMG.gz (fd1) map /dellsp4.iso (0xff) checkrange 0x80 read 0x8280 && map (hd0) (hd1) checkrange 0x80 read 0x8280 && map (hd1) (hd0) map --hook chainloader (0xff) title Part 2 Install OEM XP - GUI Mode map /dellsp4.iso (0xff) checkrange 0x80 read 0x8280 && map (hd0) (hd1) checkrange 0x80 read 0x8280 && map (hd1) (hd0) map --hook chainloader (hd0)+1 TO this: title Part 1 Install OEM XP - Text Mode map --mem /WinVBlock.IMG.gz (fd0) map --mem /WinVBlock.IMG.gz (fd1) map /dellsp4.iso (0xff) map (hd0) (hd1) map (hd1) (hd0) map --hook chainloader (0xff) title Part 2 Install OEM XP - GUI Mode map /dellsp4.iso (0xff) map (hd0) (hd1) map (hd1) (hd0) map --hook chainloader (hd0)+1 You should be able to get a little further (maybe). OR (better) instead of using the menu.lst, use command mode (on the second part) entering commands one by one on the command line and pressing enter after each one: map /dellsp4.iso (0xff) map (hd0) (hd1) map (hd1) (hd0) map --hook Here, instead of: chainloader (hd0)+1 Enter: root (hd0,0) You should get a confirmation message with some relevant data on the partition on the hard disk, if yes then: chainloader (hd0,0)+1 you should get something like "will boot NTLDR...." now enter: boot What happens? Please report the output of the above commandsbesides a description of what ahppens and if it hangs at which command it does so. jaclaz

Well, first thing you should make a copy of the stick. I.e. do what was already suggested in post #11: (this thread is quite oldish and some tools have changed but that post is still valid) To identify the \\physicaldrive number open Disk management, the boot disk (the one on which you C:\ normally is) will be disk 0, if you only have the USB stick (besides the bootdisk) it will be disk 1. (if you are in this "standard situation", i.e. without other disks and without one of those multi-card reader, the stick wiil be disk 1) Disk manager may (please read as will) ask you to "initialize the disk" (because of the missing 0x55AA), DO NOT let it do this. http://reboot.pro/12253/#entry106759 Or you could use datarescuedd, which is GUI and easier to use: http://www.datarescue.com/photorescue/v3/drdd.htm then use the dsfo to extract first 100 sectors (supposing the "full" stick image is C:\mystick.img dsfo C:\mystick.img 0 51200 C:\USB_100.img compress C:\USB_100.img in a .zip file and attach it to your next post. Once you have the image and posted the initial snippet, will see what we can do. jaclaz

, my hard drive is 7200.12 while all of these topics are entitled 7200.11.. therefore my main concern at this point is to figure out what tools suitable for my drive in case I'd have to buy them online, I'd need to order them as soon as possible because of the LONG shipping time.And believe me, I'm not setting around waiting.. I'm searching the web trying to find topics about the same drive, or 7200.12 drive. The same tools. Here we have a (actually the ONLY one) report of success wiith a 7200.12 that actually started the whole procedure thinking he had a 7200.11...: jaclaz

Nice to see you peeking around from time to time. About the adapter (and of course this is NOT an advertising of any kind) it seems like I found a good candidate (which does include a "Seagate" connector): at a "fair" price (depending on from where you manage to get it). jaclaz

Yep , the point being that if you want to "replace a string of text in a file", a tool designed to "replace a string of text in a file" often is more suited than using a "generic" (scriptable) command processor (as when using it, it may hit some limit or anyway take more time/resources than a, specific, dedicated, tool). As you might well know, I do believe that the simplest solution (for simple problems) is a bunch of lines in a batch (and I do have my part of fun playing eith them batches), but when you are trying to do something that is not simple and you have a command line, specifically designed for the specific chore, external tool, then it's usually better to use it . jaclaz

No. It is actually DEPRECATED (by me). Which you would have already learned had you READ the "Read-me-first": particularly point #10 AND the FGA's: particularly #6 BTW the whole idea of the above threads is to : jaclaz

The only explanation that I can find is that *somehow* your initial attempt (post #1) with TESTDISK produced a "wrong" MBR and/or PBR. The standard NT NTFS drivers finds *something* wrong and decides that the volume needs to be formatted. Dmde more or less "ignores" them, analyzes the filesystem, finds the "real" $MFT and thus lists all your files "as they were". (then some may be there and some may be in the missing part and thus unavailable). TESTDISK finds the (wrong) values it initially wrote and reads an "empy" $MFT. Dmde is not very "easy", let's see if I can guide you into checking the data. Once you have loaded the $MFT (open Dmde, choose the image, search for NTFS), you should have on the left pane [All Found], if you expand it clicking on the + sign, it should read the $MFT and show everything that has been found. Besides each file or directoryyou should have again a + sign. Double click a directory (where you know one suitable file should be), the contents of the directory should appear on the right top pane. Choose a (small) file of which you know the beginning of the contents (like a text file or a small program or a zip file), ideally use for the test something that belongs to the original XP install (and that thus it is likely to be in the first 134 Gb). In the lower pane you should see the hex dump of first sector of the file (if it is there, if it is not, try with another file that you can "recognize the beginning" and that "is there") and, in the first line something *like*: The LBA value is the absolute address of that sector, the vol.sec is the relative address within the volume. Do post these values. How much is LBA-vol.sec? i.e.: 89021727-89021664=63 in the above example. This would confirm that he volume starts at offset 63. How much is vol.sec/clus? i.e. 89021664/11127708=8 This would confirm that cluster size is 8 sectors. Then, do something "crazy" make a new backup of both the MBR and of the PBR (better have another copy), then open the image in tiny hexer and: access the MBR sector and fill it with 00's access the PBR sector and fill it with 00's Run again Dmde on the image with the 00ed MBR and PBR and see if the results on the same file are the same as before. jaclaz

...but you cannot read . First post of this thread: Read ATTENTIVELY point #1. Then start a new thread, if needed, and ONLY AFTER having searched for 7200.12 info (that you won't find in this thread which is ONLY about the 7200.11), you know, like this one, last active a lot of time ago, like yesterday: page__view__findpost__p__1014387 actually already containing links to "all we know" about the 7200.12. jaclaz

And gsar doesn't work for it, right? jaclaz

Oww, come off it! I do believe that you managed to find a way to break that limit What I wonder is : HOW OFTEN this happens WHY the good MS guys didn't (as they often do for much serious matters) say "it's by design" Back to your finding: What is the actual GOAL of that snippet (obviously it is not that of ECHOing a long string of comma delimited numbers to the screen)? Are you really sure that you need a XP CMD.EXE (and thus - to be "kosher" - an additional license besides the 2K one) to reach that goal? (or there are workarounds or different methods to achieve it still using the 2K CMD.EXE)? jaclaz