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.

[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

[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:

[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

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. Someone else saved my butt, and I'm more than happy to pass the favor along.