jaclaz

You need a slash (or a full device path) for the filename. root (fd0) dd if=/Sec_6571.bin of=(hd0)65+1 bs=512 count=1 or: dd if=(fd0)/Sec_6571.bin of=(hd0)65+1 bs=512 count=1 Yep, thanks , I meant that the change in the MBR happened after the "cloning", which means that the "cloning" somehow missed the MBR code (as I cannot believe that the "original" had no MBR code as "some" MBR code is written by "every" common tool and anyway the "otiginal" could not have booted). Yes, the partition table is seemingly fine, no problems there: Entry Type Boot bCyl bHead bSect eCyl eHead eSec StartSector NumSectors #0 0B 80 0 1 1 1023 254 63 63 75327777 #1 0F 00 1023 254 63 1023 254 63 75327840 2812320 #2 00 00 0 0 0 0 0 0 0 0 #3 00 00 0 0 0 0 0 0 0 0 jaclaz

Good to know . Do you mean that it was the (booted from floppy or chainloaded by grub4dos) WIN98 that wrote that on the "new" (cloned) disk? Still it is curious how EITHER the original disk had OR the "cloning" program managed to make a "code blanked" MBR. jaclaz

Well, then you are asking a "wrong" question, i.e. you are risking to fail for the chocolate covered banana : https://jdebp.eu/FGA/put-down-the-chocolate-covered-banana.html WinSetupFromUSB is simply not the "right" tool for the scope. You can add grldr.mbr (which is part of grub4dos and NOT of GRUB) as an entry to your existing \boot\BCD (it is not really-really an "install") or deploy the code that chainloads grldr (which is still the same grldr.mbr) to the MBR and thus set grub4dos (and NOT GRUB) as your "main" bootmanager. Until the (stupid) windows 10 it was easy to add a grldr because the BOOTMGR parsed the good ol' BOOT.INI file, starting with 10 it is needed to add the grldr.mbr to the BCD, see: http://reboot.pro/topic/21527-windows-10-bootmgr-no-longer-reading-bootini/ You can get the latest version of Bootice from Softpedia, here: https://www.softpedia.com/get/System/Boot-Manager-Disk/Bootice.shtml And the latest version of grub4dos here: http://grub4dos.chenall.net/downloads/grub4dos-0.4.6a-2018-09-19/ If you don't want to touch your MBR (and a few sectors after it) and don't want to fiddle with the \boot\BCD, you can still try installing the grldr on the 500 MB partition (more like your original plan) but it has to be seen how it works with latest versions of grub4dos. Traditionally (with the "standard" MS bootsector loading NTLDR, i.e. the 2K/XP bootsector for FAT32) it worked just fine with grldr renamed to NTLDR: http://reboot.pro/topic/4423-start-grub4dos-grldr-from-nt-bootsector-why-not-working/ Since your current volume bootrecord is invoking BOOTMGR, you will need to run bootsect.exe with the /NT52 switch on the volume to write the MS bootsector code invoking NTLDR, then copy to the volume the grldr renaming it to NTLDR. The "sample" menu.lst in the grub4dos download already has a provision to automatically search for and chainload a BOOTMGR, so you should be able to boot to your Windows 10 without issue after the "install" of grub4dos. Then we will see how to boot the Linux and make a suitable menu.lst entry for it. jaclaz

I am not sure to understand. Copy /b means "force" copy to copy binary data (i.e. "as is"), notmally (but it depends on versions if I recall correctly) copy will automatically switch to "/b" if it encounters binary data, but it is better to be sure and use the switch. I don't think that there is a /c switch in copy. Anyway, the file you posted is fine (in the sense that it actually contains the sectors I was interested in) . As expected there are two (separate) issues. Issue #1: the third sector of the VBR is blank (should contain boot code) Issue #2: the MBR code is (almost) blank Issue #1 may be due to some quirk of the program you used to make the "clone", the third sector of the FAT32 bootrecord of DOS/Windows 9x is actually the 3rd sector, whilst in 2K/XP and later it is the 13th (and in FreeDOS it is 15th), so a so-called-cloning program developed for 2K and later may well have provisions to clone the 13th sector because it assumes that the code is in it, "jumping" over the third sector . Issue #2 is stranger, the MBR code is almost blank with only four non-zero bytes written at offset 0xDC. no idea on what could have caused it . There are a few more minor issues, but nothing that cannot be fixed. Anyway, get the attached, it contains four files: Sector_0.bin <- this is the MBR or LBA0 (with your data AND the standard Win98 IPL booting code added) Sec_6369.bin <- this is the first sector of the VBR or LBA63 (and a copy of it is on LBA69), this is not changed as it is just fine, but see later in the instructions Sec_6470.bin <- this is the second sector of the VBR or LBA64 (and a copy of it is on LBA70) this is not changed as it is just fine. Sec_6571.bin <- this is the third sector of the VBR or LBA65 (and a copy of it is on LBA71) this is the "main" culprit How to fix the whole thing, after having copied these files to the floppy and booted from it : 1) deploy the third sector, in grub4dos: root (fd0) dd if=()/Sec_6571.bin of=(hd0)65+1 bs=512 count=1 at this point , if you run (still in grub4dos): root (hd0,0) chainloader +1 boot the system should boot to the DOS on hard disk C:\ (this is the same test #2 that previously failed) 2) write the MBR with the code (reboot from the floppy, get to grub4dos): root (fd0) dd if=()/Sector_0.bin of=(hd0)0+1 bs=512 count=1 at this point , if you run (still in grub4dos): rootnoverify (hd0) chainloader +1 boot the system should boot to the DOS on hard disk C:\ (this is the same test #3 that previously failed) So if both the above work , you should be pretty fine BUT there are a couple things still to do. Boot again to the floppy and grub4dos and: root (fd0) dd if=()/Sec_6571.bin of=(hd0)71+1 bs=512 count=1 <- this is to put the copy of the third sector where it should be dd if=()/Sec_6369.bin of=(hd0)69+1 bs=512 count=1 <- this is needed because (for *whatever* reasons) the copy of the bootsector has a wrong value in "sectors before" field If you have doubts/questions, ask them before doing something you haven't confidence with. jaclaz pathway.zip

Hmmm. It depends on which message they will get. https://www.zdnet.com/article/ms-linux-lindows-could-microsoft-release-a-desktop-linux/ jaclaz

Well, if I had to tackle the issue I would have a (temporary) English install of XP, and from it extract to .reg file the whole: HKEY > CURRENT > USER > Software > Microsoft > Windows > CurrentVersion > ShellNoRoam > MUICache then do the same on the Italian one and compare the two files. jacla

I am not sure I understand: https://ccm.net/faq/14662-windows-xp-change-the-name-of-the-recycle-bin or: http://www.syschat.com/how-rename-recycle-bin-windows-xp-5863.html (make the "rename" feature available) jaclaz

Hey, this is "Funny Farm", the whole point was about the info on MS support pages being blatantly incorrect. jaclaz

I suspected that. I checked and the 0.4.4.2009-10-16 actually has the internal dd command (in an early version, anyway working ), but you need the "target file". Since you have SYS.COM on the diskette, that is around 19 KB, do the following (booted to the DOS on the diskette, i.e. on the A:\> prompt): copy /b sys.com+sys.com+sys.com mysects.bin DIR mysects.bin you should have a file mysects.bin that is 56901 bytes (enough) Then: grub.exe on the grub4dos command prompt root (fd0) dd if=(hd0)0+100 of=(fd0)/mysects.bin bs=512 count=100 jaclaz

You have a phone? Luxury! ... why, in my day all we could do was to shout very loud to call someone! ... and we liked it! ... kids today ... https://tinyapps.org/blog/misc/200702250700_why_in_my_day.html jaclaz

... some say only on wednesdays, and if there is a full moon ... jaclaz

Good. Out of the dowload of grub4dos: http://grub4dos.chenall.net/downloads/grub4dos-0.4.5c-2016-01-18/ http://dl.grub4dos.chenall.net/grub4dos-0.4.5c-2016-01-18.7z you need only grub.exe. And out of the download of grubutils: https://code.google.com/archive/p/grubutils/downloads?page=2 https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/grubutils/grubutils-2011-06-27.zip you need only the "fat" file. General usage is here: https://www.rmprepusb.com/tutorials/grubutils#TOC-fat what you need to do (on grub4dos command line) is: root <- should give (fd0) as feedback insmod /fat fat mkfile size=51200 (fd0)/mysectors.bin dd if=(hd0)0+100 of=(fd0)/mysectors.bin bs=512 count=100 If you already made a new file 51200 bytes or larger on the floppy via DOS or any other means you can of course avoid the grubutils download and usage of the "fat" commands. jaclaz

It could be an issue with either the boot code (in the PBR) or with some data (again in the PBR, i.e. in the BPB or Bios Parameter Block). If I recall correctly, when grub4dos chainloads directly io.sys, it recreates the BPB data "on the fly" using the data found in the partition table. Clearly the partition table is fine (since the volume can be booted and DIR, etc, works just fine) and also most of the BPB must be "good enough" for exactly the same reasons. Is the volume FAT16 or FAT32? If the latter the situation is a bit more complex as the bootsector is spanned over three sectors. I need to see: 1) the MBR, i.e. sector LBA 0 2) the PBR, i.e either sector LBA 63 or sectors LBA 63-65 Basically, you should make a copy of first 100 sectors of the hard disk, compress the file into a .zip archive and upload the archive to some free hosting site or attach it to your next post, Now the issue is how exactly to extract these 100 sectors from DOS. How much available space do you have available on the boot diskette? You need 100*512=51,200 bytes ( the space for the 100 sectors) + the space for the program to dump them[1]. The 0.4.5c version of grub4dos (not the 0.4.4) does have a built-in dd command that would do (as long as you have any means to create an empty file 51.200 bytes in size on the floppy), otherwise we could actually use the (experimental) fat library for grub4dos. Try using the recommended 0.4.5c version of grub.exe, if it works it will be the easiest way to make the dump of the needed sectors. jaclaz [1] it's a lot of time I don't deal with "pure" DOS, I have not in mind a program capable of doing this in "pure" DOS and small enough to fit in a diskette, in the good ol' times DEBUG scripts were used, but it is some of the knowlefge that has been lost over the years, I cannot remember right now any suitable "pure" DOS tool

Provided that the hard disk is actually around 640 GB in size (or to be more exact it had a single partition of around 640 GB), DMDE actually found *something*. The 975 MB or around 1.02 GB in size image is too small to be meaningful (on any NTFS filesystem bigger than 5 or 6 GB the $MFT is placed on cluster 786432, which equates to roughly 3 GB). You can try "going on", selecting "$Noname 01" and then clicking on "Open Volume" but since no $MFT is available, your only option would be "file based" recovery (which is only good for files that were "contiguous"). A functional 640 GB or so hard disk should take (ddrescue is AFAICR an "average" speedwiseprogram) a few hours to be imaged, approximately between 2 and 4. So if you got 1 GB in 1/2 hour, imaging the whole disk would probably take more than 300 hours , which while not entirely unheard of: https://www.forensicfocus.com/Forums/viewtopic/t=11313/ poses a SERIOUS problem on the integrity of the disk. You need to make sure, d@mn sure, that the disk does not overheat, usually a fan (or more than one) are used to keep the disk "cool" when doing this kind of imaging that results in so many errors. But maybe it is the case of attempting to use a (if not better) more tweakable tool, that would be dd_rescue (and dd_rhelp): http://www.garloff.de/kurt/linux/ddrescue/ or ddrescue (and ddrutility): https://www.gnu.org/software/ddrescue/ddrescue.html (Linux only) Still, there remains a risk that by these attempts the situation worsens, so - once again - I have to ask you to consider whether your data/photos are worth (or are not worth) the possible cost of a professional data recovery service, if you continue there is a concrete possibility that if you later change your mind, the data/disk would be further degraded and thus made unrecoverable (the professiona that will make this later attempt, no matter what was the real cause will anywyay blame your attempts for the unrecoverability of the data). jaclaz

If via grub4dos it boots, then the system is just fine. Once you are in grub4dos (press "c" to get the grub4dos command prompt) there are THREE ways to boot the DOS/Win98 #1 chainloading the system file bypassing BOTH the MBR and the PBR (what is in the grub4dos "standard" menu.lst): find --set-root /io.sys chainloader /io.sys boot (the "boot" is NEEDED on command line and IMPLIED in a menu.lst entry). #2 chainloading the PBR of the volume, bypassing the MBR : find --set-root /io.sys chainloader +1 boot #3 chainloading the MBR: rootnoverify (hd0) chainloader +1 boot Doing the three tests above you will be able to check which part is "defective" and we will see how to "fix" it. SYS is an external command in DOS, so you need to copy it (SYS.COM) to the boot floppy if it isn't there for *whatever* reason. Please check (and double check) that the boot floppy (and the SYS.COM) come from the exact same version of DOS/Windows9x. jaclaz

... and I thought I was the one that would have failed in a diplomatic career ... jaclaz

You can try to not looking at the screen , and/or start saying aloud "I am not going to work with this computer today, it seems like a perfect day for a walk outside" or similar, maybe it works like boiling water for tea http://www.gutenberg.org/ebooks/308 http://www.gutenberg.org/files/308/308-h/308-h.htm and it decreases the amount of memory in use ... jaclaz

No, it isn't, or, if you prefer, it only happens on the vast majority of systems, but not necessarily on all of them. The booting PE has been documented to in some cases to detect disks in a different order from BIOS, and of course another number of factors may be involved, like the exact way the disk is partitioned (before or during the install) and the exact way the OS is installed (via normal setup, third party automated tools, dism apply, etc., etc.). Since it costs nothing at install times to disconnect the "other" disks it represent a foolproof way to make sure it doesn't happen. jaclaz

Let's try to clear the matter. Calling *anything* RAID without specifying its RAID level makes NO SENSE WHATSOEVER. RAID 0 is NOT properly "RAID" as there is NO redundancy whatsoever, it is only a senseless way to (maybe) achieve very slight read/write speed increases (which actually happened only on some given configurations making use of slow, now obsolete, devices and connection buses) at the (real) cost of a definite increase in the risk of failure. RAID 1 is actually "RAID", BUT it should be called simply "disk mirroring". You can have disk mirroring BOTH via hardware and via software, in the case of Windows, software disk mirroring is one among the modes "dynamic disks" can be setup. BUT at the end of the day, since the disks are actually mirrored, there are very little differences in practice on the contents of disks. Basically each disk is (or should be) an exact mirror of the other. In ordinary, day to day operations, you will notice no differences using the one or the other. When (if) disaster strikes and one of the two disks in a "mirrored" set fails, there are only a few slight differences, not really worth more than a thought. In the case of a "hardware" mirrored set of two disks, you can *any time* take the one (or the other) and connect it to another PC and it will be immediately recognized as a "normal", "self standing" disk, and you will be able to access its contents "normally". In the case of a "software" mirrored set of two disks, when you take the one (or the other) and connect it to another PC it won't be recognized "as is" and you will need to change the partition ID in the MBR from 42 to 07[1], and then it will be recognized as a "normal", "self standing" disk, and you will be able to access its contents "normally", even if a few sectors at the end of the disk (outside the normally accessed area) will contain "dynamic disk" settings data). The "hardware" mirrored set might be (slightly, you won't probably notice it) faster in operation. Of course the "software" and "hardware" mirrored set settings "do not communicate" as - even if the end result is the same or very nearly the same - the way they work is different. With hardware, you are essentially saying to the hard disk controller to write the data it receives to two different devices, with the software you are telling to the Operating System to write the data to two different connected devices. Personally if I were to choose, I would prefer a hardware mirrored set (aka RAID 1) over Dynamic Disks anytime, only because Dynamic Disks have historically given more problems, though the reason is not clear/straightforward, a possibility is that knowledgeable people (and with the available means to buy more costly hardware) chose either hardware mirroring or never chose "RAID 1" while a vast number of less knowledgeable people (and/or without the means to buy a RAID controller) chose the "free" Dynamic Disks mirroring, hence there are very few reports of issues with hardware RAID 1 and some more with "Dynamic Disks". jaclaz [1] Never tried/checked how these disk behave if GPT and not MBR, but most probably there will be a similar issue of chainging partition ID.

If the files can be seen by dir and you already fid a fdisk /MBR the only remaining thing is making sure that: 1) the partition is Primary and Active 2) the bootsector of the partition conatins valid code 3) the IO.SYS and other system files are actually there What I would do: 1) make a dos/Windows 98 boot disk with a copy of grub.exe (the grub4dos DOS executable) or make a grub4dos boot floppy (or USB stick/CD/whatever) 2) run grub4dos 3) attempt to boot the Windows 98 system on the disk by directly chainloading the system file This more otr less equates (on the grub4dos command line) to find how the disk is seen in the BIOS (it will be either (hd0) or (hd1)) and which is the partition where the DOS/Win98 is (normally first partition, i.e. either (hd0,0) or (hd0,1). So: geometry (hd0) geometry (hd1) if the disk is seen as (hd0) root (hd0,0) ls <- this should show the contents of the partition, like DIR chainloader /io.sys boot if the disk is seen as (hd1): map (hd0) (hd1) map (hd1) (hd0) map --hook root (hd0,0) ls <- this should show the contents of the partition, like DIR chainloader /io.sys boot You can use *almost any* grub4dos version, but I would suggest a 0.4.5c version, like: http://grub4dos.chenall.net/downloads/grub4dos-0.4.5c-2016-01-18/ http://dl.grub4dos.chenall.net/grub4dos-0.4.5c-2016-01-18.7z or, if it doesn't work (the Presario is an old machine and not many tests have been made with newer versions on old machines), a "historical" 0.4.4, last version of it, 2009-10-16 that you can find here: http://reboot.pro/topic/16641-grub4dos/ If you need help assistance in the usage, just post your questions/doubts. jaclaz

Again, not very good signs, actually bad ones. Basically a hard disk sector (which is normally seen as being 512 bytes in size) contains - accessible only by the internal citcuits/logic, a record that is a sort of checksum of the contents of the sector itself, called CRC or Cyclic Redundancy Check, this is a value, written at the time the sector is written that is checked when reading the data to make sure that it is valid. If you have a huge number of such errors, particularly if they come in "a bunch" at cyclical intervals it is likely a (but not necessarily) a failed head. The image won' t be successful, you can stop the imaging of the whole drive. You can or you cannot hear the hard disk "crunching" at intervals? If you stop the program you should still have available the (partial) image (the .dd file). Check it in a hex editor, or in DMDE. Is it all 00's or it does contain some data? All the symptoms till now are that of a failed drive, point is whether some partial data can be copied or not, and if these data are enough to recover (some of) the photos. If your photos have a value I would suggest you to stop fiddling with the disk and ask for the assistance of a professional data recovery firm. Typically we are talking of a cost of anything between US$ 300 and US$ 2000 and there is no guarantee that the photo can be recovered, most "serious" recovery firms (not very easy to find BTW) will ask you anything between US$50 and US$300 to "diagnose" the disk, and then will submit you an estimation of the cost of recovery (id possible). jaclaz

A semi-random thought, but maybe one could try actually disable the volume in HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices\Offline and then mount the volume "indirectly" (and with another drive letter) via IMDISK, that does have a "direct extent access" feature: http://reboot.pro/topic/20450-mounting-split-image/?p=192170 It has to be seen if volsnap.sys actually hooks also this IMDISK volume (that appears not in disk manager, etc. as it is basically a "superfloppy"). jaclaz

Isn't this one good enough? http://www.learnersdictionary.com/definition/spy jaclaz

Sure , I know, hence I explicitly specified "whatever remains of it on an internet connected machine". Now, who is soundings like a conspiracy theorist? Please don't forget a Velostat cap: http://reboot.pro/topic/13177-an-improved-electromagnetical-shielding-device/ you never know ... jaclaz

Not really. A conspiracy theorist would assume that since it is not documented the exact way the data is sent and which exact data is actually sent, then there must be something "evil" behind it. The two statements are instead simply meaning that something is not documented and this may (or may not) be a violation of privacy (whatever remains of it on a internet connected machine ). jaclaz