4

When I boot my machine either in normal mode or runlevel 1 it throws following error and I'm unable to boot the machine:

 checking filesystems  
/dev/MyGroup/LogVol00: UNEXPECTED INCONSISTENCY; RUN fsck MANNUALLY  
       (i.e., without -a or -p options)  

\*** An error occured 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):

I enter the password and run fsck and e2fsck, but both gives the same error format as shown below:

(Repair filesystem) 1 # fsck
fsck 1.39 (29-May-2006)

OR

(Repair filesystem) 1 # e2fsck -y /dev/MyGroup/LogVol00
e2fsck 1.39 (29-May-2006)
/dev/MyGroup/LogVol001: clean, 141289/1402144 files, 804207/1400832 blocks
e2fsck 1.39 (29-May-2006)
The filesystem size of the device is 131072 blocks
Either the superblock or the partition table is likely to be corrupt!

Now I decide to use alternate superblock as follows:

(Repair filesystem) 6 #dumpe2fs /dev/MyGroup/LogVol00 | grep -i superblock

To repair file system by alternative-superblock use command as follows:

(Repair filesystem) 7 #e2fsck -f -b 8193 /dev/MyGroup/LogVol00

After using all alternate superblocks I am getting the same error message as shown below:

e2fsck 1.39 (29-May-2006)  
/dev/MyGroup/LogVol00: recovering journel  
e2fsck: unable to set superblock flags on /dev/MyGroup/LogVol00:

How can I troubleshoot this type of problem?

dr_
  • 28,763
  • 21
  • 89
  • 133
user2914
  • 2,521
  • 5
  • 21
  • 15

1 Answers1

1

You don't mention that you were making configuration changes before you rebooted and got the error. If you were making changes then that might give a clue as to where to look. However assuming that this just happened without any configuration being changed.

First off you may have a real disk problem. Look at the output from the

dmesg

command and see if that lists any issues after you have run the e2fsck command.

If that doesn't show any likely causes then check the status of your logical volume. Use

lvdisplay /dev/MyGroup/LogVol00

That will list a number of things. In particular look at the LV Write Access, LV Status and "LV Size" entries in the output. Readonly access or the wrong partition size would cause things to go wrong.

Richm
  • 3,812
  • 23
  • 15
  • #tail -f /var/log/dmesg doesn't show any message related to problem and when I use #lvdisplay /dev/MyGroup/LogVol00 then it shows message of "Locking type 1 initialisation failed"... – user2914 Dec 02 '10 at 04:09
  • Try doing lvdisplay --ignorelockingfailure /dev/MyGroup/LogVol00 – Richm Dec 02 '10 at 16:30
  • Hi Richm, # lvdisplay --ignorelockingfailure /dev/MyGroup/LogVol00 displays follows things: – user2914 Dec 03 '10 at 09:36
  • LV Name /dev/MyGroup/LogVol00 VG Name MyGroup LV UUID 0vzTSd-cBBo-3MRk-NF30-SYoV-venm-mA0WbR LV Write Access /read/write LV Status available # open 0 LV Size 128.00 MB Current LE 4 Segments 1 Allocation inherit Read ahead sectors 0 Block device 252:1 – user2914 Dec 03 '10 at 09:37
  • Ok that looks ok and matches the size of 131072 blocks. But looking at your original report again /dev/MyGroup/LogVol001 was checked where did that come from? What does /dev/MyGroup/LogVol00 contain? Do you really need it to boot? If not you may be able to edit /etc/fstab and reboot without it and then investigate when you have recovered. – Richm Dec 03 '10 at 17:14