Topic
  • 8 replies
  • Latest Post - ‏2012-11-29T20:09:49Z by SystemAdmin
lapfrank
lapfrank
11 Posts

Pinned topic mksysb on NIM - TL versions

‏2010-12-07T14:31:27Z |
Hello All,

This is my first time posting on this forum, but it has been helpful to me a lot in the past!

My question is about mksysb/NIM and the version of the os (oslevel_r) shown in the lsnim -l command. For example:

lsnim -l mksysb-server1
mksysb-server1:
class = resources
type = mksysb
Rstate = ready for use
prev_state = unavailable for use
location = /images/bcbsri/mksysb-acereplica
version = 5
release = 3
mod = 11
bold oslevel_r = 5300-11
alloc_count = 1
server = master

Whenever I update one of my servers to a new TL, even though I generate my mksysb weekly with the -i option, the oslevel_r shown with the lsnim -l command will always stay the same. For now, the only way I could get it to update is by removing the mksysb (nim -o remove) and then re-defining it.

I've been doing AIX for a couple of months only.. so I might have missed something.

This is not really causing me a problem, but it throws an error everytime I refresh my partitions at my DR site:

warning: 0042-229 m_bos_inst: When installing a system using a mksysb as the
source for the installation, the level of the SPOT used for the
installation must match the level of the mksysb image that is
being installed. The release levels of the SPOT, 530907, and the
mksysb, mksysb-lgrsprd1, do not match.

Thank you very much!

Francois
Updated on 2012-11-29T20:09:49Z at 2012-11-29T20:09:49Z by SystemAdmin
  • tech100
    tech100
    109 Posts

    Re: mksysb on NIM - TL versions

    ‏2010-12-07T18:40:07Z  
    I am not such familiar with NIM but what would you see after running:

    nim -Fo check mksysb-server1

    (of course after your mksysb resource has newer TL mksysb image put on disk)
  • lapfrank
    lapfrank
    11 Posts

    Re: mksysb on NIM - TL versions

    ‏2010-12-07T19:04:47Z  
    • tech100
    • ‏2010-12-07T18:40:07Z
    I am not such familiar with NIM but what would you see after running:

    nim -Fo check mksysb-server1

    (of course after your mksysb resource has newer TL mksysb image put on disk)
    Thanks! Just tried, and it's not a supported operation for mksysbs.

    0042-025 nim: the "check" operation cannot be applied to
    "mksysb" types

    nim:/images/mksysb$ lsnim -POt mksysb
    mksysb:
    remove = remove an object
    define = define an object
    change = change an object's attributes
    showres = show contents of a resource

    I tried showres, it won't update the oslevel_r, even though it lists the correct filesets version.
  • tech100
    tech100
    109 Posts

    Re: mksysb on NIM - TL versions

    ‏2010-12-07T20:16:49Z  
    I've googled a bit and found some APAR for some problem which gives some command which can be used to change the attribute...

    http://www-01.ibm.com/support/docview.wss?uid=isg1IY44189

    Example:
    /usr/lpp/bos.sysmgt/nim/methods/m_chattr -a oslevel_r=5300-11 mksysb_nim_resource_name
  • Siddhartha.Sinha
    Siddhartha.Sinha
    25 Posts

    Re: mksysb on NIM - TL versions

    ‏2010-12-07T21:18:45Z  
    • tech100
    • ‏2010-12-07T20:16:49Z
    I've googled a bit and found some APAR for some problem which gives some command which can be used to change the attribute...

    http://www-01.ibm.com/support/docview.wss?uid=isg1IY44189

    Example:
    /usr/lpp/bos.sysmgt/nim/methods/m_chattr -a oslevel_r=5300-11 mksysb_nim_resource_name
    lsnim -l will show only the TL level. It will not show any SP level. You can check with this command if you have any broken fileset. run lppchk -v on the server and if any broken fileset is there you need to fix that. There is another command. instfix -i |grep -i ml and note down which TL level has issue. Then this command will tell which is actually have issue
    Ex. instfix -ciqk 6100-06_AIX_ML|grep ":-:"

    I couldn't find the exact fileset which has issue with the lppchk -v command. Few days ago I upgraded to AIX 7 from AIX 6 and lppchk -v was showing error. After checking lot of filesets I found that sdd software was causing that issue.
  • SystemAdmin
    SystemAdmin
    6902 Posts

    Re: mksysb on NIM - TL versions

    ‏2010-12-08T06:26:19Z  
    Hi,

    The NIM server must always be at the highest AIX level (including technology levels and service packs) or at the same level than any other client. Before upgrading any client, upgrade your nim server first then your client.
  • lapfrank
    lapfrank
    11 Posts

    Re: mksysb on NIM - TL versions

    ‏2010-12-08T14:06:05Z  
    Hi,

    The NIM server must always be at the highest AIX level (including technology levels and service packs) or at the same level than any other client. Before upgrading any client, upgrade your nim server first then your client.
    Tech100: thanks for the search, but it doesn't apply to me. All my nim definitions were made in AIX 5.3.

    Siddhartha.Sinha: I did check all my levels (instfix, lppchk, etc.) and everything is OK.

    Like I said, it's only the reported oslevel_r in the lsnim -l command that doesn't seem to get updated. Whenever I delete the mksysb ressource and define it again, it does pick up the correct version and then, if I use it to build a partition, it doesn't give any errors.

    Ajay Singh: The NIM server is already at the highest level of any one of my partitions.
  • Siddhartha.Sinha
    Siddhartha.Sinha
    25 Posts

    Re: mksysb on NIM - TL versions

    ‏2010-12-10T05:03:50Z  
    Sorry, I didn't read you original post carefully. Did u upgraded the spots every time you update the lpp_source ? If not then then your lpp_source will be higher than spot. You can either remove the spot and re-create or simply update it using the following example using the updated lpp_source. Check my website www.sinhass.com aix page for more nim related information

    nim -o cust -F -a lpp_source=530TL12SP2lpp -a fixes=update_all 530TL12SP2spot
  • SystemAdmin
    SystemAdmin
    6902 Posts

    Re: mksysb on NIM - TL versions

    ‏2012-11-29T20:09:49Z  
    I believe that the scenario the original poster is trying is as follows:

    1.) create mksysb file for NIM client. Let's assume that this is done from the command line rather than through NIM.
    2.) copy mksysb file to the NIM server and create a mksysb resource using the mksysb file.
    3.) update the NIM client. It shouldn't matter if the upgrade is done through NIM or not.
    4.) create new mksysb file for NIM client from command line and NOT through NIM.
    5.) copy new mksysb file to the NIM server and keep the same file name used in step 2.

    The situation now is that lsnim -l will show the oslevel_r from step 1 but the actual mksysb file will have an updated oslevel_r.

    The challenge is to get the nim resource to contain the updated information. This could be done simply by removing the resouce and recreating the resource. The question becomes "is there a better way?".