fsck problems -----

[dictum9]

I had a machine crash after which a vg00 filesystem did not come up. When I tried to mount it, it said to run fsck. But fsck is giving me problems:

----------------------------------------------------------------------------------


# fsck -F vxfs /dev/vg00/rlvol10
file system is larger than device
vxfs fsck: cannot initialize aggregate
file system check failure, aborting ...
#

[Jonathan Fife · Accepted solution]

Did the machine crash after an lvreduce but before the filesystem was reduced?

[Steven E. Protter]

Shalom,

fsck -F vxfs -o full -y /dev/vg00/rlvol10

If this does not help its pretty hopeless.

You may need to run newfs which will wipe out all the data.

You of course have a good backup ready.

SEP

[IT_2007]

use with -o option

fsck -F vxfs -o largefiles /dev/vg00/rlvol9

[spex]

etc,

Unfortunately, you'll have to restore vg00 from a backup.

PCS

[IT_2007]

If something changed in the filesystem, you may not able to recover it. you may have to recreate it with newfs command.

[Pupil_1]

looks like ignite or backup is the last go.

[V.Manoharan]

try
fsck -F vxfs -o full -y /dev/vg00/rlvol10
if doesn't work go for ignite restore.

[Jaime Bolanos Rojas.]

Etc,

Use Steven's syntax or IT's, also you might want to add the -m option to see what returns:

http://docs.hp.com/en/B2355-60105/fsck.1M.html

"-m Perform a sanity check only. fsck will return 0 if the file system is suitable for mounting. If the file system needs additional checking, the return code is 32. If the file system is mounted, the return code is 33. Error codes larger than 33 indicate that the file system is badly damaged."

Regards,

Jaime.

[A. Clay Stephenson]

vg00/lvol10 is not a standard LVOL. You should be able to bring the machine up in single user mode and recreate the filesystem via newfs and then restore from backup.

An easier method is to bring the box up in single-user mode, mount /var and /usr and then vi /etc/fstab. I would comment the entry out of /etc/fstab and allow the box to then come up in normal multi-user mode.
You can then recreate the filesystem and restore it at leisure.

This really looks like you broke one of the system setup rules and are using vg00 for purposes other than solely for the OS.

[Marvin Strong]

boot single user and you should be able to check vg00. since lvol10 is not normally part of a default OS install.

fsck -F vxfs -o full {dev}

might work but doesn't look promising.

you can with lvdisplay determine the appropriate size that the filesystem on lvol10 is supposed to be and try to fix it with fsadm or you might have to newfs that filesystem.

[dictum9]

# fsck -F vxfs -o full -y /dev/vg00/rlvol10
file system is larger than device
vxfs fsck: cannot initialize aggregate
file system check failure, aborting ...



It's an architechtural issue all right. /dev/vg00/lvol10 is /var/opt/ignite and 20GB. It should have had its own volume group, or at least as an lvol in some other VG, not vg00. It didn't appear to be mirrored. I don't know why I lost it as a consequence of loosing the primary disk. Anyway, it appears to be hosed.

I will recreate it and install the latest-n-the greatest version of Ignite.

I don't think I have any backups...

[Bill Hassell]

It looks like someone (root) ran lvreduce on the lvol and nothing else. This destroyed the filesystem because part of the lvol has been removed. fsck can fix logical problems but this is technically a physical problem (missing disk space) so fsck will fail with either the message you saw above or an errno 5 which is an I/O error. The I/I error occurs because the driver tries to read beyond the end of the disk (lvol). If you have any idea how large the lvol was before the crash, you might use lvextend to put the lvol back to it's original size. However, since a crash just occurred, your system may be much more damaged than just this lvol. lvreduce is a sledge hammer and knows nothing about files and directories.

[inventsekar_1]

the -o full option reference from man fsck_vxfs:

-o Specify VxFS file system specific options. These
options can be a combination of the following in a
comma-separated list:

full Perform a full file system check.

nolog Do not perform log replay. This option may
be used if the log area was physically
damaged.

Note: Use fsck -o full,nolog on clean file systems. If
fsck -o full without nolog is run on a clean file
system, it first replays the intent log. Since the
VX_FULLFSCK flag is set, an fsck does not update the
inode and extent maps before performing the full check,
so it reports inconsistencies. Use the -n option to
verify file system inconsistencies.

Because VxFS maintains an intent log, a complete check is generally
not required; the default is to replay the intent log only. If
fsck_vxfs detects file system damage or the log replay operation
detects damage, an indication that a complete check is required is
placed in the super-block. In this case, if the -y option was
specified, the full check will be run after the log replay. If the -y
option was not used, fsck must be run again, with the -o full option
to perform the full structural check.

[dictum9]

Bill Hassell

I don't understand where you got the idea that lvreduce was run. I certainly didn't and couldn't find any reference in the history files.

Nevertheless, the fact of the matter is that the lvol, the /var/opt/ignite partition is corrupt, won't mount, won't fsck and I have to reinstall the thing.

I will install it in a different VG. It appears that I don't have enough disks to create its own VG. (A PV cannot be a part of mroe than 1 VG) So I will have to borrow space in another VG.

I think it got corrupt because it was in VG00.

[Steven E. Protter]

Shalom,

Bill may get the idea from the original error message which says the filesystem is bigger than the logical volume.

lvreduce is one way to cause this.

SEP

[Sp4admin]

Hi etc,

fsck -F vxfs -o full -y /dev/vg00/rlov#

You may have some bad hardware if this doesn't work.

sp,

[dictum9]

Okay... Conceivably, it may have been run via sam.

Anyway, I am going to rebuild the whole /var/opt/ignite partition, and use different disks.

This is an olde K570 so that the disks are old and way beyond their mean failure time.

[A. Clay Stephenson]

I think it got corrupt because it was in VG00.

This makes no sense. All anyone has said is that you shouldn't use vg00 for non-OS stuff not that you can't. vg00 is no more and no less prone to failure than any other volume group.

There are other ways to utterly corrupt a filesystem/LVOL rather than running lvreduce. For example, if you dd'ed to the raw drive you could clobber LVM metadata.

[florin_10]

Recreating the file system on a different vg and restoring data from backups, as explained before, will save time and resolves the issue.
flg