1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
As far as I now know, there are four utilities that attempt to
assist in recovering a lost partition table, or a partition
that was deleted by mistake.
(i) findsuper is a small utility that finds blocks with the ext2
superblock signature, and prints out location and some info.
It is in the non-installed part of the e2progs distribution.
(ii) rescuept is a utility that recognizes ext2 superblocks,
FAT partitions, swap partitions, and extended partition tables;
it may also recognize BSD disklabels and Unixware 7 partitions.
It prints out information that is suitable as input to sfdisk
to reconstruct the partition table.
It is in the non-installed part of the util-linux distribution.
(iii) fixdisktable (http://bmrc.berkeley.edu/people/chaffee/fat32.html)
is a utility that handles ext2, FAT, NTFS, ufs, BSD disklabels
(but not yet old Linux swap partitions); it actually will rewrite
the partition table, if you give it permission.
(iv) gpart (http://home.pages.de/~michab/gpart/) is a utility
that handles ext2, FAT, Linux swap, HPFS, NTFS, FreeBSD and
Solaris/x86 disklabels, minix, reiser fs; it prints a proposed
contents for the primary partition table, and is well-documented.
The current directory contains rescuept.
I would never have written it had I known about fixdisktable
and gpart. However, now that it exists I find several situations
that are handled by rescuept and not by any of the others,
so let it be for the moment.
How do you get your partition table back?
The easy way - if you had been smart you would have done
# sfdisk -d /dev/xxx > xxx.pt
before the disaster, where xxx.pt lives on some other disk
or is printed on a piece of paper and taped to the wall. Now
# sfdisk /dev/xxx < xxx.pt
will restore the partition table.
In the absence of such good information, try each of the above
utilities to get an idea of where your partitions were.
Since gpart is the most elaborate one, it may be your best bet.
Note that if you in the course of history have deleted some partition
and created something else on the same spot, then there will often
be traces of both, and these utilities may easily retrieve outdated
information.
If you think you found a partition, make a primary partition entry
in the partition table, and try to mount the partition.
Note that some utilities count sectors the DOS way (starting with 1)
while most do it right (starting with 0).
Report successes and failures of rescuept or any of the others
to aeb@cwi.nl. (It may well be that rescuept ought to be replaced
by gpart.)
Comments:
-----
From: Nix <nix-kernel@vger.rutgers.edu>
Subject: Re: [OFFTOPIC] Searching for filesystem locator
Date: Sun, 9 May 1999 20:26:16 +0100 (BST)
> (iii) fixdisktable
I've just tried this but it appears to suffer from a 2^31-sectors problem.
> (iv) gpart
... but this proved a godsend.
-----
From: Chris L. Mason <cmason@unixzone.com>
Subject: All hail rescuept!
Date: Fri, 27 Aug 1999 22:58:24 -0400
..rescuept got me out of a real jam!
I tried fixdisktable without any luck.
-----
From: Osman <osman@Cable.EU.org>
Subject: Re: rescuept
Date: Thu, 26 Aug 1999 16:24:40 +0200 (CEST)
Ok, This is what I tried:
"./rescuept /dev/sdc > detection.txt"
"cat detection.txt | sfdisk -f /dev/sdc"
The "-f" was to force it because sfdisk didn't like the partitioning,
whoehaha...
After carefully looking at the data in "detection.txt",
I remembered that I had created the table with the "dos compatibility"
flag turned off. That gave me 31 sectors back at that time...
Well after that I mounted the ext2 partition read-only and it looked
recovered!
Wowy !!!!
-----
|
