Operating System - HP-UX
1834698 Members
2508 Online
110069 Solutions
New Discussion

fresh kernel with old filesystems?

 
tech1214
Advisor

fresh kernel with old filesystems?

I want to re-install my kernel, without having to do a re-install of the entire system. In other words, I want to get a fresh, brand-spanking new, unpatched kernel installed but not affect anything other than the kernel itself - I don't want to redo my logical volumes, or filesystems or data on the filesystems.

I've thought about taking the /usr/conf from a virgin system and just using that to over-write the current /usr/conf, but that will make all the sw databases out of sync. I prefer to keep them accurate.

Is there a clean way to go about this task?

Thanks.
6 REPLIES 6
Patrick Wallek
Honored Contributor

Re: fresh kernel with old filesystems?

What exactly are you trying to accomplish here?

I wouldn't necessarily recommend copying a kernel from another machine as the kernel file itself (/stand/vmunix) may have dependencies elsewhere.

If you did copy a kernel from another machine and then rebooted yours, you could very easily wind up with a non-bootable machine.

Give more details on why you wish to do this and maybe we can come up with a better answer for you.
James R. Ferguson
Acclaimed Contributor

Re: fresh kernel with old filesystems?

Hi:

Using SAM, select a default template for your kernel -- for instance, the OLTP DB Server template. This one, or others, should provide you with the starting point you seek.

...JRF...
Bill Hassell
Honored Contributor

Re: fresh kernel with old filesystems?

HP-UX isn't just a kernel. There are libraries, daemons, subsystems, most of which reside in various files in vg00....in other words, it's not possible to run an unpatched kernel until you uninstall all patches on the system. If you look at kernel and subsystem patches, you'll see in the patch details that some kernel-build files are replaced along with executables and libraries used by the kernel when it boots.

The only way to start fresh (and have everything work as it was originally designed) is to do a cold install, preferably from the most recent version of the Core/Install CDROM.

Perhaps you have reliability problems with randomly applied patches. A suggestion is to use the Quality Patch bundle found on the SupportPlus CDROM. Thousands of customers use this on a quarterly or twice a year without problems.


Bill Hassell, sysadmin
James R. Ferguson
Acclaimed Contributor

Re: fresh kernel with old filesystems?

Hello again:

If you really want to start from scratch, 'vgexport' all your non-vg00 volume groups; do a cold-install and apply a known set of patches (I prefer a current General Release (GR) bundle); and 'vgimport' your exported volumes. Your volume groups, logical volumes, filesystems and data therein will be present without the need to reload.

...JRF...
Bill McNAMARA_1
Honored Contributor

Re: fresh kernel with old filesystems?

this is actually something that has bothered me a couple of times here on the forum.
I also destroyed a few dclasses testing out a recovery (for the good of the community)
But, I think this could be a common enough problem.

For example, If I use the recovery CD to replace vmunix and then am all happy my system comes up.. I'm in a bit of trouble still.
I'm going to have to recall all the patches I installed and reinstall them (with force).
There should and must be a better way to do it?

Ie kmupdate or such?

Bill
It works for me (tm)
tech1214
Advisor

Re: fresh kernel with old filesystems?

The goal in our case is pretty esoteric.
We have a custom patch from HP that *must* be installed on a base of virgin 9911, but all the machines that need the patch are currently 9911 + a ton of patches. Thus custom patch will supersede all currently installed patches, so I am not too worried about the environment being disjoint from the kernel.

So, rather than blow away everything, and start from scratch, I would prefer to preserve as much stuff as possible - particularly local filesystems and licensed applications. Because of the pecularities of the environment here, gathering together all license codes for these machines has been a herculean effort in the past and I would prefer not to repeat it.

The vgexport and vgimport idea is a good one and should take care of local data, but may not cover us for the applications - can you vgimport / ?