System recovery via network book - looking hopeless

[paul_xedos]

Hi,

I'm attempting to perform a system recovery after the 11.31 system failed on a reboot (" Could not open vmunix")

Now in the recovery shell ( net booted) and wanting to mount the root 

Select one of the following:
a. Mount the root disk and exit to a shell only.
b. Recover the bootlif/os partitions.

m. Return to 'HP-UX Recovery Media Main Menu'.
x. Exit to the shell.

option 'a' fails:

Selection: a

Loading /sbin/fsck...

** /dev/rdsk/c0t0d0
BAD SUPER BLOCK: MAGIC NUMBER WRONG
USE -b OPTION TO FSCK TO SPECIFY LOCATION OF AN ALTERNATE
SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(1M).
'fsck' could not fix all customer file system errors with the options and
answers specified. You may wish to run 'fsck' again with different options or
attempt to repair the file system with the 'fsck -b' option to use a redundant
superblock. Automatic recovery cannot be completed unless the target file
system can be successfully 'fsck'ed.

option 'b' fails:

idisk: Primary partition information not valid.
Run idisk with -r option to restore.
The verification failed. Trying to restore
the partitions of /dev/rdsk/c0t0d0.

Restoring Primary Header and Table from Alternate.
Restoration of partitions on /dev/rdsk/c0t0d0 completed OK.

Verification of partitions on /dev/rdsk/c0t0d0 completed OK.

Running mkboot to verify/repair boot areas.

Specifying -e option requires devices files for EFI and HP-UX partitions.
 mkboot failed.

I've now exited to the shell and wondering where to go next

Unfortunately, I can't give any clues as to why the system is in this state

Regards

Paul

[Bill Hassell]

>> Could not open vmunix

The loader is trying to locate the vmunix file. Unfortunately there are no details so this could simply be that a root user removed /stand/vmunix or that the /stand directory is corrupted and unrecognizable. See the next error message:

>> Loading /sbin/fsck...

>>

>> ** /dev/rdsk/c0t0d0
>> BAD SUPER BLOCK: MAGIC NUMBER WRONG

This generally indicates that the filesystem has been trashed. In a very small number of situations, the magic number area may have been erased yet the rest of the filesystem is intact and an alternate super block may salvage the data. I have only seen this in the classroom with carefully crafted filesystem damage.

The next steps (restoring the boot area) do not change the contents of the /stand directory.

This is when you are very happy about making a recent Ignite backup of the system.