Changes between Version 7 and Version 8 of BadBlockHowto

Timestamp:

Mar 25, 2017, 2:41:13 PM (8 years ago)

Author:

Gabriele Pohl

Comment:

Partition table problems

BadBlockHowto

@@ -461 +461 @@
 This section first looks at a damaged partition table. Then it ignores the upper level impact of a bad block and just repairs the underlying sector so that defective sector will not cause problems in the future.
 
+=== Partition table problems ===
+
+Some software failures can lead to zeroes or random data being written on the first block of a disk. For disks that use a DOS-based partitioning scheme this will overwrite the partition table which is found at the end of the first block. This is a single point of failure so after the damage tools like `fdisk` have no alternate data to use so they report no partitions or a damaged partition table.
+
+One utility that may help is `testdisk` [#footnote6 [6]] which can scan a disk looking for partitions and recreate a partition table if requested. 
+
+Programs that create DOS partitions often place the first partition at logical block address `63`. In Linux a loop back mount can be attempted at the appropriate offset of a disk with a damaged partition table. This approach may involve placing the disk with the damaged partition table in a working computer or perhaps an external USB enclosure. Assuming the disk with the damaged partition is `/dev/hdb`. Then the following read-only loop back mount could be tried:
+
+{{{
+# mount -r /dev/hdb -o loop,offset=32256 /mnt
+}}}
+
+The offset is in bytes so the number given is `(63 * 512)`. If the file system cannot be identified then a `-t <fs_type>` may be needed (although this is not a good sign). If this mount is successful, a backup procedure is advised.
+
+Only the primary DOS partitions are recorded in the first block of a disk. The extended DOS partition table is placed elsewhere on a disk. Again there is only one copy of it so it represents another single point of failure. All DOS partition information can be read in a form that can be used to recreate the tables with the `sfdisk` command. Obviously this needs to be done beforehand and the file put on other media. Here is how to fetch the partition table information:
+
+{{{
+# sfdisk -dx /dev/hda > my_disk_partition_info.txt
+}}}
+
+Then `my_disk_partition_info.txt` should be placed on other media. If disaster strikes, then the disk with the damaged partition table(s) can be placed in a working system, let us say the damaged disk is now at `/dev/hdc`, and the following command restores the partition table(s):
+
+{{{
+# sfdisk -x -O part_block_prior.img /dev/hdc < my_disk_partition_info.txt
+}}}
+
+Since the above command is potentially destructive it takes a copy of the block(s) holding the partition table(s) and puts it in part_block_prior.img prior to any changes. Then it changes the partition tables as indicated by `my_disk_partition_info.txt`. For what it is worth the author did test this on his system! [#footnote7 [7]]
+
+For creating, destroying, resizing, checking and copying partitions, and the file systems on them, GNU's `parted` is worth examining. The [http://www.tldp.org/HOWTO/Large-Disk-HOWTO.html Large Disk HOWTO] is also a useful resource. 
 
 == Footnotes ==
@@ -472 +501 @@
 [=#footnote4 [4]] Important: set blocksize range is arbitrary, but do not only test a single block, as bad blocks are often social. Not too large as this test probably has not 0% risk.
 
-[=#footnote5 [5]] The rather awkward `expr 484335 + 100` (note the back quotes) can be replaced with `$((484335+100))` if the `bash` shell is being used. Similarly the last argument can become `$((484335-100))`. 
+[=#footnote5 [5]] The rather awkward `expr 484335 + 100` (note the back quotes) can be replaced with `$((484335+100))` if the `bash` shell is being used. Similarly the last argument can become `$((484335-100))`.
+
+[=#footnote6 [6]] `testdisk` scans the media for the beginning of file systems that it recognizes. It can be tricked by data that looks like the beginning of a file system or an old file system from a previous partitioning of the media (disk). So care should be taken. Note that file systems should not overlap apart from the fact that extended partitions lie wholly within a extended partition table allocation. Also if the root partition of a Linux/Unix installation can be found then the `/etc/fstab` file is a useful resource for finding the partition numbers of other partitions.
+
+[=#footnote7 [7]] Thanks to Manfred Schwarb for the information about storing partition table(s) beforehand.