Unable to save the base customized information on /dev/ipldevice using cfgmgr command on AIX


I am getting the following error when i run cfgmgr commands on aix 6.1, please assist.

# cfgmgr
cfgmgr: 0514-609 Unable to save the base customized information
        on /dev/ipldevice.

# ls -l /dev/ipldevice
crw-------    2 root     system       17,  0 May 10 18:42 /dev/ipldevice

rootvg is not mirrored and there are not stale pv's in rootvg
Who is Participating?
>> i mapped a lun from vio to the lpar via a script on nim<<

But this lun was not meant for rootvg, or was it?

What do you get with

lsvg -p rootvg


You could try to resynchronize the ODM and rootvg's  VGDA:

synclvodm rootvg

and to rewrite the boot image with

bosboot -a -d /dev/ipldevice

If this latter command fails but

bosboot -a -d hdisk0

works we have indeed a hardlink problem.

In this case try

rm /dev/ipldevice
ln -f /dev/rhdisk0 /dev/ipldevice

Any effect?



did you recently replace a disk in your rootvg?

Anyway, we'll have to determine what your actual boot device is and
whether /dev/ipldevice (which is a hard link) points to this disk.

So issue

ls -il /dev/ipldevice /dev/r$(bootinfo -b)

Now compare the major/minor numbers (columns 5 and 6, "17, 0" in your example) and the inode numbers (column 1) of the shown devices.

If they're not identical (which I assume) please post the output of the command I gave you. We will then try to correct this issue by recreating the "ipldevice" hardlink.

assistunixAuthor Commented:
no modification were made to any disks in rootvg.

the cfgmgr error occurred after i mapped a lun from vio to the lpar via a script on nim.
first cfgmgr command worked, whereas the second cfgmgr gave that error, so right now i have only one active path on the new disk.

 # ls -il /dev/ipldevice /dev/r$(bootinfo -b)
  304 crw-------    2 root     system       17,  0 May 10 18:42 /dev/ipldevice
  304 crw-------    2 root     system       17,  0 May 10 18:42 /dev/rhdisk0

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

assistunixAuthor Commented:
No, the disk was for non rootvg.

After performing the first two steps
synclvodm rootvg
bosboot -a -d /dev/ipldevice

cfgmgr worked, and resolved the issue, but do i still need to execute the following third command

bosboot -a -d hdisk0

it's fully equivalent to bosboot -a -d /dev/ipldevice

I only suggested using it in case the other command wouldn't work.

Glad to hear that it works now!

assistunixAuthor Commented:
ok. do you know if the combination of both commands fixed the issue or was it just one of them, from the following two commands that fixed the issue.

synclvodm rootvg
bosboot -a -d /dev/ipldevice
I assume that it's been synclvodm.

This utility

Synchronizes or rebuilds the logical volume control block, the device configuration database, and the volume group descriptor areas on the physical volumes.

There must have been some minor defect or out-of-sync condition which synclvodm was able to resolve.

Small chances are that the boot image on your IPL disk has become corrupted some way and bosboot fixed it, but I think that's rather improbable.

That said, the assumption that it's been the combination of both commands is far from likely.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.