Red Hat Linux Troubleshooting – File system Errors


Troubleshoot  Linux filesystem Issues

This post will help you resolve the Linux file system issue that causing below errors.

Devices not found when trying to boot the system

Checking filesystems
fsck.ext3: No such file or directory while trying to open /dev/devicename [FAILED]

Superblock of file-system not found

The superblock could not be read or does not describe a correct ext2 filesystem.
If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else),
then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: 

e2fsck -b 8193 <device>

Attempt to boot the system and it failed with the error:

*** An error occurred during the file system check
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance (or type Control-D to continue):

Not all filesystems can be mounted by mount -a command

# mount -a  
mount: wrong fs type, bad option, bad superblock on /dev/devicename

The above error generally happens with any of following reasons :
At boot time the system runs a file-system check against all device in fstab with an fs_passno value higher than 0.
If the fsck exit code returns a value greater than 1 the server will drop to a maintenance shell so repairs can be made
The exit code returned by fsck is the sum of the following conditions:

0    - No errors
1    - File system errors corrected
2    - System should be rebooted
4    - File system errors left uncorrected
8    - Operational error
16   - Usage or syntax error
32   - Fsck canceled by user request
128  - Shared library error

Steps to resolve the above file system Issue:

 

1. Identify which device is having problems from the error message on the screen

Checking filesystems
fsck.ext3: No such file or directory while trying to open /dev/devicename         [FAILED]

2. Drop to the maintenance shell by entering your root password

3. Remount the root filesystem read/write

# mount -o remount,rw /

4. Check to verify the device exists on the system

# ls -l /dev/devicename

5. Open the /etc/fstab file for editing

# vi /etc/fstab

6. Check for any typos in the file and correct them

7. If the device no longer exists remove it from the fstab or comment out the entry by adding # to the beginning of the line

# /dev/devicename    /home    ext3    defaults    1 2

8. Save the fstab file

9. If the initial error reports corruption or missing superblock, verify it is unmounted and run a filesystem check.

# umount /dev/ devicename
# fsck /dev/devicename

10. If all else fails, modify the /etc/fstab file and adjust the fs_passno value (sixth field) to 0. This will bypass the check

# /dev/devicename    /home    ext3    defaults    1 0

11. Reboot the system

# reboot

 

 

 

Ramdev

Ramdev

I have started unixadminschool.com ( aka gurkulindia.com) in 2009 as my own personal reference blog, and later sometime i have realized that my leanings might be helpful for other unixadmins if I manage my knowledge-base in more user friendly format. And the result is today's' unixadminschool.com. You can connect me at - https://www.linkedin.com/in/unixadminschool/

3 Responses

  1. marty says:

    I tend to think multiuser, so that influences my point of view..

    With #11, I’d never mount a filesystem I didn’t know was good with its original name, unless forced to (/opt, or something like that). So I’d create another mount point and mount that problem volume with a new name, until I’d sorted things out (fixed it or tossed it, or very occasionally salvaged what we could).

    With #9, I might point out “fsck -y” to those who might not be aware of it. If the filesystem has *a lot* of problems manually may not be reasonable/possible. So “fsck”, then “fsck -y” if you have to.

    With at least one flavor of unix/filesystem combinations I’ve seen in the past, the superblock locations got recorded in a file (/etc/superblock, I think), and I got lucky using some of those other superblocks when the first didn’t work. Rare, but one does get desperate. It has been a very long time since this has come up for me.

  1. July 22, 2016

    […] Read – Red Hat Linux Troubleshooting – File system Errors […]

What is in your mind, about this post ? Leave a Reply

Close
  Our next learning article is ready, subscribe it in your email

What is your Learning Goal for Next Six Months ? Talk to us