Michael,

What did you mean by clearing the jfslog partition in your comment:

"In particular with / (or hd4), you may need to clear the jfslog partition before fsck will be able to rebuild the superblock information."

Is that the same as "yes | logform /dev/hd8" ?


By the way, I think (or hope) I am making some progress.

The first time I tried to follow the procedure mentioned before, I received the "lqueryvg" messages and the "unable to read superblock" messages one hour after selecting the option:

2) access this volume group and start a shell before mounting the filesystems

I did try to do some fsck manually, but they gave the same error messages (Unable to read superblock).

When I follow the procedure today, after 11 minutes the console is showing me this:

---------------------------------------------
importing volume group
rootvg
checking the / file system

log redo processing for /dev/rhd4

after another 35 minutes the following messages appear on the console:

syncpt record at 20c0c8
error writing 7,48
write of map failed 4
update of maps failed
update of superblock failed
write of map failed 5
update of maps failed
update of superblock failed
write of map failed 6
update of maps failed
update of superblock failed
write of map failed 7
update of maps failed
update of superblock failed
write of map failed 8
update of maps failed
update of superblock failed
write of map failed 9
update of maps failed
update of superblock failed
end of log 2142ff8
syncpt record at 20cc0c8
syncpt address 20bf0d4
number of log records = 4998
number of do blocks = 84
number of nodo blocks = 0
failure replaying log = 0
/dev/rhd4: unable to read superblock (TERMINATED)
checking the /usr filesystem

/dev/rhd2: unable to read superblock (TERMINATED)
exit from this shell to continue the process of accessing the root volume group
#

after that I tried to clean the jfslog:

# /usr/sbin/logform /dev/hd8
logform: destroy /dev/hd8 (y)? y
/usr/sbin/logform: I/O error

and a fsck:

# fsck -n /
fsck: unable to read superblock (TERMINATED)

I am used to the fact that occassionally fsck won't repair all the issues at once the first time, so I will repeat the actions one more time tomorrow. Maybe the error messages (write of maps failed etc) will be less, then I know it is really progressing. Otherwise, I think I will have to replace the disk and install the machine from scratch....

John and Michael,

Thanks for the help, I'll let you know what I've done.

Your last remark was a bit disappointing, Michael. It would have been easier if somebody had seen this before.... 

Luckely, it is a test machine, not a critical one.

The code being executed to give you code 555 is:

When you enter maintenance mode be sure (as John suggests) to varyon rootvg without mounting the filesystems.

At this point you can run fsck -n on /dev/hd4 and see what errors it reports. If you can at least run the -n option successfully, you should also be able to run a corrective action.

Maybe you have a low level disk failure - you could try mounting /var and reading the error logs, and/or use alog -o to read a log (e.g. the console log) for error messages posted before the server went down.

Sometimes the "corrupted" area is the jfslog (or jfs2log). Again, start with fsck -n on all the other filesystems to know which ones need no attention. If you have any reason to doubt logical volume hd8 then reformat it (yes | logform /dev/hd8) and run fsck again.

In particular with / (or hd4), you may need to clear the jfslog partition before fsck will be able to rebuild the superblock information.

Advice: be conservative - use fsck -n first to see the errors fsck is finding before actually starting a fix.

Were you taking option 4, the without mounting filesystems one ?
fsck will usually fail on a mounted filesystem, not necessarily because there is a problem, and it can't write to it to fix anything if it's done while mounted.