/stand warning.

[James Ellis_1]

Yesterday I tried to load a group of patches, and one patch failed to load (because it was missing a certain fileset). So I aborted the whole install. The install of these patches would have to built a new kernel.

Today, I am getting error messages sent to my email saying this:

"Unix Filesystem /stand Critical"

When looking into /stand, I see that the /build directory has the date of Nov 15 being modified. Also, /stand is 100% full. But I aborted the install of the patches, so I figure maybe some of the kernel was partially rebuilt, until I aborted this. What or where do I look to clean out some of these files in the /stand/built or just /stand directory?

I am running a HPUX 11.0 server. Thanks, Jim

[Roger Baptiste · Accepted solution]

hi,

the kernel creation process creates temporary files under /stand/build . Since you aborted it midway, the files still exist.
Make sure your existing kernel is fine:
ll /stand/vmunix*
-> check the dates of the vmunix* files and
make sure nothing got changed recently

Same applies for /stand/system*

Then, you can remove the files under /stand/build

HTH
raj

[harry d brown jr]

How did you abort the install?

live free or die
harry

[Krishna Prasad]

The biggest file in /stand/build is usually vmunix_test. Removing or movinging it to a different directory should clear some space in /stand

[Michael Tully]

Hi,

Aborting a patch install may have left your system in an unstable state. Suggest you run
# swlist -l fileset -a state
to find which were loaded but not configured.
I hope you didn't try to install or re-install PHKL_18543

-Michael

[Darrell Allen]

Hi James,

Did you use command line swinstall? I generally use the graphical version. After analysis you have a chance to cancel the install. If you choose to continue you get one more chance to stop because it gives you a warning that continuing will build a kernel and the system will reboot. You should not interrupt swinstall after passing this point.

As Raj says, check the kernel (vmunix) to see if it was modified. If not, you should be okay to clean up /stand/build. However, you make have some patches that did get installed. You'll need to check what state they're in with swlist -l patch -a state. They need to be configured.

I hope you made a make_tape_recovery just before you started installing the patches. You may want to make one now also.

Darrell

[Darrell Allen]

Hi again,

vmunix_test is the one built by swinstall (verify the date/time stamp matches). It may not have been moved into place for the reboot since you aborted the install.

Darrell

[Santosh Nair_1]

I would think deleting the .o files under /stand/build would be okay. These are temporary object files that get generated as part of the kernel build process. Since they are temporary, they can be removed. The more important question is why the patch install failed. Since /stand is full, I suspect that played a role.

You should make sure that all the filesets are installed and configured. And finally, make sure you can generate a new kernel (cd /stand;mk_kernel) otherwise you WILL run into problems in the future with patches and kernel mods.

-Santosh

[Deshpande Prashant]

HI
It would be safe to delete the *.o and vmunix_test files in /stand/build directory.
Also as mentioned earlier by others check the states of patches installed on system, & if required configure them and build the kernel.

Thanks.
Prashant.

[James Ellis_1]

I did not abort the install. Since I was loading 4 patches, and one patch gave errors because of the filesets that were needed, I clicked the "abort" button. I was installing thru SAM. Does this mean I can go ahead and remove the files in /stand/build? I went back to the previous kernel and it seems to be working...but am still getting the message that /stand was full. Looking into /stand, the /build is indicating Nov 15 as the last change date. I'll await to hear from you all. Thanks. -Jim

[Darrell Allen]

Good! /stand/build is used exactly for what is sounds like: the directory where the new kernel is built before moving it into place. Sounds like you canceled swinstall after the analysis phase gave an error but before beginning the install phase.

Sounds like you may still have to address the size of /stand. You need to see what you can get out of there besides vmunix_test. Perhaps you could post the output from ll -R /stand.

Darrell