ITEM: CG0144L

0516-044 error trying to import volume group

Env: R24 running 3.2.5.1

Desc: When customer attemped to create a LOGICAL VOLUME on his "ovus"
volume group, it would hang and eventually return a LV with a size of
0 LP's.

Customer to resolve issue by exporting and then importing the volume
group. Upon import, it gave the error:

0516-044 importvg: The write to internal map file failed. Confirm
        space is available under the filesystem directory /etc then
        execute varyonvg again.

Action: Customer has 2 4.5gig IBM disks (hdisk2 and hdisk3). Both
disks are part of a volume group called "novus".

On a normal sized volume group with AIX 3.2, there will be a map
file stored in /etc/vg that will be about 1meg in size.

In his case, he has 24meg of free space in the "/" filesystem,
so this should not be problem.

Further, the directory /etc/vg exists with the correct
permissions/ownership.

He cannot varyon the volume group. Currently, it is not imported.
"lsvg -o" does not show it.

I had him verify the PVID on the disk matched the ODM values. They
were fine.

I then checked the "varyonvg" command, and the permissions/ownership
were correct.

The /etc/vg file was there with the correct permissions.

He later said that an "extendlv" he was running on another volume
group was hanging. This would tend to indicate that the problem is
not specific to this volume group.

I attached "dbx" to it, and this is where it currently was.

 (dbx) where
 lvm_updtime(0x325d556d, 0x2833d000) at 0xd017948c
 lvm_diskio(0x325d556d, 0x2833d000) at 0xd017ac80
 rdex_proc(0x325d556d, 0x2833d000, 0x2ff7e614, 0x2f0b0, 0x0,
           0x40000000) at 0xd0181644
 lvm_extendlv(0x325d556d, 0x2833d000) at 0xd018388c
 main(0x325d556d, 0x2833d000) at 0x10000ba8

When I set the program to continue, I got this error.

 (dbx) cont

 file size limit exceeded in lvm_updtime at 0xd017948c
 0xd017948c (lvm_updtime+0x80) 7c7e45aa       stsi   r3,r30,0x8

Hmmm, sounds like a ULIMIT is involved somehow.

I did a quick check on the process from a kernel level with a system
trace. We are getting this error from a VMM section of the code:

 1BF VMM exception: sregval=0240 vaddr=301070EC
     persistent_storage deferred_update
     error=001B pid=254B

This error (0x001B) is errno 27 or EFBIG. The file is too big.

I checked the /etc/security/limits file. The file size limit is set
to 2048 for the default, and the root limit is set to -1.

This sure seems to be related to the overall problem, and would be
less than the 1meg file that the system requires for a VG map of this
size (a little over a meg).

I informed him of this, who agreed, and is setting the ulimit back to
a value in the 2gig area.

He rebooted, and this resolved the problem.

NextAction: Close call with customer agreement



Support Line: 0516-044 error trying to import volume group ITEM: CG0144L

Dated: October 1996 Category: N/A

This HTML file was generated 99/06/24~13:30:18

Comments or suggestions?
Contact us