fsck CANNOT READ BLK 14992 on HPUX 10.20

[Norman Woo]

Hi folks

I encountered a problem during the fsck phase after a system reboot (there goes the non-down time of 455 days!!!!). It reports that it cannot read block 14992 and kicks the process into the bcheckrc prompt directing me to run 'fsck' manually. After running fsck manually I still cannot continue with boot process. The bad block is on /dev/vg00/lv07 which (of all the luck) contains the data for /usr (bin, lib, and so on).

System is the ole-trustworthy HP735 running HPUX 10.20.

During the first time when I ran fsck it did prompt me with about 10 system files under /usr/lib that it encountered problem with and asked if I wanted it to remove it from the system. I forgot to note what
those 10 files were and answered "no". Subsequent running of "fsck" no longer prompts for the removal of those 10 files.

I was hoping to say yes and then recover those 10 files from backups. Is there a way to get fsck to prompt me for those files?

By answering 'yes' this time, I'm hoping that fsck would delete those files and then mark the bad block so that I can continue the boot process. As it stands now, when I do a CTRL-D, the remaining booting process fails because it looks for the executables under /usr which is empty as it cannot mount /dev/vg00/lv07 there.

Is there a way to force a mount of /dev/vg00/lv07? I tried mount -f but this extension is not recognize under 10.20. What is the proper command?

Or is there a way to tell fsck to skip block 14992 or mark it bad?

Hopefully, once these files have been removed, bad blocks marked and then the logical volume mounted under /user, can I recover these /usr/lib/lib* files from another system (HP 817s) also running 10.20 or from another HP 7XX system?

Thanks for all your suggestions.

[Oh yeah, found out that the system went bersek when the air-conditioner in the server room failed and temperature shot up to 40 degress celcius!!!]

[monasingh_1]

Let it take rest and cool down before trying too much.
One other option is to take the disk out and connect it to other machine and try fsck there with more comfort, I know it may not be of much help, but then you can run few online diagnostics test.

Also try dd ( on rlvol7) after mounting disk on other system and see if it goes through , may not work but worth a try. If it does work then create the same size of lv and dd to the new one and then try to mount the new one after fsck.

good luck...

[Steven E. Protter]

You have to go through fsck.

I'd wonder if you have hardware issues. I've attached a script that might be able to highlight other heat related damage.

SEP

[melvyn burnard]

well you could try mount using a read only option (-r), but I am not near a 10.20 system to try it ;-[. It may mount ok, but then again it may not. the force (-f) option is only valid for hfs file systems, sadly.
If you have a persistant bad block, fsck will not be able to fix it, as this generally is more of a hardware issue.
you may have to newfs the file system, and recover from backup, how did you backup th system? fbackup?

[Frank Slootweg]

See my response in your thread in the Usenet Newsgroup comp.sys.hp.hpux :

http://groups.google.com/groups?selm=b3ifl6$e9t$1@support.neth.hp.com

[Norman Woo]

Hi folks

Some more information about my system:

1) The disk in question is HFS formatted with logical volumes on it.

2) The mount -f does not work under HPUX 10.20

3) I'm currently running the dd command to copy the disk c0t6d0 to a new new c0t5d0 of the same size (3 Gig):

dd if=/dev/dsk/c0t6d0 of=/dev/dsk/c0t5d0 conv=norerror

I started this running yesterday at 1:00 PM and as of this morning (9:00 AM) it is still running. It has reported the following errors:

151264+0 records in
151264+0 records out
dd read error: I/O error
151264+1 records in
151264+0 records in
dd read error: I/O error
151264+2 records in
151264+0 records in
dd read error: I/O error
151264+3 records in
151264+0 records in
dd read error: I/O error
1749740+4 records in
1749740+0 records in
dd read error: I/O error

Question: I forgot to add in the "bs" parameter. Will this be a problem? Also, should I stop this process or is dd still continuing to create the data on the new disk as I have the "conv=noerror" parameter set. Is it normal for dd to be running this long?

4) Someone also mentionned that I can use the support utility from the 10.20 support disk called COPYUTIL. It is suppose to create a disk image and if it encounters any bad blocks it will zero out that block in the image. So should I kill the existing dd job and go with the COPYUTIL?

Thanks

[Pete Randall]

Right now it's running at the default blocksize of 512 bytes. This could take days. You would probably be better off to kill this one and start again with "bs=1024k".


Pete

[Frank Slootweg · Accepted solution]

What do you mean by "2) The mount -f does not work under HPUX 10.20"?

What error message does it give?

Also note that it should be "mount -f -F hfs ....", i.e. with "-F hfs".

[Frank Slootweg]

Did you solve the problem? If so, how?

Not that I do not appreciate the (10) points, I do, but knowing that the problem is solved and how is the most important.

[Norman Woo]

Hi

Yes I was able to force a mount using the "-F hfs". Once mounted, I quickly backed up the information on that logical volume using the "dump" command.

Also, just to be safe, I also created an image using the "copyutil" utility from the 10.20 support disk.

Now I am in the process of adding the new disk and bringing back the data.

I had to kill the 'dd' command because it was taking too long.

So thanks to everybody here.
(Now I can go on vacation next week - spring break up here)