Repair UFS2

Dec 16, 2013
3 min read
May 27, 2023 09:13 EEST

As a follow up to the previous thread on which I was the OP have followed the advice given, contacted Ian Dowse who kindly walked me through fixing my hard drive. Here is a synopsis as best as I can do to explain what was done:

First find out the offsets of the bad sectors, and check with dd that you can’t read them

Then write zeros over that sector

 dd if=/dev/zero seek=12345 count=1 of=/dev/ad1

and recheck that the original failing dd now works.

After fixing all the bad sectors that way, you’ll probably have much more luck with standard tools such as fsck.

%sudo fsck /dev/ad1s1a
    *  /dev/ad1s1a
Cannot find file system superblock
/dev/ad1s1a: INCOMPLETE LABEL: type 4.2BSD fsize 0, frag 0, cpg 0, size
490223412

Try editing the disklabel with `disklabel -e ad1s1’, and changing the line to look like:

  a: 490223412        0    4.2BSD        2048  16384 94088
%sudo fsck /dev/ad1s1a
    *  /dev/ad1s1a
Cannot find file system superblock

LOOK FOR ALTERNATE SUPERBLOCKS? [[yn]] y

32 is not a file system superblock
28780512 is not a file system superblock
57560992 is not a file system superblock
[[snip]]
460486688 is not a file system superblock
489267168 is not a file system superblock
SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE
-b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE
SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(8).
%

looking for superblocks in the right place. What do you get if you run the following - this is a crude way to search for superblocks:

 dd if=/dev/ad1 bs=32k | hd -v | grep "19 01 54 19"

Better still, if you can get a hex dump using dd and hd of a few kb before one of the matching lines, the parameters can be extracted from there.

> %sudo dd if=/dev/ad1 bs=32k | hd -v | grep "19 01 54 19"
> Password:
> 00008b10  00 74 27 3d 19 01 54 19  75 31 8b 04 bd 9d 34 00
|.t'=..T.u1....4.|
> 00008bd0  8b 4d 64 81 bd 5c 05 00  00 19 01 54 19 89 c6 89
|.Md..\\.....T....|
> 0001c350  00 00 00 00 00 00 00 00  00 00 00 00 19 01 54 19
|..............T.|
> 005ec350  00 00 00 00 00 00 00 00  00 00 00 00 19 01 54 19
|..............T.|
> 0b7e0350  00 00 00 00 00 00 00 00  00 00 00 00 19 01 54 19
|..............T.|

Looks good - the 3rd and later lines look like superblocks - try:

  fsck_ffs -b 160 /dev/ad1s1a

(160 is calculated by taking 0x0001c350 from the third line above,
subtracting 0x550 to get the start of the superblock, and then dividing
by 512 to get the sector number, and finally subtracting the partition
offset of 63)

I’m guessing that fsck was looking for superblocks in the wrong place because without a valid superblock it was assuming that the filesystem was UFS1 not UFS2. As far as I can tell, for UFS2 the first standard backup superblock is usually at block 160, whereas for UFS1 it’s at block 32. I guess fsck_ffs and/or the man page need to be updated to deal with that.

=======================================

In end, it worked fine and that HD is back in business. Thanks Ian, and everyone else that helped out on this one.

Marty %%

Web Installed Formmail - http://face2interface.com/formINSTal/ Webmaster’s BBS - http://bbs.face2interface.com/


freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to “freebsd-questions-unsubscribe@freebsd.org ” %%


Related Posts