AIX 7.2 requires 2GB of memory to boot, but this minimum is not enforced in the LPAR profile except by Live Update (to ensure we'll be able to boot the surrogate LPAR). You can check your Minimum Memory setting in your LPARs profile by running the lparstat command (as shown below).

 

# lparstat -i | grep Memory
Online Memory                              : 4096 MB
Maximum Memory                             : 8192 MB
Minimum Memory                             : 2048 MB

 

If your partition does not meet the minimum memory profile requirement, you’ll receive the following error message when you perform a live update preview (with geninstall –p –k).

 

Checking lpar minimal memory size:

------------------------------------------

Required memory size: 2048 MB

Current memory size: 1024 MB

1430-119 FAILED: the lpar minimal memory size is not sufficient

 

You’ll need to change partition profile so that the minimum memory setting is, at least, 2048 (2GB) and then stop & start the partition for the profile update to take effect.

 

The /var/adm/ras/liveupdate/logs/lvupdlog log file will also contain error messages indicating the problem:

 

LVUPD 11/28/2016-18:52:00.716 DEBUG lvupdate_utils32.c - 6713 - lvup_check_minmem_size: Partition minimum memory size (1024 MB) on p8tlc-lvup is lower than the minimum memory size required (2048 MB).

 

LVUPD 11/28/2016-18:52:00.716 ERROR lvupdate_utils32.c - 8647 - lvup_preview: ERROR(s) while checking the current mimimal memory size against the computed required size.

 

 

 

 

Prior to AIX 5.3 TL7 and AIX 6.1, there was an 8 character limit on AIX user passwords. If you need passwords of greater than 8 characters then you must enable one of the supplied Loadable Password Algorithms (LPAs). The following table lists the available algorithms and the limitations of each:

 

 

For example, to enable the MD5 algorithm I can modify /etc/security/login.cfg file with the chsec command as follows:

 

# chsec -f /etc/security/login.cfg -s usw -a pwd_algorithm=smd5

 

# tail -2 /etc/security/login.cfg

        pwd_algorithm = smd5

 

This algorithm (smd5) will allow a password limit of 255 characters. Each of the available algorithms is listed in the /etc/security/pwdalg.cfg file.

 

# head -50  /etc/security/pwdalg.cfg

*******************************************************************************

*

* Loadable Password Algorithm (LPA)

*

* The format of a LPA stanza is:

*

* lpa:

*       lpa_module = /any/program

*       lpa_options = options_list

*

* lpa           Corresponds to a password hashing algorithm that can be

*               specified in the "usw" stanza of /etc/security/login.cfg

*               as the system-wide password hashing algorithm.

*

* lpa_module    Specifies the path of the password hashing load module.

*               In the above example, /any/program is the path to the load

*               module that is used to do the password hashing in 32 bit

*               mode. The load module that is used to run in 64 bit mode

*               is /any/program_64.

*

* lpa_options   Is an optional attribute that provides a means of

*               communicating run-time configuration options to the load

*               module. The value is a comma separated list of items.

*               Please refer to the documentation for the load module for

*               appropriate values.

*

*******************************************************************************

*

* /usr/lib/security/smd5 is a password hashing load module using

* the MD5 algorithm.

*

* It supports password length up to 255 characters.

*

* To generate smd5 password hash compatible to standard salted MD5,

* add the following option line for smd5 stanza.

*       lpa_options = std_hash=true

*

* Note : password hash generated with this option won't be compatible with

* hash generated without this option.

*

*******************************************************************************

smd5:

        lpa_module = /usr/lib/security/smd5

 

*******************************************************************************

*

* /usr/lib/security/ssha is a password hashing load module using SHA and

* SHA2 algorithms. It supports password length up to 255 characters.

*

* This LPA accepts three options. The options are separated by commas.

...etc...

 

 

Once you’ve enabled the LPA of your choice, and you set/change a users’ password, you’ll notice that the /etc/security/passwd stanza for that user will look different when compared to the stanzas of users that have not had their password set/changed using the new LPA:

 

fred:

        password = E7nOaTrrz9Q16

        lastupdate = 1330986703

        flags = ADMCHG

 

joe:

        password = {smd5}z9JrHDJB$Oq/cZXr0jUyAWvfFyjt161

        lastupdate = 1330987903

        flags = ADMCHG

 

 

 

In the example above, user joe’s password has been set using the smd5 algorithm.

 

For those of you who run PowerHA (HACMP) and are thinking about using one of the LPAs with the clpasswd utility, you may want to review this APAR first:

 

IZ40362: HACMP PASSWD UTILITY FAILS WHEN LONG PASSWD ALGORITHM IS ENABLED

https://www-304.ibm.com/support/docview.wss?uid=isg1IZ40362

 

The APAR states “HACMP cluster-wide C-SPOC password administration does not support use of the feature allowing passwords longer than 8 characters which became available with the Loadable Password Algorithm as part of AIX 53 TL 7.”

 

The last time I tested this with PowerHA, the problem was that the password entry in /etc/security/passwd was corrupted/truncated when a users password was changed using the clpasswd utility.

 

For example, if the passwd utility is linked to clpasswd and I changed a users password, the password field appeared to be corrupted/truncated and the user could not log in successfully:

 

# ls -l /usr/bin/passwd

lrwxrwxrwx   1 root     system           39 Dec 22 11:30 /usr/bin/passwd -> /usr/es/sbin/cluster/utilities/clpasswd

 

# passwd tom

Changing password for "tom"

tom's New password:

Enter the new password again:

 

# grep -p tom passwd

tom:

        password = {smd5}FU2MWa.N.

        lastupdate = 1229910298

        flags =

 

 

Login no good!

tom@aix16's password:

Access denied

 

But if we use the original passwd command (stored in /usr/es/sbin/cluster/etc/clpasswd), the users password is changed successfully and the user can log in OK.

 

root@aix16 /usr/es/sbin/cluster/etc/clpasswd # ./usr_bin_passwd.orig tom

Changing password for "tom"

tom's New password:

Enter the new password again:

 

root@aix16 /usr/es/sbin/cluster/etc/clpasswd # grep -p tom /etc/security/passwd

tom:

        password = {smd5}PcBK/5QW$RE09Q0xz4TGQFp98KjxSs.

        lastupdate = 1229910818

        flags =                   ADMCHG

 

Login OK!

$ id

uid=10003(tom) gid=1(staff)

 

usr_bin_passwd.orig  password = {smd5}HcMHTTu3$BWkU8JVCWgT8szAN8TGCF1

clpasswd             password = {smd5}6z61fiIn/070

 

I’ve not tried this again recently but I am curious if the same behaviour can be expected on a PowerHA system today. When I first encountered this problem (in 2008) I opened a PMR for the issue. In that call I was told that the “clpasswd utility is corrupting the encrypted password when distributing to the nodes, so that a login fails”. I’ll configure a HA cluster soon and try it again with PowerHA 6.1 and AIX 6.1 and report back with the results.

 

UPDATE: I built a HA 6.1 cluster (on AIX 6.1) this afternoon in my lab and tested this successfully. Based on the tests I’ve performed so far, it appears that this limitation no longer exists. Thanks to hafeedbk@us.ibm.com for the help on this one.

 

The following IBM tech note has more information on the available Loadable Password Algorithms and support for longer than 8 character passwords on AIX:

 

AIX support for passwords greater than 8 characters

http://www-01.ibm.com/support/docview.wss?rs=111&context=SWG10&q1=pwd_algorithm&uid=isg3T1010741&loc=en_US&cs=utf-8&lang=en

 

 

It’s no secret that I like NIM. I’ve written about NIM on several occasions, in Redbooks, technical articles and on my blog. It’s a great tool for installing and maintaining AIX. Occasionally though, it can throw you an unusual error or two when things go wrong. For the uninitiated resolving these errors can be challenging.

 

Here’s a couple of NIM related questions I received recently. Both are troubleshooting queries.

 

“I'm getting the following error when trying to create a NIM lpp_source for AIX 6.1”:

 

                               Define a Resource

 

Type or select values in entry fields.

Press Enter AFTER making all desired changes.

 

                                                        [Entry Fields]

* Resource Name                               [6100-06_lpp]

* Resource Type                                lpp_source

* Server of Resource                          [master]                +

* Location of Resource                        [/export/eznim]          /

  NFS Client Security Method                  []                      +

  NFS Version Access                          []                      +

  Architecture of Resource                    []                      +

  Source of Install Images                    [/dev/cd0]              +/

  Names of Option Packages                    []

  Show Progress                               [yes]                   +

  Comments                                    []

 

...

Preparing to copy install images (this will take several minutes)...

 

0042-001 nim: processing error encountered on "master":

   0042-081 m_mk_lpp_source: a resource already exists on "master" at

location "/export/eznim/bid_ow"; due to NFS export restrictions, the

        new location "/export/eznim" may not be used

...

 

I could see what could be causing the issue but I first asked to see the contents of the /etc/exports file. Just to make sure that /export/eznim was not explicitly exported. It wasn’t.

 

# grep eznim /etc/exports

/export/eznim/vios/mksysb_image -ro,root=vio1,access=vio1

/export/eznim/bid_ow -ro,root=nim1,access=nim1

 

I suggested they re-try the operation again but this time specify the full path to the lpp_source directory, like so:

 

                               Define a Resource

 

Type or select values in entry fields.

Press Enter AFTER making all desired changes.

 

                                                        [Entry Fields]

* Resource Name                               [6100-06_lpp]

* Resource Type                                lpp_source

* Server of Resource                          [master]                +

* Location of Resource                        [/export/eznim/6100-06_lpp]          /

  NFS Client Security Method                  []                      +

  NFS Version Access                          []                      +

  Architecture of Resource                    []                      +

  Source of Install Images                    [/dev/cd0]              +/

  Names of Option Packages                    []

  Show Progress                               [yes]                   +

  Comments                                    []

 

This worked fine. And the lpp_source was created successfully.

 

#  lsnim -l 6100-06_lpp

6100-06_lpp:

   class       = resources

   type        = lpp_source

   locked      = 26738726

   Rstate      = unavailable for use

   prev_state  =

   location    = /export/eznim/6100-06_lpp

   alloc_count = 0

   server      = master

 

The second issue related to down-level filesets after an AIX 6.1 migration with nimadm.  There was also an issue with disk space that generated an error during NIM operations.

 

“Hi Chris,

 

Thanks for replying back to my post. I am a newbie to AIX/pSeries world.

I was following your document on upgrading AIX 5.3 to 6.1 using nimadm, it seemed to have worked partially for me, as I got to AIX 6100-00-00. The mksysb and the SPOT I created were for AIX 6100-06-05.

 

Before I re-attempt the upgrade, is there anything I need to be clean up on AIX 5.3 side that could have perhaps caused issues with the upgrade.

 

Thanks”

 

I recommended that the following command be run on the NIM client, to determine which filesets were down-level after the migration.

 

# oslevel -s

# instfix -i | grep AIX

# instfix -i | grep SP

 

If the output contained messages like "Not all filesets for 6100-06_AIX_ML were found", or something similar, then they should run the following command against each line (there could be more than one).

 

# instfix -icqk 6100-06_AIX_ML | grep ":-:"

 

This will tell you which filesets were not updated.

 

The output from ‘oslevel –s’and ‘instfix –i | grep AIX’ looked OK.

 

# oslevel -s

6100-06-04-1112

 

# instfix -i | grep AIX

    All filesets for 6100-00_AIX_ML were found.

    All filesets for 6100-01_AIX_ML were found.

    All filesets for 6100-02_AIX_ML were found.

    All filesets for 6100-03_AIX_ML were found.

    All filesets for 6100-04_AIX_ML were found.

    All filesets for 6100-05_AIX_ML were found.

    All filesets for 6100-06_AIX_ML were found.

 

But the output from ‘instfix –i  | grep SP’ indicated an issue with 61-06-051115_SP.

 

# instfix -i | grep SP

    All filesets for 61-00-010748_SP were found.

    All filesets for 61-00-020750_SP were found.

    All filesets for 61-00-030808_SP were found.

    All filesets for 61-00-040815_SP were found.

    All filesets for 61-01-010823_SP were found.

    All filesets for 61-00-050822_SP were found.

    All filesets for 61-00-060834_SP were found.

    All filesets for 61-01-020834_SP were found.

    All filesets for 61-00-070846_SP were found.

    All filesets for 61-01-030846_SP were found.

    All filesets for 61-02-010847_SP were found.

    All filesets for 61-02-020849_SP were found.

    All filesets for 61-00-080909_SP were found.

    All filesets for 61-01-040909_SP were found.

    All filesets for 61-02-030909_SP were found.

    All filesets for 61-03-010921_SP were found.

    All filesets for 61-00-090920_SP were found.

    All filesets for 61-01-050920_SP were found.

    All filesets for 61-02-040920_SP were found.

    All filesets for 61-00-100939_SP were found.

    All filesets for 61-01-060939_SP were found.

    All filesets for 61-02-050939_SP were found.

    All filesets for 61-03-020939_SP were found.

    All filesets for 61-04-010944_SP were found.

    All filesets for 61-04-021007_SP were found.

    All filesets for 61-04-031009_SP were found.

    All filesets for 61-00-110943_SP were found.

    All filesets for 61-01-081014_SP were found.

    All filesets for 61-02-060943_SP were found.

    All filesets for 61-03-030943_SP were found.

    All filesets for 61-03-041014_SP were found.

    All filesets for 61-04-041014_SP were found.

    All filesets for 61-05-011016_SP were found.

    All filesets for 61-01-091015_SP were found.

    All filesets for 61-02-081015_SP were found.

    All filesets for 61-03-051015_SP were found.

    All filesets for 61-04-051015_SP were found.

    All filesets for 61-01-070943_SP were found.

    All filesets for 61-02-071014_SP were found.

    All filesets for 61-02-091034_SP were found.

    All filesets for 61-03-061034_SP were found.

    All filesets for 61-04-061034_SP were found.

    All filesets for 61-05-021034_SP were found.

    All filesets for 61-06-011043_SP were found.

    All filesets for 61-02-101036_SP were found.

    All filesets for 61-03-071036_SP were found.

    All filesets for 61-04-071036_SP were found.

    All filesets for 61-05-031036_SP were found.

    All filesets for 61-06-021044_SP were found.

    All filesets for 61-06-031048_SP were found.

    All filesets for 61-05-041048_SP were found.

    All filesets for 61-04-081048_SP were found.

    All filesets for 61-03-081048_SP were found.

    All filesets for 61-03-091112_SP were found.

    All filesets for 61-04-091112_SP were found.

    All filesets for 61-05-051112_SP were found.

    All filesets for 61-06-041112_SP were found.

    Not all filesets for 61-06-051115_SP were found.

 

The culprit was the csm.hc_utils fileset from TL6 SP5. It was still at level 1.7.1.0 instead of the expected 1.7.1.1.

 

# instfix -ciqk "61-06-051115_SP" |grep ":-:"

61-06-051115_SP:csm.hc_utils:1.7.1.1:1.7.1.0:-:AIX 6100-06-05 Service Pack

 

I recommended that the csm.hc_utils 1.7.1.1 fileset be added to the AIX 6.1 lpp_source. The migration was attempted again and the client migrated to AIX 6.1 TLP6 SP5 successfully.  I also suggested they determine if this fileset was really used and/or needed (CSM is no longer supported/available starting with AIX 7.1 anyway).

 

And just when I thought all his problems were resolved, he replied with: “however upon trying to install these from the NIM server, I get errors on NIM”.

 

*********************************************************

errors:

0042-001 nim: processing error encountered on "master":                |

 |      0042-001 m_showres: processing error encountered on "master":       |

 |      0042-185 c_ch_nfsexp: Failed to link or copy /etc/.tmp.nim.exports. |

 |   12451894 to /etc/exports                                               |

 |           Check permissions and filesystem space

*********************************************************

 

Fortunately a quick look at the output from the df command highlighted the problem immediately.

He was out of space in the root file system. The very place that /etc/exports, and the NIM database (/etc/objrepos), reside.

 

# df -g

Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on

/dev/hd4           2.50      0.00  100%     3388     1% /

/dev/hd2           4.50      1.74   62%    42150     4% /usr

/dev/hd9var        1.00      0.52   48%     3262     2% /var

/dev/hd3           4.00      3.84    5%       74     1% /tmp

/dev/hd1           0.50      0.37   27%      479     1% /home

/proc                 -         -    -         -     -  /proc

/dev/hd10opt       0.75      0.21   73%     5698     3% /opt

/dev/livedump      0.25      0.24    4%       17     1% /var/adm/ras/livedump

/dev/exportlv    136.25    124.03    9%    20128     1% /export

 

After cleaning up unwanted files in / and making sure there was plenty of free space, the error no longer appeared in future NIM operations.