jaclaz Posted December 16, 2018 Share Posted December 16, 2018 (edited) On 12/16/2018 at 4:25 AM, pathwayus69 said: I do have one questions would it be copy /c other then b? 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 Edited December 18, 2018 by jaclaz Corrected wrong commands inserting "current root" i.e. () Link to comment Share on other sites More sharing options...
rloew Posted December 16, 2018 Share Posted December 16, 2018 The four bytes at 0xDC in the MBR is a signature that Windows 9x writes when there are only zeroes between 0xDA and 0xE0. Windows has big problems when the checksum of two MBRs are identical so it adds a signature to new MBRs or if blank. It corrupted one of my Amiga Hard Drives by doing that. Link to comment Share on other sites More sharing options...
jaclaz Posted December 16, 2018 Share Posted December 16, 2018 1 hour ago, jaclaz said: 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 . 21 minutes ago, rloew said: The four bytes at 0xDC in the MBR is a signature that Windows 9x writes when there are only zeroes between 0xDA and 0xE0. Windows has big problems when the checksum of two MBRs are identical so it adds a signature to new MBRs or if blank. It corrupted one of my Amiga Hard Drives by doing that. 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 Link to comment Share on other sites More sharing options...
pathwayus69 Posted December 17, 2018 Author Share Posted December 17, 2018 I've tried a few times using the dd command when I load grub command line I did the falling. root (fd0) the message below is Filesystem type is fat, using whole disk. dd if=Sec_6571.bin of=(hd0)65+1 bs=512 count=1 Error 11: Unrecognized device string, or you omitted the required Device part which should lead the filename. I did double check to make sure i have grub 4.4 and I is. I double check the cloning software i've clone software "EaseUS Partition Master 13.0" and gparted in linux both of them just see two partitions. The main one partition with os, and the other one which has the recovery drive. Link to comment Share on other sites More sharing options...
rloew Posted December 17, 2018 Share Posted December 17, 2018 11 hours ago, jaclaz said: Do you mean that it was the (booted from floppy or chainloaded by grub4dos) WIN98 that wrote that on the "new" (cloned) disk? It doesn't matter how you run Windows 9x. When it enumerates the Hard Drives, it checks each MBR and puts a signature in any MBR that does not appear to have one. Link to comment Share on other sites More sharing options...
jaclaz Posted December 17, 2018 Share Posted December 17, 2018 9 hours ago, pathwayus69 said: I've tried a few times using the dd command when I load grub command line I did the falling. root (fd0) the message below is Filesystem type is fat, using whole disk. dd if=Sec_6571.bin of=(hd0)65+1 bs=512 count=1 Error 11: Unrecognized device string, or you omitted the required Device part which should lead the filename. 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 3 hours ago, rloew said: It doesn't matter how you run Windows 9x. When it enumerates the Hard Drives, it checks each MBR and puts a signature in any MBR that does not appear to have one. 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). 9 hours ago, pathwayus69 said: I double check the cloning software i've clone software "EaseUS Partition Master 13.0" and gparted in linux both of them just see two partitions. The main one partition with os, and the other one which has the recovery drive. 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 Link to comment Share on other sites More sharing options...
pathwayus69 Posted December 17, 2018 Author Share Posted December 17, 2018 6 hours ago, jaclaz said: 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). Sorry I left the /Sec_ in my post but had tried that also, I will try "dd if=(fd0)/Sec_6571.bin of=(hd0)65+1 bs=512 count=1" The joys or working on older hardware/software but at lest am learning something. Link to comment Share on other sites More sharing options...
jaclaz Posted December 17, 2018 Share Posted December 17, 2018 (edited) 1 hour ago, pathwayus69 said: Sorry I left the /Sec_ in my post but had tried that also, I will try "dd if=(fd0)/Sec_6571.bin of=(hd0)65+1 bs=512 count=1" The joys or working on older hardware/software but at lest am learning something. I re-checked and yes, my bad , there is a little bug in the parsing of dd , grub4dos allows using [TAB] completion on command line after the slash, BUT the dd command actually needs "full" path, i.e. including the device. Adding the leading (fd0) should work. As well, once rooted to the device, you can use empty brackets (that mean current root), i.e.: root (fd0) dd if=()/Sec_6571.bin of=(hd0)65+1 bs=512 count=1 should also work. jaclaz Edited December 17, 2018 by jaclaz Link to comment Share on other sites More sharing options...
rloew Posted December 17, 2018 Share Posted December 17, 2018 To be sure, he would have to post the MBR of the original Hard Drive. A new Drive as well as a GPT MBR is blank. Simply partitioning a Drive without making it bootable might not initialize the MBR Code. Mine won't unless you tell it specifically to do so. Link to comment Share on other sites More sharing options...
pathwayus69 Posted December 18, 2018 Author Share Posted December 18, 2018 Ok So tired that tonight with the rig Root(fd0) Filesystem type is fat, using whole disk dd =if()/Sec_6571.bin of=bin of=(hd0)65+1 bs=512 count=1 buf_size=0x1000, loops=0x1. in_pos+0x0000000000000000, out_pos=0x000000000000000 00000000 bytes read / written x0000000000000200 / 0x0000000000000200 then after running rootnoverify (hd0) chainloader +1 boot system just sit at _ I will try to get a copy of the mbr not sure if I will get it tonight as i half to take the unit back apart. Thanks you for all the help Link to comment Share on other sites More sharing options...
jaclaz Posted December 18, 2018 Share Posted December 18, 2018 Well, no, there has been a misunderstanding. After having copied the third sector of the VBR (sector 65) that went OK., you need to test the bootsector, i.e.: root (hd0,0) chainloader +1 boot it should boot. Then you need to copy the MBR (sector 0), only after you have it copied you can test the MBR, i.e.: rootnoverify (hd0) chainloader +1 boot You don't need to try and get a copy of the MBR, I already provided it (with your partitions data) in the form of the file Sector_0.bin. Do re-read the previous post, you ran command #1 but then did the test intended after the command #2: https://msfn.org/board/topic/178018-windows-98-hard-drive-cloning/?do=findComment&comment=1157673 Quote 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) jaclaz Link to comment Share on other sites More sharing options...
Destro Posted December 26, 2018 Share Posted December 26, 2018 (edited) Many differn't ways you can do such a thing. This maybe easy or hard depending on the person. Depending on the hardware. Id never do it like this, Id simply format a new disk and sys.com it. Then literally copy all the files from one disk to the 2nd disk in offline mode, using win PE, or or something else. I have used symantec ghost for years pretty good product version 8.0 that work good too. Like you litterally just take out the old hard drive that has the data on it you want to copy. Instal the new drive. Boot the computer up with a floppy disk. Run fdisk make your partician, reboot. format the drive. The Sys the C drive. take both drives out. Hook the drive up that has all your stuff on it to a computer running windows. Unhide files and what not. Make a folder and copy the entire contents to that folder. Shut down the PC. Take your new disk that you already sys the drive and formated use the USB dongle on that. Booot the PC up copy all the files from that folder to the new drive. EZ Edited December 26, 2018 by Destro Link to comment Share on other sites More sharing options...
rloew Posted December 26, 2018 Share Posted December 26, 2018 Copying the files would not work safely with Windows 9x unless you have a tool such as my XFILE that can preserve Short File Names. Standard copying can cause the Short File name for a given file to be changed on the destination. Link to comment Share on other sites More sharing options...
Destro Posted December 26, 2018 Share Posted December 26, 2018 yup but this would work 100% on a fresh install of 98. You wouldn't have a problem copying those files from disk to disk on XP. Link to comment Share on other sites More sharing options...
jaclaz Posted December 26, 2018 Share Posted December 26, 2018 (edited) Only for the record, a number of Commercial programs, particularly of the DOS/WIN9x era, use hidden sectors or volume serials (and what not) to "validate", so if you have any of these you can only do a "clone". jaclaz Edited December 26, 2018 by jaclaz Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now