?
Solved

AIX TL upgrade issue

Posted on 2014-10-02
5
Medium Priority
?
1,306 Views
Last Modified: 2014-10-04
I have upgraded an AIX server from 6100-09-02 to 6100-09-03, The procedure I followed was to mount all the upgraded file sets on a NFS share and ran a "smitty update_all" command, When I have run this command for the first time, AIX was not updated from 6100-09-02 to 6100-09-03, but it went back to a older level, I had to run "smitty update_all" again and then I was able to see my desired level, WHY DID THIS HAPPEN....

Also when it failed, I ran the below command
# oslevel -sl 6100-09-03-1415
csc08tsm09:
Fileset                                 Actual Level       Service Pack Level
-----------------------------------------------------------------------------
bos.perf.pmaix                          6.1.9.0            6.1.9.15

Thanks,
0
Comment
Question by:Ramu Shetty
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
5 Comments
 
LVL 4

Expert Comment

by:popesy
ID: 40358889
Hi

One reason this can happen is to do with the date that some filesets are released.

In my situation, I was upgrading from 5300-11-05-1036 (week 36 of 2010) to 5300-12-00-1015 (week 15 of 2010) but because the version I was updating to was older than the previous version my update failed.

Compare the date of the released file sets, if this is older than the installed version then my understanding is that AIX won't update to an 'older' version.

Cheers, JP.
0
 
LVL 10

Expert Comment

by:Carlos Ijalba
ID: 40359067
Review the smit.log file (/smit.log or /home/user_id/smit.log), to see exactly what happened.

Did you reboot the server after running the TL upgrade? some TL's require a reboot since it replaces some kernel filesets.
0
 

Author Comment

by:Ramu Shetty
ID: 40359516
I dont think its the date of release, I am going from 6100-09-02-1412 to 6100-09-03-1415, So going from filesets from 12th week to 15th week.

also

Reboot comes later, As soon after we run the updates in applied state, if we run a "oslevel -s" it will show the desired OSLEVEL, So this issue is before the reboot, for your reference this is what is in the smitty log..

Requisites
  ----------
  (being installed automatically;  required by filesets listed above)
  bos.perf.pmaix 6.1.9.0                      # Performance Management

I also found out that it gave me some warnings..

WARNINGS
--------
  Problems described in this section are not likely to be the source of any
  immediate or serious failures, but further actions may be necessary or
  desired.

  Conflicting Versions of Filesets
  --------------------------------
  The following filesets are conflicting versions of filesets for which there
  are multiple versions on the installation media.  Since a specific version
  was not selected, the newest installable version has been selected.

    perl.rte 5.8.8.366                        # Perl Version 5 Runtime Envir...
    infocenter.man.EN_US.commands 6.1.9.0     # AIX manual commands - U.S. E...
    bos.help.msg.en_US.smit 6.1.9.0           # SMIT Context Helps - U.S. En...


I even tried if any dependent filesets were a issue but could not find anything
0
 

Author Comment

by:Ramu Shetty
ID: 40359546
I also found out that while installing this fileset, The smitty log had this info..

sysck: 3001-036 WARNING:  File
        /var/perf/pm/bin/shrpoolinfo
        is also owned by fileset bos.perf.tools.
sysck: 3001-036 WARNING:  File
        /var/perf/pm/bin/crosslpar
        is also owned by fileset bos.perf.tools.
sysck: 3001-036 WARNING:  File
        /var/perf/pm/bin/pmcfg_ext
        is also owned by fileset bos.perf.tools

When I listed the dependent filesets I see the following..

 Fileset               Dependents
  ----------------------------------------------------------------------------
<Fileset> is a requisite of <Dependents>
Path: /usr/lib/objrepos
  bos.perf.pmaix 6.1.9.0
                        bos.perf.tools 6.1.9.15
                        bos.perf.pmaix 6.1.9.15

Path: /etc/objrepos
  bos.perf.pmaix 6.1.9.0
                        bos.perf.tools 6.1.9.15
                        bos.perf.pmaix 6.1.9.15
0
 
LVL 68

Accepted Solution

by:
woolmilkporc earned 2000 total points
ID: 40361150
"bos.perf.pmaix" was new with AIX  6.1.9.0 (inital release).

It looks as if the basic version 6.1.9.0 wasn't yet installed in your 6.1.9.2, instead it was going to be newly and automatically installed with 6.1.9.3 because it became a prerequisite for another already installed fileset (bos.perf.tools), see the part of the log you posted:

Requisites
  ----------
  (being installed automatically;  required by filesets listed above)
  bos.perf.pmaix 6.1.9.0                      # Performance Management


A bit above in the log you could maybe find more info about the fileset "bos.perf.tools" which now needs "bos.perf.pmaix".

Now a base level fileset and an update fileset cannot be installed in the same run. That's why you just got 6.1.9.0 after the first attempt and had to repeat "update_all" to get the  updated version.

The "sysck" messages are quite normal and thus nothing to worry about. The same is true for the "Conflicting Versions" messages.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Attention: This article will no longer be maintained. If you have any questions, please feel free to mail me. jgh@FreeBSD.org Please see http://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-update-server/ for the updated article. It is avail…
When you do backups in the Solaris Operating System, the file system must be inactive. Otherwise, the output may be inconsistent. A file system is inactive when it's unmounted or it's write-locked by the operating system. Although the fssnap utility…
Learn how to find files with the shell using the find and locate commands. Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:
This video shows how to set up a shell script to accept a positional parameter when called, pass that to a SQL script, accept the output from the statement back and then manipulate it in the Shell.
Suggested Courses
Course of the Month9 days, 4 hours left to enroll

764 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question