On Thu, 2002-05-02 at 22:40, John Brown wrote:
> My RH 7.1 install fails at boot.
> What's a "super block"? How do you fix it with fsck? Can you?
> John
The Superblock contains the size, shape, version, and state of the
filesystem. Things like block size, first inode, blocks per group, free
blocks, free inodes, mount count, maximum mount count, last time
mounted, last time written to, and flags that show the state of the
filesystem (ie, clean unmount) are stored on the superblock.
When you create an ext2 filesystem many "alternate superblocks" are
stored as backups in case the primary superblock is lost, overwritten,
corrupt, or otherwise unusable. Usually, only the main Superblock in
block group 0 is read when you mount an ext2 filesystem.
For example, everyone can try this one without hurting anything to see
these superblocks being written:
$ dd if=/dev/zero of=foo.img bs=1M count=500
$ mke2fs foo.img
mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
foo.img is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
128016 inodes, 512000 blocks
25600 blocks (5.00%) reserved for the super user
First data block=1
63 block groups
8192 blocks per group, 8192 fragments per group
2032 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Those comma separated numbers are the alternate superblocks.
To repair a Unix filesystem, you use "fsck" (FileSystem ChecK). Each
type of filesystem (ext2, reiserfs, xfs, etc) have their own independant
runtimes that check that specific type of filesystem (fsck itself is not
all-knowing). As fsck calls these executables after it identifies what
type of filesystem it is (either via /etc/fstab, by the "-t" command
line option, or by checking the magic identifier stored in the
filesystem), there is a naming convention: "fsck.{filesystem type}", ie:
"fsck.ext2", "fsck.xfs", etc. You will find these in /sbin/fsck*
If the primary superblock is lost, fsck.ext2 (aka e2fsck) should be able
to read one of the backup superblocks to restore the filesystem.
To try this, do:
# losetup /dev/loop0 foo.img
# dd if=/dev/zero of=/dev/loop0 size=1024 count=2
# mount -t ext2 /dev/loop0 /mnt
mount: wrong fs type, bad option, bad superblock on
/dev/loop0,or too many mounted file systems
oops! :) This is the error you are seeing. Now we will fix it:
# fsck.ext2 -f -y /dev/loop0
Parallelizing fsck version 1.18 (11-Nov-1999)
e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
Couldn't find ext2 superblock, trying backup blocks...
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop0: ***** FILE SYSTEM WAS MODIFIED *****
/dev/loop0: 11/128016 files (0.0% non-contiguous),
16169/512000 blocks
Note the "Couldn't find ext2 superblock, trying backup blocks".
If fsck.ext2 can't automagically find the backup blocks, you can
implicitly tell it to use an alternate backup block:
# fsck -b 8193 -f -y /dev/loop0
You can find "ESL" (Ext2 Superblock Locator) on the 'net as well, should
you not know what alternative superblock backups were used by your
filesystem (it looks for the ext2 superblock magic on every block on a
selected partition).
Hope this helps.
- Ian C. Blenke <ian@blenke.com> <icblenke@nks.net>
http://ian.blenke.com
PS. fsck.ext2 needs a block device to check, thus the need for losetup
of /dev/loop0.. you can't "fsck foo.img", which is rather irritating.
I'd much rather use "mount -o loop foo.img /mnt"
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:38:42 EDT