File system check failed

[interior.ocean]

My system from and after that at startup as it was doing a file system check I got this:

Checking file systems ... fsck 1.41.3 (12-Oct-2008)
/dev/sda1: clean, 30/124496 files 34735/248976 blocks
/dev/hda1 contains a file system with errors, check forced.
/dev hda1:
Inode 16728084 has illegal block(s).

/dev/hda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
fsck died with exit status 4
failed (code4).
File system check failed. A log is being saved in var/log/fsck/checkfs if that location is writable. Please repair the file system manually. failed!
A maintenance shell will now be started. CONTROL-D will terminate this shell and resume system boot. (warning)
Give root password for maintenance
(or type Control-D to continue):

I have no idea (once again) what I should do about this. I went on battery power to skip the check so I could come look for a solution, but not sure if that was a wise thing to do. /var/log/fsck/checkfs doesn't tell anything new.

[Hallvor]

Did you try running fsck manually?

[interior.ocean]

I have no idea how to do that. Other than fixing the problem, I'd like to know what caused it so I can prevent it from happening again.

[Hallvor]

The easiest is to run a file system check from a livecd, for instance (as root):

Code: Select all

umount -a
e2fsck -y -f -v /dev/hda1

[michapma]

I have no idea how to do that.

C'mon, you can do better than than. If you've no idea, then the best thing to do is inform yourself.

By the way, continuing to use the system when a filesystem check is needed is a bad idea, since it could mess up any bogus data structures even worse. Would be best to use a different computer to research the problem.
http://linux.about.com/od/lsa_guide/a/gdelsa35t08.htm

Other than fixing the problem, I'd like to know what caused it so I can prevent it from happening again.

You probably can't know for sure, but the classic example is due to the filesystem not being shutdown properly, as in power interrupt or a hard reset.
http://adminschoice.com/repairing-unix-file-system-fsck

[interior.ocean]

The easiest is to run a file system check from a livecd, for instance (as root):

Code: Select all

umount -a
e2fsck -y -f -v /dev/hda1

I don't have a cd drive. Can't I do it some other way?

Also, I don't have an access to another computer and I need to use computer for school stuff, so can't use this one. My system has frozen lots of times without giving any error messages (sound freezes on a loop and none of the controls work and screen is frozen too), and sometimes there's a kernel failure. I've asked about these problems a few times (not sure if on these forums) and search the internet for a solution but without results as I have no idea what happened and why, and people haven't been able to help either.

[michapma]

The easiest is to run a file system check from a livecd, for instance (as root):

Code: Select all

umount -a
e2fsck -y -f -v /dev/hda1

I don't have a cd drive. Can't I do it some other way?

Also, I don't have an access to another computer and I need to use computer for school stuff, so can't use this one. My system has frozen lots of times without giving any error messages (sound freezes on a loop and none of the controls work and screen is frozen too), and sometimes there's a kernel failure. I've asked about these problems a few times (not sure if on these forums) and search the internet for a solution but without results as I have no idea what happened and why, and people haven't been able to help either.

This implies that you're using the computer with a messed-up filesystem, which as has been pointed out risks further screwing it up.
A live CD was suggested because fsck shouldn't be run on a mounted filesystem. But no, you don't need a live CD, you can run fsck manually from the maintenance shell. (Running fsck manually means without the -p or -a options, see the man page.) What happened is that fsck was checking the filesystem of /dev/hda1 when it detected a problem bad enough that it couldn't fix it itself. This is a serious problem and so instead of continuing it showed warning messages and dropped you to a maintenance shell. In maintenance mode, the root filesystem is mounted, but in read-only mode—it's an acceptable exception to not running fsck on a mounted filesystem. Read this.

So here's what you can do:

1. Stop using the damaged filesystem! This means don't use it to research a solution on the net. Use a friend's computer, a library computer, or whatever is available. Print out or write down everything you'll need to remember.
2. The problem has probably persisted, the automatic fsck should still fail, and the system should drop into maintenance mode. Enter the root password.
3. If the system has not dropped into maintenance mode, you should run the fsck manually anyway. To do this, boot in single-user mode. There should be an option in the grub menu. (The following assumes grub-pc from squeeze; it's similar in grub-legacy.) If not, you can edit the existing menu entry by pressing "e." Edit the end of the line with "linux /boot/vmlinuz-2.6.32-blah root=UUID=[some-number-string]" to have the options ro and single at the end, with no other options. Press ctrl-x to boot when the editing is done. (Your edit will only be used once and will be discarded afterward.)
4. Now you're in a read-only shell with root access. If the filesystem type is ext2 or ext3, you can use the command e2fsck. Check out at least the description of its man page with "man e2fsck". Here's the command Hallvor gave you for reference:

   Code: Select all

   e2fsck -y -f -v /dev/hda1

   Note you don't need to unmount with umount -a. The -y option means answer yes to all questions automatically; the -f option forces checking even if everything looks clean; -v means verbose, so it will tell you everything that goes on. If you'd like, omit the -y option and answer each question fsck poses.
5. If you're fortunate, fsck will be able to fix the problems and will notify you that all is okay. If that happens, you can exit maintenance or single-user with ctrl-d or by entering "exit", go on your way rejoicing and report your success here for the benefit of our egos and of course future solution-seekers.
6. If fsck is unable to fix problems, it's bad. Carefully note its messages and if possible extract the log files from /var/log/fsck/ and post here accordingly.

Here's a reminder from a link previously posted, also available here:

If fsck finds unrepairable problems, you need either in-depth knowledge of how filesystems work in general, and the type of the corrupt filesystem in particular, or good backups.

If fsck fixes the problems and this is an isolated incidence, don't worry. If you start to see lots of checks going on, it could be a sign that your drive is reaching the end of its useful life. Either way, backup the valuable data from your drive. I use an external USB drive.

Resources for you to print for reference:
http://www.debianhelp.co.uk/fsck.htm
http://linux.die.net/man/8/e2fsck

is that what you wanted?