1

Situation: we have an old, unused laptop that we want to give to my father and mother in law but Windows kept complaining that the hard drive will fail soon, it should be changed. But unfortunately I don't have that Windows 7 product key anymore. Probably was an OEM but the sticker has been peeled off.

What I tried: I have a spare 500 GB Toshiba drive and the faulty one in it is also a 500 GB WD. So I pulled up an Ubuntu from an USB drive, put my spare drive into another USB HDD case and started to dd.

I didn't really think it through, so I started to copy the physical drive, /dev/sdb to /dev/sdc. It took like 24 hours to copy but I thought it was because the old drive had a couple of bad sectors.

Since then my spare drive seems even more dead than the original with Windows on it. It won't boot, not readable, fdisk can't manage it. I'm beginning to think that it was a fatal mistake to replace the first sector with the MBR and the partition table because it may have contained information on the physical architecture of the disk.

  1. Is this assumption correct?

I tried to find some way to recover the disk, followed some step-by-step instructions that told me to dd some data to the disk. Whenever it was some bigger amount, it always failed with input/output error. However when I just tried to fix the MBR, it worked and didn't produce any error.

  1. Do you think that the problem can be fixed somehow? If I'm correct, rewriting the MBR is just copying 440 bytes, not 512. In the remaining 72 there's the MBR and - I just suspect it, sorry if I'm wrong - some info about the disk.

Now fdisk states this about my now dead spare drive:

255 heads, 63 sectors/track, 60801 cylinders, total 976773120 sectors

  1. How can I make sure that this is valid for my Toshiba HDD and not something copied from the dying WD?

  2. The good solution would have been to partition the drive beforehand and use dd separately for each partition that I want to save?

EDIT: fdisk on Ubuntu seems fully functional, I can view, edit and save the partitions, but the disk is still not working. I'm more and more suspicious that it's the disk geometry that's not matching somehow.

Improve this question
4
  • What was the exact dd command you used? It should not have taken 24 hours. Commented Nov 1, 2017 at 21:59
  • dd if=/dev/sdb of=/dev/sdc conv=noerror,sync Commented Nov 1, 2017 at 22:41
  • 1
    You should have specified a large block size (bs=XXXX) . That would have significantly reduced the time taken. Commented Nov 2, 2017 at 0:12
  • 1
    Try testdisk utility Commented Nov 2, 2017 at 5:35

2 Answers 2

Reset to default
3

Question 1: Your assumption is wrong. An MBR does not contain "information on the physical architecture of the disk."

Question 2: Use fdisk, parted or any other disk partition utility. Check the results against the specifications for the disk.

Question 3: No, it is best to copy the entire disk image from the old disk to "new" disk.

Improve this answer
5
  • I would argue that for #3 the best solution is is to use a native OS copy, or archive tool. Depending on how the disk is bad you'll get errors on individual files (which might be a pain depending on the size of those files). but you'll also get some level of ability to verify the files. With dd you have a duplicate disk but no idea what copied successfully. Commented Nov 1, 2017 at 23:36
  • @Petro. Native OS or archive tools work at the filesystem level. For copying an OS disk, you typically use tools that work primarily at the block level , i.e. under the filesystem level. Commented Nov 2, 2017 at 0:08
  • I'm not sure why are you saying this. The MBR wikipedia article states that the partition table entires hold information on heads (8 bits), cylinders (10 bits) and sectors (6 bits). (Which are fake, of course, but still, OS on low BIOS level will handle the disk according to those.) en.wikipedia.org/wiki/Master_boot_record Commented Nov 2, 2017 at 8:07
  • 1
    @LastTen. CHS information relates to start and end of MBR partitions and not the physical architecture of a disk as a whole. If what you say is true, how would an OS discover the size of a disk if the disk has no partitions? Commented Nov 2, 2017 at 12:48
  • Makes sense, thanks. I was just thinking that this fake CHS information is somehow used later when the disk is handled on low level. Commented Nov 4, 2017 at 23:06
1

(976773120 * 512 byte sector) / 1000b / 1000kb / 1000mb = 500.10783744 GBs. However the number of sectors comes from ATA not the data on the disk.

It's quite often that HDDs do not have the same number of sectors even for the same nominal GBs this might explain some of your errors.

An MBR is 512 bytes, if you stopped at 440 nothing is going to work. It's likely you got this number (really its 446) from guides about how to copy bootloaders without touching partition data. You copied everything but the partitions actually.

The copy would no doubt take a very long time using a small block size over 500GBs. However I strongly recommend against using dd here.

To do this you should use fdisk and partclone like this:

It might be the partitions are already cloned just not seen because you borked the partition table. ( i can't tell what happened based on your question alone.) It's also possible you have a GPT disk as well. In either case first try this.

First of all use /dev/disk/by-id/ in the future. But I am assuming you're going FROM /dev/sdb TO /dev/sdc

  • fdisk /dev/sdb
  • press P
  • note the partitioning style: MBR or GPT. If GPT STOP and change your question noting that you have a GPT disk.
  • also note the number of bytes.
  • press V and check for errors before copying
  • press Q
  • fdisk /dev/sdb
  • press P
  • note bytes. If there isn't more or the same number of bytes you'll have problems unless you shrink something.
  • press Q

Now copy MBR:

dd if=/dev/sdb of=/dev/sdc bs=512 count=1

This copies one block of 512 bytes from sdb to sdc.

then do

partprobe

Now try mounting your partitions. If they don't work at this point go ahead and copy them over again with partclone. Here is an example where its assumed windows is on /dev/sdb1 going to /dev/sdc1

  • partclone.ntfs -b /dev/sdb1 /dev/sdc1
Improve this answer
4
  • Regarding the original WD drive it says that partitioning is MBR. Bytes: 500,107,837,440. Number of sectors: 976,773,120. Geometry: 255 h / 63 s / 60801 c. Everything is the same, except the manufacturer. Commented Nov 2, 2017 at 8:27
  • So now that I followed your advice and checked the old drive with fdisk, I started to re-create the partitions manually on the new one. Went fine. The 2nd partition, former system, 109 GB, and the 3rd partition, former data were created and could even be formatted! The 1st one however, a mere 105 MB one (what? I didn't create that for sure and it was even bootable!) cannot be formatted on the new drive. But this one never complained about bad sectors, really! Commented Nov 2, 2017 at 9:08
  • Maaany years ago I had some Linux on this laptop together with Windows. Maybe this 105 MB is the remains of grub? That's why it is marked as bootable? Commented Nov 2, 2017 at 9:11
  • The first is most likely either an extended partition table (dynamic disk for MBR) or its reserved space for a bootloader. Commented Nov 2, 2017 at 18:16

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.