Discussion Locked

/var has problems on bootup - Haaaaalp!

0 helpful
6 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Red hat 7.2 running on a Pentium 3 machine,
has an ide drive and a scsi drive, but I don't
know offhand which mount points are located
where. We had a power outage this AM that
lasted longer than our UPS could handle, so
the system came down, of course. On restart,
we get this error:
"/var contains a filesystem with errors"
It runs a checks and finds that "inode 77974
has illegal blocks".
"Unexpected inconsistency. run fsck
manually".

Then we drop into a limited shell of some sort.
Problem is that fsck can't fix /var at all - it won't
even look at it.

another weirdness: mount points will
mount/unmount at will. You can manually
mount them, and then a while later they will
disappear from the mount point listing.

Needed: suggestions for what to do next. This
is for a high school - this server provides
email/website and student directory space.
Thanks!

6 replies

by trule

Now that I've posted the above it seems
unclear. The inode error appeared the first
couple of times we ran fsck. Now all mount
points but /root have "disappeared" - they are
not automatically mounting (Most do exist and
can be manually mounted, but sometimes
even that doesn't work).

running fsck now brings up a warning
message re: "you may destroy data..."

Suggestions?

by linuxula2000

the mounts probably aren't mounting because of errors. you might boot into linux single (at the boot prompt type just that - linux single) and when you get to the prompt run e2fsck on the partitions that have the errors (more than likely it will be e2fsck /dev/hda or hda1 or so). e2fsck is better, i think, at recovering errors the fsck. of course if you're using reiser you would do reiserfsck. if you're using the red hat extension 3 file system i believe e2fsck will work on it as well.

goodluck
jack wallen

by dhaval_thakker

I think because of the errors you are not able to
mount the partitions.

Now boot into linux using "linux single".
Run the command "fsck /dev/hda#".

You may have a damaged superblock. Are you seeing any errors like that?

If you need to replace the
superblock you can do so with fsck -o -b=# where # is the new Superblock to use. You can determine what alternate superblocks are available with the command
newfs -Nv.

by trule

Turns out that with RedHat 7 you MUST specify hda# (or
whatever point you are trying to fix) rather than the name
assigned to it (i.e. home etc.). Once we found this out fsck
ran like a charm.

This discussion is closed to new replies.