# Deleted partition table, still in kernel memory [SOLVED]

## gregp01

I've accidentally overwritten the first 20MB or so of one of the disks on my system (/dev/hda). The disk has a 512MB swap partition as /dev/hda1, and the rest of the 40GB is an LVM partition (/dev/hda2). I haven't lost any data (and the swap wasn't in use), but as soon as I reboot I'll be screwed since I hosed the partition table.

It's my understanding that the kernel keeps the partition maps in memory somewhere - how do I get this information out so I can use fdisk to re-write the correct partition table?

I've already tried gpart ( http://www.stud.uni-hannover.de/user/76201/gpart/ ) as suggested at http://www.linuxquestions.org/questions/history/233663 .

Is there an LVM command to tell me exactly how big the LVM partition is, since it fills all the rest of the disk? Then maybe I can work backwards...

EDIT: Solved. See my last post.Last edited by gregp01 on Sun Oct 17, 2004 9:26 pm; edited 1 time in total

----------

## garlicbread

Usually there is a partition table located right at the begining of the disk in the first couple of sectors (sector - 612 bytes usually)

it will list the first 4 primary partitions located on the disk

there is info in the kernel memory but this probably would have been lost as soon as you rebooted the PC

(cat /proc/partitions has some info but not much and this is read from the disk at bootup anyway)

there are a couple of tools that can be used to read / manipulate this

fdisk and sfdisk

sfdisk -l -uS /dev/hda as an example will read off the partition table off the hard disk and display the begining / end sectors of each partition

as an example this is what mine looks like

   Device Boot    Start       End   #sectors  Id  System

/dev/hda1   *        63  58605119   58605057   c  W95 FAT32 (LBA)

/dev/hda2      58605120  59633279    1028160  83  Linux

/dev/hda3             0         -          0   0  Empty

/dev/hda4      59633280 117210239   57576960   f  W95 Ext'd (LBA)

/dev/hda5      59633343  89337464   29704122  8e  Linux LVM

/dev/hda6      89337528 115153919   25816392  83  Linux

/dev/hda7     115153983 117210239    2056257  82  Linux swap

for an extended partition this is a little more complicated, since there is a max of 4 primary partitions (old limitation)

for extended partitions one of the 4 primary partition slots is used up to siore the extended partition, the extended partition then acts as a container for more partitions to exceed the 4 partition limit

hda1 - hda4 are reserved for primary partitions under linux so I don't think you have to worry about extended partitions in your case

since you've overwritten the first 20Mb of the disk, this table is probably lost

first thing is to boot off another disk, perhaps the live CD

next run "sfdisk -l -uS /dev/hda" to see if it can see anything from the partition table

personaly I tend to use sfdisk to try and list the details of partitions

and fdisk to actually make changes (as it has a menu system that I find eay to use)

Also one thing to remember is that ther Linux version of fdisk only affects the partition table not the data

this means that if you can write back a new partition table the same as before with fdisk with exactly the same mappings then this might work

The tricky part is knowing where the partitions start and end on a sector basis if the table has already been overwritten (which is why I usually keep a backup on a floppy of the sector listings)

if nothings been found with sfdisk

run "fdisk /dev/hda"

it'll probably give a warning that no valid partition table was found if it's all been zeroed out

at this point you can type "m" for a list of commands

"w" will write back the partition table in fdisk memory which will probably be a default blank one, if nothing was found to begin with

"p" lists the current partitions for the disk

by the sounds of things if there is no partition table

then you'll need to write a new one using fdisk

specifying the first partition as 512MB in length for the original swap

and the 2nd partition as the rest of the disk for the LVM partition.

if your lucky the start end sectors will be the same as before

But if the point where the first partition ends and the 2nd one begins is out by a couple of sectors (remember 1MB = 2048 secotrs) which can happens sometimes when doing this then Linux may not be able to read the second LVM partition and you may have to fiddle about by trying different start sectors for the 2nd partition

since the end of the swap partition is probably zeros you may be able to find the beginning sector of the LVM partition by using a disk editing utility, but I wouldn't know what to advise for that

----------

## jimhend~1

u could try gpart.

ive used this before.

it was able to guess the partition table for me in a case where the first 512 bytes of the disk had been over written.

i used another tool as well , which i forget the name now , but it was similar to gpart , and arguable better.

try freshmeat.net

http://freshmeat.net/search/?q=partition&section=projects

----------

## gregp01

Some clarifications:

* I have not rebooted. Everything on the system still works fine. /dev/hda1 and /dev/hda2 still point to the proper places - the only thing I need to find out is what exact disk sectors those places are, so that I can rebuild the correct partition table manually.

* I've already tried gpart. It gave me four partitions of 0 MB as its guesses - not very useful.

garlicbread: Thanks for the /proc/partitions suggestion - it does indeed contain useful information. However, it lists values in 1K blocks, not the 512 byte blocks that hard disks use. 

(As for the rest of your post, while I greatly appreciate your thoroughness, I already knew about most of it (sfdisk, fdisk, the fact that the partition table is in sector 0). Seriously though, thanks anyway, and if you know where I can get exactly what I need, you'll be my personal hero.)

If I don't get any further suggestions, I'll try the /proc/partitions values multiplied by 2. However, since the kernel (or devfs, or something) still knows precisely where /dev/hda1 and /dev/hda2 point, it seems to me that I should be able to somehow get to that information.

----------

## garlicbread

any tool you use such as gpart or sfdisk etc will probably try to read the partition info from the disk (and will hence show 0 partitions)

I might have found something

if your using a 2.6 kernel and have sysfs mounted (similar to procfs)

within "/sys/block/hda/"

there is a number of subdirectories called "hda1" "hda2" etc on my system and within each subdirectory appears to be a "start" and "size" file that if you read as a text file appear to show the start sector and number of sectors in length of each partition

I'm not sure if it's pulling this info from memory or off the disk so you may or may not get some info from that

----------

## gregp01

Ok, so /sys/block/hda was what did it - it has sector numbers for partition sizes and start locations. By using the information from my second drive (identical to the first, but different partitons), I was able to infer that:

PartitionOneEndCylinderInFdisk = PartitionTwoStartSectorFromSysBlock / NumberOfSectorsPerCylinderFromFdisk

When multiplied by two, the information in /proc/partitions matches up with that in /sys/block .

Maybe this will help someone else, too...

Many many thanks to you, garlicbread.

Now, to back up the partition tables on all my machines...

----------

## nightfrost

This thread might be saving my life!

I have the exact same problem; I've messed up the first 10 megs (I think). I haven't rebooted yet; but have to hand this computer over soon; and knowing my other family members they will reboot it rather soon. I ask of a step-by-step solution to this problem only since I'm in such hurry... what should I do to save my precious hard drive??

------------------------------------

sorry, in my haste I didn't see garlicbreads thorough reply   :Embarassed: 

----------

## nightfrost

OK sorry for being stupid... I have all the info, still haven't rebooted. What do I tell fdisk to do to fix this problem? I can't find the correct commands. It can't be (n) add a new partition, can it?

----------

## gregp01

First off, you may be screwed anyway. When this happened to me, I got lucky - hda1 (the first partition) was swap space that wasn't in use. If you had a data partition as hda1, you almost certainly lost some data and quite possibly the superblock/allocation table (or whatever your filesystem uses). If that's the case, you'll most likely have to recover what you can and recreate the partition with the proper tool (mke2fs, mkreiserfs, or whatever).

If your first partition is swap, make sure to issue 'swapoff /dev/hda1' before going any further. If it's a data partition, though, *don't* unmount it until you've recovered as much data as you can to another partition or drive, as you may not be able to re-mount it again with the damage.

Either way, here's how I reconstructed my partition table; this assumes that the affected drive is /dev/hda, so you may have to modify the steps accordingly:

1. Get the start sectors and partition lengths from /sys/block/hda . /sys/block/hda/hda1 has those values for /dev/hda1, and so forth. You can use 'cat /sys/block/hda/hda1/size' to get the size (in sectors) for /dev/hda1 .

2. Get the number of sectors per cylinder from fdisk. Run 'fdisk /dev/hda' and issue a 'p' command (then quit - 'q'). The number you want is on the line like this:

```
Units = cylinders of 16065 * 512 = 8225280 bytes
```

My 200GB drive has cylinders with 16065 sectors each.

3. Use the formula to figure out the end cylinder for each partition:

```
PartitionOneEndCylinderInFdisk = PartitionTwoStartSectorFromSysBlock / NumberOfSectorsPerCylinderFromFdisk
```

Obviously, the start cylinder for partition n is the end cylinder for partition n-1 plus 1. Unless you did something highly unusual, the start cylinder for /dev/hda1 (the first partition) is 1.

4. Run fdisk again ('fdisk /dev/hda'). It should complain that it doesn't see a partition table, and it's creating a new one. That's fine. Now, using the 'n' command (new partition), re-create the partitions using the start and end cylinders you calculated in step 3. Make sure you're specifying the values in cylinders (i.e., not appending M, K, or anything else - I don't rember the exact syntax, so be sure to check).

5. Make sure you change the partition types to the correct values - 'Linux swap' (82) for swap, 'Linux' (83) for most data partitions (but not for Windows partitions - those are likely either NTFS (7) or FAT32 (b or c - I was never clear on what the difference was between LBA or not)).

6. Run another 'p', and make sure the values look right. Compare them against the size values from /proc/partitions ('cat /proc/partitions'). Unfortunately, you'll have to trust the formula when it comes to the start and end cylinders.

7. Write the new table to disk ('w') and quit fdisk ('q'). If your first partition was swap, remember to issue 'mkswap /dev/hda1' before rebooting to avoid errors about a missing swap signature. If your first partition was data, and you recovered everything, you should be able to mkfs like normal, then copy your data back. If you lost important files (kernel image, etc.), I really can't help you here, but other threads might be able to...

8. Reboot and pray. You might want to write down everything from /proc/partitions and /sys/block so if something goes wrong you can still use those values to try and fix it from a rescue disk...

If everything works, you should be out of the woods. If not, well, try the rescue disk, and post here again and I'll see what I can do.

One thing this whole thing taught me was to keep backup copies of the partition tables for all my disks. sfdisk ('man sfdisk') is one utility for doing this. What I usually do is get a text backup of the partition layout from sfdisk (see the man page for the right options) and also 'dd if=/dev/hda of=/some/directory/and/filename bs=512 count=1' to get a true backup of the actual partition table. Then, I collect those files for all my machines, and put copies on each of them, so I should always have at least one backup somewhere accessible.

Another thing that I did, which may or may not be practical for you, is to duplicate my boot partition (usually /boot ) on all the drives on my system. I'm running LVM on 3 identical 200GB drives, so they each have the same partition layout (1GB swap, 32MB boot, rest is LVM). Whenever I update my boot partition (new kernel or whatnot), I run a script to copy the partition to a file on disk and the other two drives. I also had GRUB (my bootloader) install itself on all 3 drives. That way, if I do something stupid (or one of the disks fails), I can still boot my system (at least in theory). The script itself is very simple, just a few dd calls:

```
#!/bin/bash

dd if=/dev/sda3 of=/root/boot.img

dd if=/dev/sda3 of=/dev/sdb3

dd if=/dev/sda3 of=/dev/sdc3
```

(My drives are SATA, which show up as SCSI drives with the new libata in the 2.6 series kernels.)

Hope this helps...

----------

## gregp01

I just realized that those reading very closely may be confused. In my most recent post I talk about a 200GB drive, while in my first post it's a 40GB drive. If anyone cares, that's just because I screwed up a machine with a 40GB drive, but my main machine has the three 200GB drives. Carry on.

----------

## nightfrost

My dear gregp01, you're about to become my all-time personal hero  :Smile: 

I just need to know one thing before I carry on: is there anything I need to think about concerning extended drives? When following the formula, I get decimals on the number of cylinders when reaching the extended partitions: This is my partition table as it should look like:

/dev/sda1 : start=            63,  size= 19534977, Id= 07

/dev/sda2 : start= 19535040,   size= 19535040, Id= 83

/dev/sda3 : start= 39070080,   size= 19535040, Id= 83

/dev/sda4 : start= 58605120,   size=        2, Id= (?)

/dev/sda5 : start= 58605183,   size=430622262, Id= 83

/dev/sda6 : start= 489227508, size=   995967, Id= 82

The first partition is a winxp partition which I don't care too much about?

Again, thank you so very very much for your help! It feels like this might work now...

----------

## nightfrost

One more thing; 

the first partition's start-file, i.e., /sys/block/sda/sda1/start says 63 and not one. Is that a problem?

----------

## nightfrost

I think it's finally fixed! Thank you soo much!

I followed your formula and set up the first three partitions with fdisk. I then rebooted and found that the newly set partitions where in order.

To solve the extended partitions bit I had to do a little gambling (if this will cause any problems, please tell me). I started cfdisk, and sort of guessed at the size of the disks I had created when I first set up the system. That seemed to do the trick. However, I'm not sure what symptoms I should expect if I entered the sizes wrong. Or would it not have worked at all were they wrong?

----------

## gregp01

As far as the start sector goes (the 63 you saw), I'm fairly certain that that's normal - it's how my machines are set up, and it seems to be the default even when you specify a starting cylinder of 1. I think that's the space reserved at the start of the drive for the partition table, the master boot record (MBR), and possibly other data.

I really don't know what symptoms to expect if you guessed wrong. I think that if you guessed too small (meaning the new partitions start at an earlier sector than they used to) you won't have a problem, while if you guessed too big you'd have filesystem errors. Since everything seems to work, I wouldn't worry about it - I don't think it will cause any problems down the road.

For future reference, if all you're running on that machine is Linux and you need only 4 partitions or less, you might as well make them all primary partitions and skip the extended partition entirely. Even if you are running Windows, it *probably* won't cause a problem - I'm pretty sure it never did for me.

Alternatively, you could try LVM (although it's most likely far too much of a hassle to switch at this point). LVM lets you combine actual partitions and drives into one or more Volume Groups (VGs) which act as a single 'drive'. VGs can then be partitioned into many Logical Volumes (LVs) which act just like regular partitions, except they have extra features like the ability to resize them while they're in use and the ability to take 'snapshots' which preserve an exact copy of the LV while still allowing changes (only the changes are written to disk, so you don't need double the space). You can read all about it here ( http://www.tldp.org/HOWTO/LVM-HOWTO/index.html ) if you're interesed.

----------

## nightfrost

thanks a lot (really a lot!) for the tips and all your help. I've been using the computer constantly the last 48 hours and everything seems to work... (well, I  have a bunch of other problems; but they're most definitely not due to partition table.)

----------

## gregp01

Hey, no problem - that's what this whole thing is about, anyway.  :Smile:  Someone else saved my butt, and I'm more than happy to pass the favor along.

----------

