topic Re: fsck problems ----- in Operating System - HP-UX

fsck problems -----

dictum9 — Fri, 08 Sep 2006 13:52:43 GMT

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 ...
#

Re: fsck problems -----

Jonathan Fife — Fri, 08 Sep 2006 14:00:01 GMT

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

Re: fsck problems -----

Steven E. Protter — Fri, 08 Sep 2006 14:00:40 GMT

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

Re: fsck problems -----

IT_2007 — Fri, 08 Sep 2006 14:01:07 GMT

use with -o option

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

Re: fsck problems -----

spex — Fri, 08 Sep 2006 14:02:56 GMT

etc,

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

PCS

Re: fsck problems -----

IT_2007 — Fri, 08 Sep 2006 14:03:15 GMT

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

Re: fsck problems -----

Pupil_1 — Fri, 08 Sep 2006 14:07:02 GMT

looks like ignite or backup is the last go.

Re: fsck problems -----

V.Manoharan — Fri, 08 Sep 2006 14:10:56 GMT

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

Re: fsck problems -----

Jaime Bolanos Rojas. — Fri, 08 Sep 2006 14:13:23 GMT

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.

Re: fsck problems -----

A. Clay Stephenson — Fri, 08 Sep 2006 14:16:35 GMT

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.

Re: fsck problems -----

Marvin Strong — Fri, 08 Sep 2006 14:24:54 GMT

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.

Re: fsck problems -----

dictum9 — Fri, 08 Sep 2006 14:43:35 GMT

# 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...

Re: fsck problems -----

Bill Hassell — Fri, 08 Sep 2006 14:45:42 GMT

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.

Re: fsck problems -----

inventsekar_1 — Fri, 08 Sep 2006 14:47:21 GMT

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.

Re: fsck problems -----

dictum9 — Fri, 08 Sep 2006 14:53:27 GMT

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.

Re: fsck problems -----

Steven E. Protter — Fri, 08 Sep 2006 15:04:50 GMT

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

Re: fsck problems -----

Sp4admin — Fri, 08 Sep 2006 15:18:39 GMT

Hi etc,

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

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

sp,

Re: fsck problems -----

dictum9 — Fri, 08 Sep 2006 15:30:31 GMT

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.

Re: fsck problems -----

A. Clay Stephenson — Fri, 08 Sep 2006 15:57:39 GMT

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.

Re: fsck problems -----

florin_10 — Sat, 09 Sep 2006 01:48:16 GMT

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