11-22-2013 05:51 AM
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:
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.
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
11-24-2013 06:28 PM - edited 11-24-2013 06:29 PM
>> 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.