Jump to content

Windows 98 Hard drive Cloning


pathwayus69

Recommended Posts

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) :thumbup.

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 :dubbio:.

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 :w00t:.

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 :unsure:, 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 by jaclaz
Corrected wrong commands inserting "current root" i.e. ()
Link to comment
Share on other sites


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

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 :w00t:.

 

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 :thumbup.

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. :dubbio:

jaclaz

Link to comment
Share on other sites

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

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

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 :yes:, 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

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 :yes:, 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

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 :blushing:, there is a little bug in the parsing of dd :w00t:, 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 by jaclaz
Link to comment
Share on other sites

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

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

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&amp;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

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 by Destro
Link to comment
Share on other sites

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

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 by jaclaz
Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...