Question & Answer
Question
*This page will be update regularly in case new FAQs.
*The following applies to environments using encrypted NIMSH(secure) communication.
- What if I update my NIM master before updating all NIM clients ?
- Any considerations when updating the NIM master ?
- Is non-SSL encrypted communication impacted by the NIM changes ?
- How can I boot in to Maintenance Mode in case of boot failures during the transition to the new Service Pack ?
- What happens to a NIM client after it is updated ?
- How to update NIM clients via NIM in NIMSH(secure) mode ?
- Restoring mksysb backups ?
- Can older clients still work with secure NIM after it is updated to the 2633 build ?
- Does update order matter ?
- Other considerations ?
Answer
What happens if I update my NIM master before updating all NIM clients?
Push operations to clients that have not yet been updated may hang or fail. Ensure that NIMSH is stopped on older clients to avoid hangs. Once a client is updated to a compatible level, communication should be restored automatically.
What should I consider when updating the NIM master?
NIM updates are normally performed locally by using smitty update_all or the install_all_updates command.
The update may pause and prompt for a passphrase. To resume, simply press 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 NIM communication impacted by these changes?
No. Environments that do not use NIMSH (secure) will not experience the same interruptions. However, IBM still recommends updating to the latest Service Pack and switching to NIMSH (secure) to mitigate the vulnerabilities.
How can I boot into Maintenance Mode if a boot failure occurs during the transition to the new Service Pack?
This may be difficult during the transition period, but you can use one of the following workarounds:
- Build a temporary LPAR to serve as a NIM master at the updated level, and use it for Maintenance Mode boot and recovery work.
- Create a bootable ISO from an existing LPAR at the updated level by using the
mksysb_isocommand, and then boot it through the VIO VML. See mksysb_iso command. - Update your existing NIM master. Bear in mind that clients that have not yet been updated will then need to be updated without NIM.
What happens to a NIM client after it is updated?
An entry that runs nimclient -c is added to the /etc/firstboot file. When the client reboots, it attempts to share the new certificates with NIM by using the new method. If this fails—for example, because the NIM server has not yet been updated—a cron job is added automatically to retry certificate retrieval every minute.
The cron job is removed after communication with the updated NIM server has been established successfully.
The crontab entry can be removed if desired. In that case, you must run nimclient -c manually after the NIM master is updated.
Another option is to configure passwordless login for all NIM clients. This configuration can be deployed through a NIM script:
How can I update NIM clients through NIM in NIMSH (secure) mode?
The recommended method is to use alt_disk_copy. If that is not possible, update_all or Live Kernel Update can also be used, subject to the following considerations.
When the running rootvg is updated, the client is expected to lose communication with the NIM master after the NIM client fileset is updated and the NIM binaries are changed. This will not interrupt the update, but the operation may display a communication error at the end and exit with a non-zero return code, even though the update completed successfully.
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:The following error is expected when performing a Live Kernel Update through NIM:
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:Can I restore mksysb backups?
Restoring mksysb backups through NIM is possible only for backups at the same or a lower level and build date than the NIM master.
If the NIM master is updated, it will still be able to restore backups from older levels. However, NIMSH (secure) communication will start failing as soon as the restore completes. Post-restore customization is also unavailable for incompatible levels.
Can older clients still use secure NIM after the NIM master is updated to the 2633 build?
An iFix will not be available for older releases. As a workaround, however, the bos.sysmgt.nim.client fileset can be updated independently to the 2633 build level. This enables older clients to communicate with the NIM master by using the new encryption method.
This works for active streams: AIX 7.2 TL5 and AIX 7.3 TL2, TL3, and TL4.
Note: Some versions of the bos.sysmgt.nim.client fileset may run bosboot and report that a reboot is required. A reboot is not required to start using the new secure NIM method. You can ignore the warning and reboot when the rest of the system is updated.
Older clients in environments that do not use encryption will not be impacted.
The bos.sysmgt.nim.client fileset can be updated through NIM with:
# nim -o cust -a filesets=bos.sysmgt.nim.client -a lpp_source=<LPP> -a installp_flags="acYXN" <Target Client>Note: This process automatically updates bos.rte.install and bos.dsc.rte. To avoid that, we recommend creating an LPP source that contains only the bos.sysmgt.nim.client filesets.
The installation sequence should be:
- Update the
bos.sysmgt.nim.clientfileset on all active NIM clients. This adds a cron job that runsnimclient -cevery minute. Communication with the NIM master will be lost until the master is updated. - Update the NIM master to the 2633 build.
- Reboot the NIM master. At this point, all clients will exchange certificates with the NIM master. If all goes well, communication with all active clients will be restored.
After completing this process, you will be able to update your NIM clients at any time without becoming stuck in a transitional state in which communication with some clients does not work.
Other considerations
- When using NIM to apply the update to the running
rootvg, if the update or Live Update fails at any point, work must resume locally on the client LPAR. NIM communication will not work until the NIM master is updated. To obtain the UUID required for NIM registration, run:
# lsattr -El sys0 -a partition_uuid - partition_uuid 7a8be3b5-927a-48f6-ab2b-ded04f5ed4f3 Partition UUID False- To refresh the UAK key, see AIX Update Access Key.
Was this topic helpful?
Document Information
Modified date:
17 September 2026
UID
ibm17282482