Location of /stand mount point ?

[eric lipede_1]

Hi
What are the consequences, if any, of mounting /stand on a logical volume other than /dev/vg00/lvol1 ? Thks in advance

[eric lipede_1]

HPUX 11v2 and 11v3

[Torsten. · Accepted solution]

/stand must be the first LVOL on the disk and all configuration must be correct to allow a system boot.

If something is wrong, the system cannot access the kernel, so it will not boot.

[eric lipede_1]

Hi
Yes, thats what I thought, however, I came across this (not my doing i have to say !!)

/dev/vg00/lvol13 557056 253845 284277 47% /stand

uptime
2:33pm up 33 days, 14:57, 5 users, load average: 0.01, 0.01, 0.01

Now, as far as I can tell, the reboot was successful. So, in your experience:
1. Can this be left as is;or
2. should this be moved (lvol1 isnt being used) via maintainance mode and remounted on the correct mount point?

...whats the best way forward here - thks

[Matti_Kurkela]

If you create a "fake /stand" elsewhere but don't delete the old /dev/vg00/lvol1, the system will boot just fine and will seem to work... but any new kernel configuration changes and kernel patches won't actually "take".

For example, swlist will indicate that new patches will be properly installed and configured, since the new kernel image can be created successfully. It's just that after a reboot, the old kernel will still be used instead of the new one.

The bootloader will still look for a kernel in the first filesystem of the disk selected for booting. Unless you've customized the boot parameters, the kernel will expect to find the root filesystem on the same disk the kernel and the bootloader has been loaded from.

MK

[Dennis Handly]

>/dev/vg00/lvol13 557056 253845 284277 47% /stand

Were you using DRD? Do you actually see a vmunix there?

>as far as I can tell, the reboot was successful.

Yes, the kernel knows how to get to itself.

>1. Can this be left as is

I wouldn't think so.

[Torsten.]

What does

# lvlnboot -v

tell you?

[eric lipede_1]

Hi
the kernel sits in /stand/vmunix and the system reboots fine. I have no idea why the creator decided this. Whats the best fix here?
Thks

[eric lipede_1]

/stand# lvlnboot -v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c2t0d0s2 (0/1/1/0.0.0) -- Boot Disk
/dev/dsk/c2t1d0s2 (0/1/1/0.1.0) -- Boot Disk
Boot: lvol1 on: /dev/dsk/c2t0d0s2
/dev/dsk/c2t1d0s2
Root: lvol3 on: /dev/dsk/c2t0d0s2
/dev/dsk/c2t1d0s2
Swap: lvol2 on: /dev/dsk/c2t0d0s2
/dev/dsk/c2t1d0s2
Dump: lvol2 on: /dev/dsk/c2t1d0s2, 0

lvlnboot: Volume group not activated.
Cannot display volume group "/dev/vgciapk".
lvlnboot: Volume group not activated.
Cannot display volume group "/dev/vglock".


more /etc/fstab
# System /etc/fstab file. Static information about the file systems
# See fstab(4) and sam(1M) for further details on configuring devices.
/dev/vg00/lvol3 / vxfs delaylog 0 1
/dev/vg00/lvol12 /stand vxfs tranflush 0 1
/dev/vg00/lvol4 /tmp vxfs delaylog 0 2
/dev/vg00/lvol5 /home vxfs delaylog 0 2
/dev/vg00/lvol6 /opt vxfs delaylog 0 2
/dev/vg00/lvol7 /usr vxfs delaylog 0 2
/dev/vg00/lvol8 /var vxfs delaylog 0 2
/dev/vg00/lvol9 /var/adm/crash vxfs delaylog 0 2
/dev/vg00/lvol10 ... swap pri=1 0 0
/dev/vg00/lvol11 /oracle vxfs delaylog,largefiles 0 2


lvdisplay -v /dev/vg00/lvol1
--- Logical volumes ---
LV Name /dev/vg00/lvol1
VG Name /dev/vg00
LV Permission read/write
LV Status available/syncd
Mirror copies 1
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 304
Current LE 19
Allocated PE 38
Stripes 0
Stripe Size (Kbytes) 0
Bad block off
Allocation strict/contiguous
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c2t0d0s2 19 19
/dev/dsk/c2t1d0s2 19 19


/dev/vg00/lvol1 is unused ??

[Torsten.]

Here you can see

Boot: lvol1 on: /dev/dsk/c2t0d0s2



So the system still boots from LVOL1.