Bad Super Block

[Stephen Hughes]

I have had a disk failure on my HP 9000 server. The disk has been replaced, but now while rebooting the system, I get a "BAD SUPER BLOCK: TRASHED VALUES IN SUPER BLOCK USE -b OPTION TO FSCK TO SPECIFY LOCATION OF AN ALTERNATE SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(1M)." error. I started the comamnd fsck -y -b -F hfs /dev/vg00/rodex and after 3 and a half hours, the fsck stopped with the following error "Pid 2168 received a SIGSEGV for stack growth failure. Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz." I used the SUPER BLOCK SIZE of 16. The size of the filesystem is 15 Gig.

What else can I try to fix the disk?

[Denver Osborn]

Has anything been done to the drive to restore the LVM information to it??

# vgfcgrestore -n /dev/rdsk/
# vgchange -a y /dev/vgname

[John Palmer]

Id this filesystem mirrored? If not then you are wasting your time trying to fsck it.

As per the previous post, you have to restore LVM information to the disk with vgcfgrestore. The vgchange causes the volume group to accept the replaced disk. This will not restore any data other than mirrored volumes which should resync automatically.

[Shelby Dunlap]

If this system is running HP-UX 11.0 (found with uname -a), make sure that you don't have PHKL_18542, PHKL_19060, or PHKL_19909 on your system. If you do, see about possibly install the latest superceding patch, or remove and recreate the mirror instead of resychronising the logical volume. 'swlist' can be used to see if these patches are installed on your system. These patches have been known to, in mirrored environments, cause data corruption when disks are replaced.

--

If by some chance the volumes don't sync automatically when you vgchange, which I often see they don't, you can manually sync them with a:
vgsync

[Insu Kim]

Take a look at the file, /var/adm/sbtab, which has information of alternative super blocks.
You can use them when you fsck shown below.

Inside sbtab.
16 32 2504 .....
--------------------

# fsck -F hfs -y -b 16
In the case of fsck's failure above,
# fsck -F hfs -y -b 32
From your article,
I hope that you do this in maintenance mode because root file system may be corrupted, I guess.

After finishing fsck, a list of message will show on the console and if you find "reboot -n" on the message, perform "reboot -n" at prompt when fsck has completed.


Regards,