summaryrefslogtreecommitdiffstats
path: root/rescuept/README
diff options
context:
space:
mode:
Diffstat (limited to 'rescuept/README')
-rw-r--r--rescuept/README107
1 files changed, 0 insertions, 107 deletions
diff --git a/rescuept/README b/rescuept/README
deleted file mode 100644
index 9009bff59..000000000
--- a/rescuept/README
+++ /dev/null
@@ -1,107 +0,0 @@
-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 !!!!
------