Boot problem - cannot find /stand/vmunix

[Seth Gustafsson]

I have an L-class system with two disk drives as vg00 and using MirrorUX. When I try and boot off the PRI disk, the system will not boot and I get the message

failed exec: cannot find /stand/vmunix

I can boot from SEC disk and bring the system up normally.

I can boot to ISL on the PRI disk. What can I do to fix this problem with the PRI disk.

Thxs, Seth

[Peggy Fong]

Hi
There are many things you can do. As I understand it you have a primary and a mirror disk and can boot from one and not the other. Did this start after extending your mirror? If so, then run lvlnboot -R /dev/vg00 to sync up the lvm data on both disk. lvlnboot -v should show your boot, root, swap and optionally dump configured (I am assuming this will be correct because you can boot from one disk).

You can also remove and recreate the lvlnboot info by running:
lvrmboot -r /dev/vg00

Then recreate boot, root, swap and dump

lvlnboot -b /dev/vg00/boot_lvol
lvlnboot -r /dev/vg00/root_lvol
lvlnboot -s /dev/vg00/prim_swap_lvol
lvlnboot -d /dev/vg00/dump_lvol

lvlnboot -R /dev/vg00 (can't hurt...)

reboot.

I find it hard to believe you don't have /stand/vmunix because you can boot from one disk that is part of the same volume group.

You can always try booting to maintenance mode on the disk that doesn't work

Reboot
override autoboot
boot from primpath (the one you're having prbs)
interact with IPL
hpux -lm
If this boots to what looks like single-user mode then your kernel is fine (and the lvlnboot -R I suggested at the beginning is probably all that was needed).

Activate vg00
vgchange -a y /dev/vg00
lvlnboot -R /dev/vg00
De-activate vg00
vgchante -a n /dev/vg00
Reboot server (do not use init)

Hope some of this helps,
~pf

[Peggy Fong]

Here's some more things to check.
Check the stand file system and verify that it is on the primary disk and mirrored to the second disk - example
lvdisplay -v /dev/vg00/lvol1 (or whatever stand is called.
Primary disk should be on left and mirror disk on right of display. If this is reversed then your boot paths and what you think is primary are crossed.

Also, while in multi on the disk you can boot from do a pvdisplay -v /dev/dsk/cXtYdZ on the primary disk that you cannot boot from. Verify that stand is the first lvol on the disk, swap is second and root is third. After that it doesn't matter what the order is.

Let me know if any of this works please...
Thanks,
~pf

[Wieslaw Krajewski]

Hi,

Everything what was said is true, but I would like to add something more as posiible reasons of the problem.

1. There is the LIF volume corrupted on the PRI disk,
for example LABEL file is missing or corrupted.

2. lvol1 copy on the PRI disk is not the very first on the PRI disk.

I think that the second reason is definitely less likely that the first one.
So to check if the first reason takes the place try:

after booting from the SEC working disk:

lifls -l /dev/dsk/c#t#d#
where the special file corresponds to the PRI disk.
You should see at least
ISL, AUTO,HPUX,LABEL and of course PAD.
In the case of missing LABEL file use mkboot command,
and then lvlnboot as mentioned in first answer.

Hope this helps.
Rgds.

[Insu Kim]

One of the possibilities is that you mirrored in the wrong sequence, which means that lvol1, /stand, should always be mirrored at the first, and the next lvol2, lvol3, lvol4 and so on.

To resolve this error,
Get into maintenance mode,
ISL> hpux -lm
And reduce all the logical volumes in vg00 in this order, lvol1, lvol2, lovl3 .....

# lvreduce -m 0 /dev/vg00/lvol1 /dev/dsk/...
# lvlnboot -b /dev/vg00/lvol1
# shutdown -ry 0

After system is up,
Remirror them in the string.

# lvextend -m 1 /dev/vg00/lvol1 /dev/dsk/...

Best regards,

[Thierry Poels_1]

I somehow disagree with In-Su, sorry ;)
Quote
One of the possibilities is that you mirrored in the wrong sequence, which means that lvol1, /stand, should always be mirrored at the first, and the next lvol2, lvol3, lvol4 and so on.
Unquote

Only the three first logical volumes (i.e. /stand, primary swap (dump) & /) have to be mirrored in sequence at first on the mirrored boot disk. The sequence and location of other logical volumes does not matter.

regards,
Thierry.

[Bill McNAMARA_1]

try an
ISL> hpux -ll

all potentially bootable kernels will be
displayed with an asterix * beside them.

you can then verify if there is one there or not..

You may have a problem with the /stand filesystem and may have to boot on recovery cd to fsck it.

Later,
Bill

[Insu Kim]

Thank you, Thierry, for your advice.

I've been learning a ton of knowledge in the forums.

[Thierry Poels_1]

I can certainly agree on that.
I'm currently using the forum as a steppingstone to HP-UX Certifications ;)
But don't tell anybody that we learn a lot in the forums, or HP will make us pay for it ;)
Thierry.

[Peggy Fong]

I doubt that /stand/vmunix is corrupt because the poster (who has never assigned any points- 0 of 27 points assigned) can boot from the "mirror" disk. It's more likely as many others have pointed out that either there is a problem with the LABEL file on that disk (which my commands will take care of) or /dev/vg00/{stand} is not first on the disk.
The point about LABEL being corrupt, etc is true -- I didn't mention that specifically in my post. My assumption was that the disk was mirrored and lvlnboot -R was not run therefore the LABEL files were not in sync. I believe that the fixes can be done in multi-user since the system will boot to one disk.

At least we can help each other learn - too bad we may not ever know if we help this administrator - I hope Seth will post a response and let us know what works! And assign points :)

peg

[Seth Gustafsson]

I appreciate all the responses and this is a great tool ? like the response about not telling HP due to they will probably start charging us ? hahaha.

The system is up and running but unfortunately due to the company business I have to wait until tonight to repair this problem.

As for some of the responses ? the volumes are in the right order /stand being the first one, so on and son on. Of all the responses I have to believe it is the LABEL that is corrupt. But anyway?. I will post the final resolution tonight.

Thxs Everyone.