FSCK problems

[Stefan Saliba]

I am doing an fsck -y on my filesystem and it will always says SuperBlock marked as clean , modifications made , reboot HP-Ux with reboot -n.

I reboot and if I do fsck again it will again do the same.

Is this normal or is there something with my disk. The system works fine but when I checked this command on another system it did not behave like this.

Stefan

[Paula J Frazer-Campbell]

Hi Stefan,

On the other servers are they the same? are the disks the same? are the arrays the same?


During normal boot up what does fsck tell you?


Paula

[Steven Sim Kok Leong]

Hi,

Did you fsck the filesystem while it was mounted and being accessed?

Try booting up the system in single-user (hpux -is) or maintenance mode, subsequently perform an fsck on the LVs without mounting the filesystems.

Hope this helps. Regards.

Steven Sim Kok Leong

[A. Clay Stephenson]

Hi Stefan,

I assume that this is your / filesystem. It is very important that you do a 'reboot -n' immediately after the fsck. Do not do simply a reboot or a shutdown. The idea is that in this case you do not want to flush the buffers to disk; that would simply corrupt the filesystem again.

[Stefan Saliba]

Yes it is the root filesystem and it was mounted when I did fsck. Is it not allowed to do fsck when it is mounted? Do you think i have some physical failure on the disk ?

[A. Clay Stephenson]

Hi:

In your case, unless you take the disk out and import it to another machine and then do an fsck, it will have to be mounted because it's the root filesystem. I doubt that you have a disk failure, it's just essential that you do a reboot -n and nothing else after the fsck.

[Stefan Saliba]

Yes I do a reboot -n but it seems I am in a vicious circle. I do a reboot -n , then system boots, I redo an fsck then it says again do reboot -n so it's like a vicious circle it never ends.

[Steven Sim Kok Leong]

Hi,

Is your root filesystem mirrored? If it is, you can split the mirror, fsck the mirrored LV (eg. /dev/vg00/lvol1b) without mounting it. Then modify your /etc/fstab to mount / using /dev/vg00/lvol1b instead of /dev/vg00/lvol1. Subsequently perform a reboot -n. In this case, shutdown will also work.

If your root filesystem is not mirrored, then follow the instructions in this document to run a recovery shell using your SUPPORT CD:

http://us-support.external.hp.com/cki/bin/doc.pl/sid=2e3a56e617dd2dedb5/screen=ckiDisplayDocument?docId=200000047869320

Once you are in the recovery shell with the appropriate settings configured (indicated in the document), you can perform an fsck on the root filesystem LV (eg. /dev/vg00/lvol1).

Here, I have extracted the crucial steps from the guide for your convenience:
=================================================
Support# chroot_lvmdisk <-------- You type this
Enter the hardware path associated with the '/'(ROOT) file system
(example: 10/0.6.0 ) <-------- Your boot disk path should be listed

Is 10/0.6.0 the hardware path of the root/boot disk?[y|n|q]-y <-- if correct
**** Automated from here ****
/sbin/fs/hfs/fsck -c 0 -y /dev/rdsk/c0t6d0s1lvm
** /dev/rdsk/c0t6d0s1lvm <--- The SupportCD's path to your HFS /stand
** Last Mounted on /stand
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
55 files, 0 icont, 47805 used, 24 free (24 frags, 0 blocks)
***** MARKING FILE SYSTEM CLEAN *****

***** FILE SYSTEM WAS MODIFIED *****

Mounting c0t6d0s1lvm to the Support Tape's /ROOT directory...

/sbin/fs/vxfs/fsck -y /dev/rdsk/c0t6d0s2lvm <----- Normally your / (JFS)
log replay in progress
replay complete - marking super-block as CLEAN
/sbin/fs/vxfs/mount /dev/dsk/c0t6d0s2lvm /ROOT
/sbin/fs/hfs/mount /dev/dsk/c0t6d0s1lvm /ROOT/stand
loading /usr/sbin/chroot
x ./usr/sbin/chroot, 12288 bytes, 24 tape blocks
Enter 'cd /ROOT; chroot /ROOT /sbin/sh' at the shell prompt to chroot to
the customer's /(root) disk.
Support#: <------- If all goes well, it stops here.
=================================================

Hope this helps. Regards.

Steven Sim Kok Leong

[Frank Slootweg]

Because this is the root filesystem, and hence can not be unmounted, you must do the fsck in single-user mode ("init s" or better reboot to single user mode ("ISL> hpux -is" or "init:s:initdefault:" in /etc/inittab).

For the same reason, you must use the *block* device i.e. /dev/vg00/lvol? (not rlvol?).

When it says to "reboot -n" you *must* do so *immediately*, i.e. *no* other commands between the end of the fsck and the "reboot -n".

The point is that fsck has just marked the filesystem clean, but because it is still mounted (because it can not be unmounted), an operation beween the fsck and "reboot -n" can mark it non-clean again.

[Frank Slootweg]

> Yes I do a reboot -n but it seems I am in a vicious circle. I do a reboot -n , then system boots, I redo an fsck then it says again do reboot -n so it's like a vicious circle it never ends.

Do you do the *second* reboot also in single-user mode?

I.e. the sequence should be:

- Boot in single-user mode.
- fsck /dev/vg00/lvol? fsck *reports* and *fixes* errors and says to "reboot -n"
- *Immediately* do "reboot -n".
- Boot again in single-user mode.
- fsck /dev/vg00/lvol? should report *no* errors. Follow *exact* instructions as fsck gives them.

[Stefan Saliba]

My question is this frank, if I am in multiuser mode, and do an fsck -y on the root file system, is it normal for me to get "Filesystem marked as clean, reboot using reboot -n " on the console.

I tried this on another similar box and it did not give any messages to reboot.

I will try booting in single user mode and do an fsck on lvol1. then boot multiuser and do an fsck -y again and see if it complains again

stefan

[Frank Slootweg]

> My question is this frank, if I am in multiuser mode, and do an fsck -y on the root file system, is it normal for me to get "Filesystem marked as clean, reboot using reboot -n " on the console.

Yes, that is normal, especially if the fsck run *fixed* something.

> I tried this on another similar box and it did not give any messages to reboot.

Probably because on *that* system, nothing was fixed, so there was no need to reboot.