oslevel != oslevel -r

[teqmem]

Hello,

I have a low-end AIX server which I had previously loaded with maintenance pack 4.3.3.10. When I run oslevel with and without the -r option, I recieve different results as shown below. Since oslevel only returns 4.3.1, this server is considered vulnerable and must be upgraded.

# oslevel
4.3.1.0
# oslevel -r
4330-10

I have used the following commands in the past to tell which
filesets need to be updated but no matter what level I use, the output is always blank.
instfix -ivk 4330-06_AIX_ML | grep not | grep ':'

How can I tell which filesets are causing the oslevel command to just return 4.3.1.0?

Thank you

 

[plamb]

have you tried lppchk -vm3

 

[teqmem]

I just tried "lppchk -vm3" but the output was blank.

 

[pko]

find this

[root@ ~]# instfix -i | grep ML
All filesets for 4.3.1.0_AIX_ML were found.
--> cut <--
...
--> cut <--
All filesets for 4330-06_AIX_ML were found.
Not all filesets for 4330-07_AIX_ML were found.
All filesets for 4330-08_AIX_ML were found.
All filesets for 4330-09_AIX_ML were found.
All filesets for 4330-10_AIX_ML were found.
All filesets for 4330-11_AIX_ML were found.

[root@ ~]# instfix -icqk 4330-07_AIX_ML | grep ":-:"
4330-07_AIX_ML:Java.rte.bin:1.1.8.10:1.1.8.8:-:AIX 4330-07 Update
4330-07_AIX_ML:Java.rte.classes:1.1.8.10:1.1.8.8:-:AIX 4330-07 Update
4330-07_AIX_ML:Java.rte.lib:1.1.8.10:1.1.8.8:-:AIX 4330-07 Update


palo

 

[hfaix]

What do you get from?

oslevel -rl 4330-10

 

[DukeSSD]

On a 4.3.3 system you should not have any BOS (base operating system) 4.3.1 file sets.
instfix -1 |grep 4.3.1
should identify the BOS file sets that were made redundant by 4.3.3, these are the ones that will be making oslevel think the AIX level is still 4.3.1 rather than 4.3.3, assuming you actually have all the required components of 4.3.3 installed.
The system was obviously upgraded from 4.3.1 to 4.3.3 at some point, if this upgrade was not totally successful (or was subsequently migrated to another system without the aid of the required installation media) the oslevel will still think the system is at 4.3.1 and although oslevel -r shows 4.3.3 ML10 that only means that of the 4.3.3 file sets installed, they are all at the ML10 level.
I suspect you only have some old hangover 4.3.1 file sets that never made it into 4.3.3.
The safe way to get over this is to do an upgrade or migration install to 4.3.3 MLxx and then upgrade from 4.3.3 MLxx to 4.3.3 ML10. The xx will be whatever 4.3.3 install media you have handy.
I suggest you then go to the IBM update site and download / install ML11 and the appropriate later file sets.

 

[teqmem]

oslevel -rl 4330-10" returned blank.

"instfix -1 |grep 4.3.1" - did you mean "instfix -i" as "-1" is not a valid argument.

I ran this "lslpp -L all | grep 4.3.1" and got the following. I suspect one or some of these are causing 'oslevel' to return 4.3.1. Do you agree? What's the easiest way to get these to version 4.3.3?

# lslpp -L all | grep 4.3.1
X11.Dt.helpmin 4.3.1.0 C AIX CDE Minimum Help Files
X11.msg.en_US.base.rte 4.3.1.0 C AIXwindows Runtime Env. Messages
4.3.1.0 C Docregister Common Messages -
bos.msg.en_US.txt.tfs 4.3.1.0 C Text Formatting Services
bos.rte.jfscomp 4.3.1.0 C JFS Compression
4.3.1.0 C Sample Service Processor Modem
4.3.1.25 C CHRP IEEE 1284 Parallel Port
4.3.1.0 C Standard Parallel Adapter

 

[teqmem]

These IMNSearch filesets seem to be the problem. But why are the maintenance levels different from the actual levels? I went to "Software Maintenance and Utilities" but didn't see any pending updates.

# oslevel -l 4.3.3.0
Fileset Actual Level Maintenance Level
-----------------------------------------------------------------------------
IMNSearch.rte.DBCS 1.1.3.0 1.2.3.1
IMNSearch.rte.SBCS 1.1.2.0 1.2.3.1

 

[teqmem]

I found that the IMNSearch.rte version 1.1 belong to 4.3.1 so had to simply load the 4.3.3 version from the second volume of the AIX 4.3.3 CDs. Now 'oslevel' returns '4.3.3.0'.

Thanks for all your suggestions.

 

[DukeSSD]

Sorry about the 1/l but I'm glad it all worked out.