"Linux Gazette...making Linux just a little more fun!"

The Answer Guy

By James T. Dennis,
Starshine Technical Services, http://www.starshine.org/

Bad Super-block on Filesystem

From Mike Klicpera on 20 Aug 1998

I am trying to correct a corrupted super-block on my Linux (Redhat ver. 4.2) system. When using the command "e2fsck -av /dev/hda2" the resulting message is that "a bad magic number in super-block" When using the command "e2fsck -b 8193 /dev/hda2" the resulting message is "attempt to read block from filesystem resulted in short read while trying to open /dev/hda2". In neither case did the program e2fsck correct the super-block. Could you provide any advice or point me in the right direction?

I'd start by looking at the partition table.

Use fdisk -l [the letter ell, not the number one -- Heather] to list all the partitions that your Linux system can see. Make sure that the /dev/hda2 really is supposed to be a Linux native partition (that you haven't swap devices and the partition has moved to /dev/hdb2 --- and that it isn't a swap partition or whatever).

It's also possible that you've switched from some autotranslation mode to linear (LBA) or otherwise changed how the system addresses this drive. Normally this shouldn't affect Linux --- but I don't know what sort of situation you have.

The "short read" error causes me to suspect that the partition table is wrong or that you're pointing fsck to the wrong device/slice. That's the error I get if I run debugfs on a directory or file rather than the proper /dev/ node. It's also possible to get this if you've got a partition that's listed as Linux native that has no filesystem yet made on it or when you try the e2fsck -b on an MS-DOS filesystem.

You can try a number of other superblocks (they should be scattered every 8K clusters)

In a particularly bad case you can try mke2fs -S (make superblocks and group descriptors only). This is described in the man page --- and is for "last ditch" efforts only.

If you have a tape drive or a suitably large extra disk drive you can make an "image" backup of this device before you try any other (more radical) attempts at data recovery. You'd just use a command like:

dd if=/dev/hda2 of=/dev/nst0

... or better:

dd if=/dev/hda | buffer /dev/st0

... to backup the entire drive through the "buffer" program to stream all of the data out to your SCSI tape drive.

You can write the image to another block device, such as hdc3 using a command like:

dd if=/dev/hda of=/dev/hdc3

(assuming you have a large enough blank partition on the extra or loaner drive).

You can even send the data to another system with a command like:

dd if=/dev/hda | rsh $othersystem dd of=/dev/hdc3

(or whatever).

The advantage of any of these techniques is that it allows you to experiment with various recovery techniques with less chance of "making it worse" (any time you think you've "made it worse" you use the reverse commands to "start over").

There are a number of hex editors for Linux, some with nice ncurses interfaces. These can allow you to explore a filesystem trying to find out where things are. I haven't played with any of these enough to be any good with them --- and I've never read through the sources to find out where the interesting data structures should be, or what they should look like.

Eventually I'd like to see the Linux programming community produce a set of fs recovery tools to rival the Norton Utilities for DOS (for which I used to be a professional support rep). The first such tool would be one that could scan a raw device, find superblocks and report the information from them.

Thanks in advance for any help.

I hope it helps.

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 32 September 1998

	phreak	abandon	javaterm	BBS	flaws	doslinux	resume
	softwindows	convert	apache	emulate	database	distrib	proxy
	disable	DVI	superblock	serial	permission	detach	cdr
rs422	modem	notfound	tuning	libc5	startup	clock	ping
accounts	lilo	NDS	95slow	nonlinux	progenv	cluster	ftpd