hpux11i 32/64 bit upgrade fails

[Ravinder Kaul]

Hi

the HPUX11i upgrade from 32 to 64 bit gives the following error
Compiling /stand/build/conf.c...

Loading the kernel...
ld: Bad init() routine for the plug-in loaded from /opt/langtools/lib/libcomp.sl
Fatal error.
*** Error exit c
Stop.
ode 1
make failure.
ERROR: The kernel build failed

The swlog shows that the upgrade process is completed successfully .
* Summary of Execution Phase:
* 2 of 35 filesets were Skipped.
* 33 of 35 filesets had no Errors or Warnings.
* The Execution Phase succeeded.

NOTE: Software requiring a reboot has been installed, but the kernel
build, reboot, and configure steps are being skipped because
those tasks are being done by the program that invoked
swinstall.

======= 03/02/04 20:25:10 IST END install AGENT SESSION (Rebooting
Any asistance to resolve it will be appreciated

[Steven E. Protter]

Sorry to be the bearer of bad news but a cold install is the way to go here.

The kernel customization your apps required is simply too much for the update/ux to handle.

Best bet is a cold install, install the applications, then migrate the data.

SEP

[Ravi_8]

Hi,

you might not be having sufficient space in /stand.

I prefer cold install rather than upgrade.
upgrading creates lots of problem with applications

[Ravinder Kaul]

Steve,Ravi

Thanks for th reply. May be cold install is the way to go. Steve, Which data r u referring to for migrating. There is a external disk box connected to the server. IF I export the data vgs info before reinstalling and then import the data vgs back into the OS I should be able to mount the volumes and use them or is there any more steps to be carried out

[Naveej.K.A]

hi kaul,

following is the procedure to export/import volume groups

Importing and exporting VGs
The functionality of exporting VGs allows you to remove all data concerning a dedicated VG
from the system without touching the data on the disks. The disks of an exported VG can be
physically moved to another system and the VG can be imported there. Exporting a VG
means the following: remove the VG and corresponding PV entries from /etc/lvmtab and
remove the VG directory with their device files in /dev. Again - the data on the disks is left
unchanged.
Since the structural layout of the LVM information on disk has not changed throughout the
HP-UX releases you can import a VG that has been created on a UX 10.20 system e.g. on a
UX 11.11 system.
vgexport has a -m option to create a so called mapfile. This ascii file simply contains the LV
names because they are not stored on the disks. You need a mapfile if you do not have the
standard names for the LV device files (lvol1, lvol2, ...).
Hereâ s the procedure to export a VG on system A and import it on system B:
on system A:
Umount all LVs that belong to the VG and deactivate it:
# vgchange -a n vg01
Export the VG:
# vgexport -v -m /tmp/vg01.map vg01
Now all information about vg01 has been removed from system A. The disks can now be
moved to system B and the VG can be imported there:
on system B:
Create the directory for the LV device files and the group file. It is important to choose a
minor number that is unique on system B.
# ll /dev/*/group
# mkdir /dev/vg01 (you could also choose another VG name)
# mknod /dev/vg01/group c 64 0x##0000
NOTE: Starting with LVM commands patch PHCO_24645 (UX 11.00) or PHCO_25814 (UX 11.11)
vgcreate and vgimport will check for the uniqueness of the group file's minor number.
Now copy the mapfile from system A and import the VG:
# vgimport -v vg01 -m /tmp/vg01.map /dev/dsk/c1t0d0 /dev/dsk/c1t1d0
NOTE: The PV device files may be different on system B compared to system A.
If you have a bunch of disks in the VG you may not want to specify each of them within the
argument list of vgimport. Using the -s option with vgexport/vgimport lets you get around
this:
# vgexport -v -s -m /tmp/vg01.map vg01
If you specify -s in conjunction with the -m option vgexport simply adds the VG-ID to the
mapfile:
# cat /tmp/vg01.map
VGID bfb13ce63a7c07c4
1 lvol1
2 lvol2
3 lvsap
4 lvdata
When using the -s option with the vgimport command on system B all disks that are
connected to the system are scanned one after another. If the VG-ID listed in the mapfile is
found on the header of a disk this disk is included automatically into the VG
Hereâ s the appropriate vgimport command:
# vgimport -v -s -m /tmp/vg01.map vg01
So you do not have to specify the PVs anymore.

regds