Originally posted by: tech100

why update of this fileset takes so long (more than 10 minutes so 1 of 420 steps consumes ca. 30% time of whole update)? anyone observed similar thing? this is quite new P7 server with no cpu/io performances issues. is something blocking / timeouting this fielset update and can be fixed?

 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 sysmgt.cimserver.pegasus >>. . . .

Restoring CIM Schemas...
Creating the cimserver repository...
Filesets processed:  345 of 420  (Total time:  19 mins 46 secs).

installp: APPLYING software for:
        sysmgt.cim.providers.osbase 1.2.9.65
        sysmgt.cim.providers.smash 1.2.9.65
        sysmgt.cim.providers.scc 1.2.9.65
        sysmgt.cim.providers.metrics 1.2.9.65

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

 .......................

........................

........................
 restricted by GSA ADP Schedule Contract with IBM Corp.
. . . . . << End of copyright notice for sysmgt.cim.providers >>. . . .

Filesets processed:  349 of 420  (Total time:  30 mins 44 secs).

installp: APPLYING software for:

Originally posted by: dvader

Yes, this is unpropriate behaviour!!!

Is there anyone who can solve it? Thx

Originally posted by: tech100

the issue occurs only on "live" system and not when you do OS update directly on alt_rootvg using alt_disk_copy. this solution is acceptable (at least for me) - system must be reboot anyhow after update finishes. you still have saved original copy on old_rootvg which you can reintegrate into updated rootvg after you apporve update (successful)