0

I installed a new hard drive in my home server today, went to format it in gdisk (larger than 2 TB), set the changes and wrote them. Then I noticed that I had selected the wrong disk, in fact I just overwrote the partition table on my startup disk instead.

The partition table changes will be written as soon as I reboot the system, and I'm relatively certain that it won't be bootable unless I can restore the partition table to what it was before.

Is there any way I can restore the old partition table, or at least enough of it to safely reboot?

I have the 'p' output from gdisk, from before I overwrote the table:

Command (? for help): p
Disk /dev/sdh: 125045424 sectors, 59.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D0127C61-1349-42D1-A03F-46F604F3DD6C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 125045390
Partitions will be aligned on 2048-sector boundaries
Total free space is 4717 sectors (2.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       119883775   57.2 GiB    8300  Linux filesystem
   5       119885824       125044735   2.5 GiB     8200  Linux swap

Some complications:

  • The disk was formerly partitioned in MBR, and - without checking for sure - I don't think that this particular PC supports UEFI/booting from GPT.

  • I'm not sure that this printout includes all the information I would need to reconstruct the partition table. Is it possible that some partitions are hidden here? Or that other vital information would be missing? I know - for example - that because gdisk/GPT doesn't have a "bootable" flag, this printout doesn't include it.

  • I already tried writing these partitions back with fdisk, but I can't figure out how to get fdisk to create a partition numbered '5'. I imagine that, if my swap partition "moved" from sdh5 to sdh2, this wouldn't just magically work.

I found a similar issue, Recover Partition-Table still present in running system regarding overwriting the partition table using dd. But in my case, since I used gdisk (+ fdisk) to write a new table, I'm not certain that the information in /sys/block is completely accurate anymore.

0

I finally had a chance today to take a good whack at this problem, and fortunately the solution was (mostly) more straightforward than I was worried about.

What helped me along was a little more learning about how my distro (Debian) sets up disk partitions in a guided installation (http://www.linuxbsdos.com/2011/02/15/debian-6-installation-and-disk-partitioning-guide/), and about how logical partitions are created and specified on the disk (http://tldp.org/HOWTO/Partition/fdisk_partitioning.html#mixed).

After reading the notes there, and re-checking , I went back into fdisk and:

  • Rewrote the MBR (o) to start over.
  • Created (n) a primary partition '1' with the "sdh1" sectors noted from gdisk's output (2048 - 119883775).
  • Created (n) an extended partition '2' starting from the first available sector and spanning the rest of the disk (119883776 - ...).
  • Created (n) a logical partition '5' with the "sdh5" sectors noted from gdisk's output (119885824 - 125044735).
  • Changed the type (t) on partition '5' to Swap (type code '82').
  • Toggled the bootable flag (a) on "sdh1".
  • Wrote my changes (w) and exited.

I rebooted to test this partition table out, and the system didn't boot. So from here I had to unplug the disk and mount it on another PC. But luckily, all I had forgotten to do was:

  • Re-install grub to the (now-reformatted) MBR. Once the disk was mounted in my other PC, I used grub-install --root-directory=/path/to/mount/point /dev/sdX (where sdX was the device file for the mounted disk on my other PC).
    • If I had done this before rebooting the machine, I imagine it would have been grub-install --root-directory=/ /dev/sdh.

The grub configuration on the disk was still fine, so reinstalling grub itself was all that was necessary. After plugging the disk back in and starting up, everything seems to be working perfectly so far.

One important lesson I took away from this was that /sys/block data for extended partitions is a bit misleading. The /sys/block/.../size info for "sdh2" only claimed 2 blocks, which excluded the real size of the partition, necessary to fit "sdh5" (my logical/swap partition) inside it.

EDIT For good measure, the current fdisk -l output on my disk (which, after rebooting, has now labeled itself "sdi" instead of "sdh" as before) is:

Disk /dev/sdi: 64.0 GB, 64023257088 bytes
255 heads, 63 sectors/track, 7783 cylinders, total 125045424 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: <...>

   Device Boot      Start         End      Blocks   Id  System
/dev/sdi1   *        2048   119883775    59940864   83  Linux
/dev/sdi2       119883776   125045423     2580824    5  Extended
/dev/sdi5       119885824   125044735     2579456   82  Linux swap / Solaris

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.