Take the 2-minute tour ×

Hy, I accidentially overwrote the first 1M of my harddisk on linux (using dd). So, the partition-table is gone. I can still access all partition (except the first one) using /dev/sda2 (and so on), so the data is still there. I only need the partition boundaries to restore the table. How can I do this? The Linux-Kernel must still know them because all mount-points still work. fdisk -l /dev/sda doesn't work because it acctualy reads the partition table.


share|improve this question
what filesystems are you using...sometimes you can find the start and end of partitions based on filesystem markers...just a thought –  hbdgaf Dec 1 '10 at 20:38

3 Answers 3

up vote 3 down vote accepted

The extents of the partitions can be read from /sys/block/sda/sda1/start, /sys/block/sda/sda1/size and so on. The values are in sectors. Write down these values before doing anything else, especially rebooting.

Once you have the values, you can recreate the partitions with fdisk. Use the u command to switch the unit to sectors, then create the partitions by entering

  • n
  • primary/logical/extended
  • partition number (except for logical partitions: do them in order)
  • initial sector
  • + size in sectors
share|improve this answer
I found those sys-files and wrote the values down, but how do I recreate the partitions using fdisk? What do you mean by expert menu? Thanks! –  theomega Dec 2 '10 at 13:32
@theomega: I meant the x “extra functionality (experts only)” menu, but in fact it's not needed, you just need to use the u command to switch to sectors. –  Gilles Dec 2 '10 at 19:23

Almost two years have passed since the question was asked. We were in exactly the same situation yesterday: We have a Linux Software RAID Level 1 with 2 disks. One of the disks broke down and had to be replaced. We had the disk exchanged and then wanted to copy the partition table from the remaining (working) disk to the new disk. Unfortunately, we copied the empty partition table from the new disk to the old disk. Luckily, we immediately discovered this before rebooting the machine, so the correct partition table was still active in the kernel. Here is what we did to resolve the issue:

  • We extracted partition data from the /sys/block/ file system as described in Gilles` answer.
  • Our system uses a GUID partition table, so we couldn't use fdisk but had to use gdisk instead.
  • gdisk works pretty much the same as fdisk except there is no need to specify u for sectors.
  • We created partitions with the exact data as extracted from /sys/block/. There are other answers to similar questions that say to decrease the partition size by one, but that was not neccessary for us.
  • With a guid partition table there is no longer a distinction between primary and extended partitions.
  • The sys/block file system contains no information about file system types, so we extracted them with mount.
  • With a guid partition table, there is no longer a bootable flag. If the partition table to restore is from a bootable disk, there must be a partition with type BIOS boot partition (usually the first partition).

After writing the partition table with gdisk, we were able to reboot the system and everything was running just fine.

share|improve this answer

Personally, I would use testdisk running from the Trinity Rescue Kit CD. It's well documented. I don't know how to recover the overwritten area of that first partition, though.

Trinity Rescue Kit CD

testdisk wiki and download

share|improve this answer

Your Answer


