Dear All,
Here I am sending the error msg that come to to the terminal when I attempt to start my
linux redhat 2.4.18-3 system.


cheking file system
/boot clean
/home : clean
/usr :containing file system with errors,check forced
error reading block 35924(attempt to read blocks from filesystem resulted in short read)
usr/ UNEXPECTED INCONSISTENCY;run fsck MANUALLY.
(i.e. without -a or -p option)]

an error occurred during the file system check
dropping you to system shell.the system will reboot when you leave the
shell.
give root password for maintinace
(or type control d for normal startup)


I tried several options but the problm is that I don't have a boot diskette,
so I cant unmount the usr directory during the pocess.fsck can damage file sys heavily when running in a mounted fs.An option possibly -A(not -a) -R -V(can't remember exactly)tells on invoking that it recquire a terminal to run.i started the bash shell but it is not working in that also.I dont know the name of the device as recquired by command.To force bad block check i don't know the file of bad blocks -c option -l option.File sys is ext3.I am using fsck 1.27.

Please help me to solve the problem.

I'm not following all of this, but here are a few comments. Are you sure that /usr is mounted? Are you sure that you don't know the device name? It's not easy to find out that a file system is mounted without also obtaining the device name. For example, with the "df" command, the device name is the first field. You can just examine /etc/fstab to get the device name. But you should not actually need the device name. Modern versions of fsck will look it up in /etc/fstab. So simply:
fsck /usr
really should work.

Ideally you should find some way to umount /usr or arrange that it was never mounted prior to fsck. A boot cd (can linux really boot from a diskette?) would be a good option. You're right that running fsck on a mounted filesystem is very dangerous. This is because some of the data from that filesystem is sitting in buffer cache. When this cache is written out, it will intermix with the data written by fsck and scramble the filesystem. So you need to do the following sequence of commands:
sync
<wait 10 seconds or so>
fsck /usr
reboot -n

The first sync will flush out any changed data in / or any other mounted filesystems. You need to wait until the disk writes complete. Then run fsck.
Then immediately reboot without syncing. Also during this entire procedure, almost nothing else must be happening. It is relatively safe in single user mode. This is not completely safe, but your system is not usuable anyway, so it is what I would try. There is a risk of damaging other mounted filesystems. The first sync together with minimizing activity should mitigate this danger. If you decide to try it, please post back and let us know how it works.

However, even if this does work, you may not be home free. fsck may not be able to repair your disk. "attempt to read blocks from filesystem resulted in short read" make me think that your disk may be bad in a hardware sense. fsck cannot repair broken hardware.

Whether or not fsck seems to work, you must immediately do the "reboot -n". Good luck.

Dear All
Yesterday I posted a querry related to file systen inconsistency and as Mr perderabo suggested I used "fsck /usr" command and it worked.
The problem of short read can't be solved and resulted in some bad sectors in disk.
Thanks to Unix.com and Mr perderabo.

Yes! it's reale worked!