Accidentally deleted the partitions on my boot disk. The system is still running. How can I recover?

Question

I just accidentally scrubbed all the partitions from the wrong disk.

/dev/sda is the boot disk, and /dev/sdb is a new disk I am trying to set up as a RAID mirror.

I accidentally fat-fingered it, and wound up deleting the partition table on /dev/sda, rather then /dev/sdb.

The system is still up and running, so it's running off a cached partition table somewhere.

Can I recover the partition table, or at least view it, so I can recreate the partitions exactly where they were?

fdisk /dev/sda -l yields no partitions.

_{^{Yeah, I feel clever}}

Solution

The kernel keeps the partition table in cache permanently (unless explicitly told to reload, and that can't be done if some of the partitions are in use). So you're safe until you reboot (or tell the kernel to operate on data that doesn't reflect the true disk contents; for example, if you've already activated mdraid, it might have written its metadata on the disk already).

If you have an up-to-date backup of your boot sector (the first 512 bytes), you can restore it (cat boot-sector-backup >/dev/sda — do check that the size of the file you're restoring is exactly 512 bytes). Your bootloader installation may have created a boot sector backup, but if it's been upgraded or you've repartitioned since then, it won't be up-to-date. Do not restore a backup that may be obsolete.

The kernel's information about the partitions is accessible through /sys/class/block/sda/sda*. In the directory for each partition (sda1, sda2, etc.):

• start contains the offset of the beginning of the partition, in 512-byte sectors.
• size contains the size of the partition, in 512-byte sectors (except for the extended partition).

If you have partitions numbered 5 or above, they are logical partitions (see What is the difference between "extended" partition and "logical" partition), contained inside an extended partition. There is a single extended partition (or none), and it is one of the partitions 1–4. The file size does not contain the size of the extended partition, so you first need to determine that; it must be large enough for all logical partitions to fit, and must not encompass any primary partitions (the other partitions numbered 1–4).

Run fdisk /dev/sda. Use u to switch the unit to sectors. Create the partitions (n) with the right offset and size (as the prompt says, put + before the number of sectors when it comes to the size), starting with the extended partition.

Use p to check that the partition table looks right. If some of these partitions are not Linux data partitions, use t to set their type (82 for Linux swap, c for a Windows FAT32 partition, 7 for a Windows NTFS partition). If you have a bootable DOS/Windows partition, set its bootable flag (a).

Double-check that the output looks good, then press w to commit the new table to disk.

Save the contents of /sys/class/block/sda/ in a tar archive on a USB stick. Then reboot from a removable media. **After rebooting, if the partition table you created is not correct, you risk massive data corruption**. So from the removable media, runfsck -n(don't forget the-n) to check the consistency of the filesystems on each partition (don't usemount`, which would only work if the offset was correct and could damage the disk (even in read-only mode, because it would write the journal) if the offset was correct but not the size).

If fsck finds no filesystem, you got the offset of a partition wrong. If it reports errors, chances are you got the size of the partition wrong. As long as you haven't written to the disk, you can still fix the partition table. When you have no partition from the disk mounted, pressing w in fdisk will make the kernel re-read the partition table. Once you have your partitions right, you should be able to reboot into your normal system and continue as usual.

Comments

[Admin]

Don't make kernel re-read partition yet (using any of the *fdisk programs). cat /proc/partitions to take a note of all the partitions. And the files /sys/block/sda/sda?/size and /sys/block/sda/sda?/start (there would be folders like /sys/block/sda/sda1 for each of your partitions)

[Admin]

@Anil - cannot force the kernel to re-read mounted partitions. In fact, even partprobe doesn't cause problems. Basically, you have to dismount the bad partition before the kernel forgets it, it seems.

[Fake Name]

I chose this as the answer (as it is the best way to actually recover the partitions), though I wound up doing something else. I stated in the OP I was working on migrating to RAID-1. I already had the /boot partitions migrated into a raid array, the the / partition was a LVM volume. I wound up just using pvmove to move the LVM volume while it was still online. Then, I just removed the accidentally damaged disk from the LVM LV, and got the system fully booting from the RAID-1 partition. GRUB is still being bizarre, and it hangs at boot until I massage the MD array manually, but it works.