UNEXPECTED INCONSITENCY run fsck manually redhat

Solution 1:

ProTip: When it says

Run fsck manually

What it actually means is

Run fsck in interactive mode and evaluate the output to decide what you want to do

NOT "Blindly use -y because that's what everyone else seems to do and it can't hurt anything".
fsck -y can be destructive. That's why it's not the default behavior.

It sounds like you have some pretty serious corruption (the "Error reading block 63471616" bit makes me think possibly physical disk damage), and frankly fsck may have made things worse.

If you have backups, now would be the time to use them. If not, and the data is important, I would image the partition (you can try running recovery tools like debugfs on the image).

Ultimately you probably want to just newfs (or mkextfs, whatever the Linux equivalent is) the partition -- if you're sure this isn't because of a physical disk failure.

Solution 2:

Note that the following method will not get your data back. It might restore your volume group metadata. You can always read the lvm documentation in product guide. It has detailed explanation of the commands I am going to tell.

Comment out the fs in fstab and then boot. Now, find the VG on which you ran the lvresize. I think it's vg_yavin.

Run this

vgcfgrestore --list <VG-NAME>

This will give a list of the break points on the VG before any significant operation was done. You have to find out the file corresponding to your lvresize operation. Theoretically it should be the most recent one.

On that file run

 vgcfgrestore --file /etc/lvm/archive/<file-name> <VG-NAME>

This will restore the metadata of the VG before the lvresize.

Boot up normally and see whether it works.

On the error message, your default superblock of the fs is corrupt. Try to boot up with the backup superblocks which should be present if you have a working dumpe2fs output. Then

e2fsck -b <backup_sb> <disk-name>

But depending on corruption and how badly the fs is now, it's all a probability.