August 2026 AIX/VIOS Service Pack NIM FAQ

Answer

What if I update my NIM master before updating all NIM clients ?

Push operations to non-updated clients may hang or fail, ensure that NIMSH is stopped on older clients to avoid hangs. Once the client is updated to a compatible level, communication should be restored automatically. 

Any considerations when updating the NIM master ?

Updating NIM is naturally done locally with "smitty update_all" or "install_all_updates" command. 

The update may pause while prompting for user input to enter passphrase, to resume just hit ENTER:

 installp:  APPLYING software for:
        bos.sysmgt.nim.client 7.3.4.2


. . . . . << Copyright notice for bos.sysmgt >> . . . . . . .
 Licensed Materials - Property of IBM

 5765CD300
   Copyright International Business Machines Corp. 1993, 2026.

 All rights reserved.
 US Government Users Restricted Rights - Use, duplication or disclosure
 restricted by GSA ADP Schedule Contract with IBM Corp.
. . . . . << End of copyright notice for bos.sysmgt >>. . . . 

0518-307 odmdelete: 1 objects deleted.
0518-307 odmdelete: 1 objects deleted.
0518-307 odmdelete: 1 objects deleted.
Enter PEM pass phrase:

Is non-SSL encrypted communication impacted by the NIM changes ?

NO, environments that do not use NIMSH(secure) will not experience the same interruptions, however IBM still recommends to update to the latest Service Pack and switch to NIMSH(secure) in order to mitigate the vulnerabilities. 

How can I boot in to Maintenance Mode in case of boot failures during the transition to the new Service Pack ?

During the transition period this may be tricky, but the following workarounds can be used: 
A. Build a temporary LPAR as NIM at the updated level and use it for maintenance mode boot and recovery work. 
B. Create a bootable ISO from an existing LPAR at the updated level using the “mksysb_iso” command and boot via VIO VML: https://www.ibm.com/docs/en/aix/7.3.0?topic=m-mksysb-iso-command
C. Update your existing NIM master having mind that the rest of the clients that are not updated yet will need to be updated without NIM. 

What happens to a NIM client after it is updated ?

An entry that runs "nimclient -c" is added in the /etc/firstboot file, at reboot the client will try to share the new certificates with NIM using the new method, if that fails, for example because the NIM server is not updated yet, a cron job will be automatically added that will try to get the certificates every minute. 
This job is removed after successful communication is established with the NIM server when it is updated. 

If you want, the crontab entry can be removed. In this case manual run of "nimclient -c" is required when the NIM master is updated. 
Another option can be to create passwordless login to all NIM clients, this can be rolled out via NIM script. 
Refer to NIM script: https://www.ibm.com/docs/en/aix/7.3.0?topic=resources-using-script-resource
And creating ssh key for login: https://www.ibm.com/support/pages/ibm-aix-configure-openssh-user-passwordless-login

 How to update NIM clients via NIM in NIMSH(secure) mode ?

The recommended method is using alt_disk_copy, however if that is not possible, using update_all or Live Kernel Update are also possible with considerations. 
When updating the running rootvg, it is expected for the client to loose communication with the NIM master after the NIM client file set is updated and the NIM binaries are changed. While this will not interrupt the update,  the operation may display a communication error at the end and exit with non 0 return, even tho the update was successful. 
NIM update_all error: 

0042-001 nim: processing error encountered on "master":
   0042-001 m_cust: processing error encountered on "instlab227":
   0042-175 c_script: An unexpected result was returned by the
        "instlab224.aus.stglabs.ibm.com:/export/nim/scripts/instlab227.script" command:

For Live Kernel Update via NIM the following error is expected: 
 

08/10/2026-10:41:23     Live AIX update completed in 0h 8m 2s.

File /etc/filesystems has been modified.
File /etc/inittab has been modified.
File /sbin/rc.boot has been modified.

One or more of the files listed in /etc/check_config.files have changed.
        See /var/adm/ras/config.diff for details.
0042-001 nim: processing error encountered on "master":
   Unable to load client private key: The system call does not exist on this system.
00000001:error:05800074:x509 certificate routines:(unknown function):key values mismatch:crypto/x509/x509_cmp.c:403:

Restoring mksysb backups ?

Restoring mksysb backups via NIM is only possible for backups at the same or lower level and build date than the NIM master. 
If the NIM master is updated, it will be able to restore backups for older levels, however NIMSH(secure) communication will start failing as soon as the restore completes. Post restore customization is also not possible for non compatible levels. 
 

Can older clients still work with secure NIM after it is updated to the 2633 build ? 

An iFix will not be available for older releases, however as a workaround the "bos.sysmgt.nim.client" file set can be updated on its own to the 2633 build level and this will enable older clients to work with your NIM master using the new encryption method. 
**This works for active steams ( 72 TL5 and 73 TL2/3/4 ) . 
***Note that some version of the nim.client file set may run bosboot and state that reboot is required. Reboot is not required to start using the new secure NIM method, you can ignore the warning message and reboot when the rest of the system is updated. 

Other considerations ?

• When using NIM to apply the update to the running rootvg, In case the update fails or Live Update fails at any point, work must resume locally on the client LPAR as NIM communication will not work until the NIM master is updated. 
• How to get the UUID needed for NIM registration: 

# lsattr -El sys0 -a partition_uuid
-	partition_uuid 7a8be3b5-927a-48f6-ab2b-ded04f5ed4f3 Partition UUID False

• How to refresh my UAK key: https://www.ibm.com/docs/en/aix/7.3.0?topic=system-aix-update-access-key