Partition repair

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.
 
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 said:
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.
 
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.

Code:
# 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
------



Code:
# 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
Code:
# 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

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

As you mentioned testdisk when using it
On launching it shows the following:
Code:
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
 
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.
 
Beastie said:
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.
 
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)
Code:
(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:

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

Code:
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
=====
Code:
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!
 
Back
Top