/stand/vmunix missing

[bi]

One of our HP systems is missing its vmunix file from /stand.

/stand has system, vmunix.prev and system.prev. /stand/build has vmunix_test.

It appears someone was trying to manually rebuild the kernel and didn't quite finish. there also is a file named .update_ux in /stand which has one line in it: /stand/build/vmunix_test.

sam, of course, can't read the kernel. Any advice on how to repair this? And what is the system using for its kernel?

Please help. Thanks.

 

[smurtzy]

The system is up and running as it has the current kernel in memory, if you were to reboot you would be able to boot without pointing to a new or previous kernel.
Not sure of you OS but you can login into to the ISL and choose to boot from your previous kernel:
At the ISL do an ll and see if you have vmunix.prev still with you.

ISL>hpux -ll

This will display all the kernels with a * mark at the end. Boot from the available kernel. For ex., if it lists vmunix.prev then boot from it with the following syntax

ISL>hpux /stand/vmunix.prev

Once the system is up, then rebuild the kernel.. Once the kernel is rebuilt make sure you have it under /stand as vmunix and then reboot the system.

 

[throat]

I would be tempted to run

mk_kernel -o /stand/vmunix

and debug whatever the "someone" was trying to do. If it goes through without any warnings you will have a new vmunix to try booting from.

Make another copy of vmunix.prev - it may be the only bootable one you have until you sort out the mess.

Cheers,
Steve.

 

[bi]

Thanks, both of you, for answering this. What happened was that we had to bind a driver for our autoloader picker to the kernel (sam doesn't do that) and manually rebuild the kernel. Someone was to have gotten permission to boot the box to put the kernel in place, but never followed up.

I ended up rebuilding the kernel again (from what was running in memory) and booting the box to make it stick.