Partition repair

[jaymax]

Is there a utility to repair and restore partitions, on system disks, without destroying data?

Thanks!

[dh]

I've succesfully restored partition table couple of times by using sysutils/scan_ffs program. scan_ffs doesn't restore the partition table itself, but it gives you information (partition offset/size) that you can use with disklabel to restore the partition table.

[Beastie]

By partition, do you mean BSD partitions or BIOS partitions (BSD slices)?
If it's the latter, you can use TestDisk (http://www.cgsecurity.org/).

[jaymax]

dh - if the problem is on your system disk, /, /var, /usr, /dev/ etc inaccessible ? disk label does not provide offset info either otherwise I would rebuild as I have a dump on another disc

[jaymax]

Beastie - BSD partitions

[Beastie]

problem is on your system disk, /, /var, /usr, /dev/ etc inaccessible

I'm not sure I can really help much, but it's possible the superblock was corrupted. There are backups in every cylinder group. You could look into it.
http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg38682.html
http://www.nabble.com/Looking-for-help-to-reconstruct-a-corrupted-UFS2-filesystem-td14985445.html
BTW, you can boot from a livefs.

Do you mind me asking what happened?

[dh]

dh - if the problem is on your system disk, /, /var, /usr, /dev/ etc inaccessible ?

If your system disk is the problem, you boot from another source (live CD) and use scan_ffs and disklabel from there. Since scan_ffs is not part of base system, you'll have to put it onto USB memory stick or something.

disk label does not provide offset info either otherwise I would rebuild as I have a dump on another disc
I didn't say it did - you'll just use the disklabel program to rewrite the partition table using the information gathered with scan_ffs.

[jaymax]

Beastie: Was attempting an upgrade from 6.0=>6.4=>7.0=>7.2
At first step, 6.0=>6.2, sysinstall took me to Upgrade>>...>>Diskeditor, partition dimensions were present but no mount pt., inserted these, brought me back to diskeditor now with neither dimensions or mount point.

dh: Running scan_ffs from frenzy-1.1 livefs CD =>

is the ad0 disk mounted during the scan at /mnt? which root, one has a 63 offset the other none.

# scan_ffs /dev/ad0
ufs1 at 63 size 102400 mount / time Thur Jan 1 00:00:00 1970
ufs2 at 0 size 262144 mount / time Wed Oct 11 13:16:08 2006
ufs2 at 1048576 size 1041920 mount /var time Wed Oct 11 13:16:52 2006
ufs2 at 5216256 size 262144 mount /mnt/tmp time Wed Oct 11 13:16:49 2006
ufs2 at 6264832 size 18444608 mount /mnt/usr time Wed Oct 11 13:16:50 2006
ufs1 at 54190380 size 2880 mount /mnt time Wed Nov 26 12:29:01 2008
ufs1 at 54193268 size 2880 mount /mnt time Wed Nov 26 12:29:03 2008
ufs1 at 54196148 size 2880 mount /mnt time Wed Nov 26 12:28:58 2008
ufs1 at 54199028 size 2880 mount /mnt time Wed Nov 26 12:28:59 2008
ufs1 at 54202132 size 2880 mount /mnt time Wed Nov 26 12:29:00 2008
scan_ffs: read: Input/output error
------



# scan_ffs -l /dev/ad0
X: 204800 63 4.2BSD 1024 8192 16 # /
X: 1048576 0 4.2BSD 2048 16384 0 # /
X: 4167680 1048576 4.2BSD 2048 16384 0 # /var
X: 1048576 5216256 4.2BSD 2048 16384 0 # /mnt/tmp
X: 73778432 6264832 4.2BSD 2048 16384 0 # /mnt/usr
X: 2880 54190380 4.2BSD 512 4096 1 # /mnt
X: 2880 54193268 4.2BSD 512 4096 1 # /mnt
X: 2880 54196148 4.2BSD 512 4096 1 # /mnt
X: 2880 54199028 4.2BSD 512 4096 1 # /mnt
X: 2880 54202132 4.2BSD 512 4096 1 # /mnt
scan_ffs: read: Input/output error

/swap not read, probably ?
------


Before disk loss
# df -k
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ad0s1a 507630 123604 343416 26% /
devfs 1 1 0 100% /dev
/dev/ad0s1e 507630 14032 452988 3% /tmp
/dev/ad0s1f 35722892 25975090 6889972 79% /usr
devfs 1 1 0 100% /usr/var/named/dev


I do have some questions

[i] My /dev/ directory shows:
ad0a; ad0c; ad0d; ad0e; ad0f

ad0s1a; ad0s1e; ad0s1f not seen in directory


[ii] ufs1 vs ufs2=> don't recall explicitly installing ufs2 file system, but then again ?

[iii] Am I safe in assuming that the /mnt/tmp and the /mnt/usr are pointing to the /dev/ad0s1e & /dev/ad0s1f partitions; what about /var and there are two / partitions which seems to overlap and are using both ufs1 and ufs2 ?

Thanks

[jaymax]

Beastie:

As you mentioned testdisk when using it
On launching it shows the following:
Disk /dev/ad0
Please select Partition Table type , press ENTER when done

Choices presented were
Intel; EFI GPT; Mac; NONE; Sun; XBox; Return
{which should be used ?}

For FreeBSD 6.0 on 1386 archtecture

[Beastie]

You should choose Intel, but testdisk repairs/recreates missing/corrupted MBRs (BIOS partitions/BSD slices), so it won't fix your problem (BSD partitions).
And AFAIK, it's file recovery doesn't understand UFS.

UFS2 has replaced UFS1 as default for quite some time now. If I'm not mistaken, FreeBSD 5.x was already using UFS2.

It seems you recreated new partitions over the old ones. I might be very pessimistic, but I doubt you'll be able to restore much. You may try individual file recovery. I have never used it, but sysutils/magicrescue looks interesting.

[hedwards]

It seems you recreated new partitions over the old ones. I might be very pessimistic, but I doubt you'll be able to restore much. You may try individual file recovery. I have never used it, but sysutils/magicrescue looks interesting.

As long as the only thing that was done was a repartition the odds are quite good. A reformat may or may not work out well, depending upon what specifically was done. The chances are quite a bit better if it wasn't a full format, which I don't think FreeBSD does by default, and if the partitions do not line up with each other properly.

I've been through nuked partition records a few times and I don't think that I've ever been relegated to pulling up backups.

[jaymax]

I am about to make the plunge, re-install now and wanted to check by assumptions and actions

From scan_ffs -l /dev/ad0 (could not figure out what some of the columnar display were defining, indicted by "?"; hope my other guesses are correct)
(bytes/Blk)
(512) (1024) (2048)
End Start ? ?? ? Mnt Pt. Blocks MB MB MB
=== ===== ==== ===== === ====== ======= ==== ==== ====

X: 1048576 0 4.2BSD 2048 16384 0 # / 1048576 2048 1024 512
X: 204800 63 4.2BSD 1024 8192 16 # / 262081 511.9 255.9 128
X: 4167680 1048576 4.2BSD 2048 16384 0 # /var 3119104 6092 3046 1523
X: 1048576* 5216256* 4.2BSD 2048 16384 0 # /mnt/tmp 4167680 8140 4070 2035
X: 73778432 6264832 4.2BSD 2048 16384 0 # /mnt/usr 67513600 131862.5 65931.3 32966

--------

These were the original sizes before the problem:

df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s1a 496M 134M 323M 29% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/ad0s1e 496M 14M 442M 3% /tmp
/dev/ad0s1f 34G 25G 6.7G 79% /usr
devfs 1.0K 1.0K 0B 100% /usr/var/named/dev

The Disk is a MAXTOR 5T040H4 40G disk, from BIOS 40983MB & CHS 19618/16/255

Confusion issues ==>

* Seems as if the order of "End" and "Start" is reversed here ?

I did not have an explicit swap partition on this disk (just raw undefined space), had them on the other disks
The /var slice was actually converted through a soft link to /usr/var, seems as if the /var slice is showing up from the livefs disk rather than the expected /dev/ad0s1d, nothing appears on the mnt/ad0d mount point.

--------

Assuming the ufs2 fs with 2084 byte blocks does it seem safe to use the following:

Slice Start End Mnt Pt. Blocks MB
===== ===== ====== ====== ====== =====
ad0s1a 0 1048576 / 1048576 512
ad0s1c 1048576 4167680 <NONE> 3119104 1497 SWAP
ad0s1d 4167680 5216256 /var 1048576 512
ad0s1e 5216256 6264832 /tmp 1048576 512
ad0s1f 6264832 73778432 /usr 67513600 32966

(I'll put in a swap partition here now)
----------------------------------------------------
Now the following are mountable from the livefs at mnt:

Slice
=====
ad0s1a "Operation not permitted"
ad0s1c "Operation not permitted"
ad0s1d Mounted OK !
ad0s1e Mounted OK !
ad0s1f Mounted OK !

Am I safe in assuming then that ad0s1a is damaged beyond repair or will be damaged in this procedure and will have to be restored from dump or tar after the GEOMETRY is reset, although /dev/ad0s1a is present
ad0s1c is probably raw swap or just empty
and that the other slices will suffer a similar faith as this will involve reformating of the discs

Thanks for all the help, much appreciated!