pkg commands don't work. unable to lock zones to perform operations

Rick Smith

unread,

Sep 7, 2010, 8:56:04 PM9/7/10

to

I am trying to remove a package, I get this error:

From the global zone I run this command: root@server# pkgrm
PKG
## Waiting for up to <300> seconds for package administration commands
to become available (another user is administering packages on zone
<uschi1fip02>)
pkgrm: ERROR: ERROR: Unable to acquire package administration lock for
zone <uschi1fip02>; please try again later
pkgrm: ERROR: ERROR: Unable to acquire lock on non-global zone
<uschi1fip02>: releasing all locks
pkgrm: ERROR: unable to lock zones to perform operations

1 package was not processed!

root@server #

I zlogin to the zone being mentioned and do a ps -ef and there is no
process running a package command, there is one perl script running
and I do a grep pk on that perl script and comes up with nothing.

Any idea?

Alex Zhang

unread,

Sep 7, 2010, 9:23:17 PM9/7/10

to

On 民國99/9/8 上午8:56, Rick Smith wrote:
> I am trying to remove a package, I get this error:
>
> From the global zone I run this command: root@server# pkgrm

[snip]

>
> 1 package was not processed!
>
> root@server #
>
> I zlogin to the zone being mentioned and do a ps -ef and there is no
> process running a package command, there is one perl script running
> and I do a grep pk on that perl script and comes up with nothing.
>
> Any idea?

Could you shutdown this zone?

Andy Neirman

unread,

Sep 7, 2010, 9:28:47 PM9/7/10

to

I am trying to find downtime for this - is there any other way. I ran
into the same problem while trying to install the package, but pkgadd
has a nice option -G which installs only in the global zone,
unfortunately pkgrm does not have any such option.

John D Groenveld

unread,

Sep 7, 2010, 10:09:42 PM9/7/10

to

In article <cea19807-3d9d-42ad...@e14g2000yqe.googlegroups.com>,

Andy Neirman <andy.n...@gmail.com> wrote:
>I am trying to find downtime for this - is there any other way. I ran

It was a bad idea to install HP's printing software on
a production system without testing first.

After you obtain downtime and remove the package, run pkgchk(1M)
to confirm that HP's bits didn't horrifically mangle your system.

But before you run, pkgchk(1M) on your production system,
read the fine manual and try it on a test system.

John
groe...@acm.org

Andy Neirman

unread,

Sep 7, 2010, 11:25:45 PM9/7/10

to

I did test it on a system. I did not realize pkgrm won't work on the
production system

John D Groenveld

unread,

Sep 8, 2010, 8:52:07 AM9/8/10

to

In article <ba07a8d1-505e-4d94...@n3g2000yqb.googlegroups.com>,

Andy Neirman <andy.n...@gmail.com> wrote:
>I did test it on a system. I did not realize pkgrm won't work on the
>production system

Did lpstat(1) hang on your test system?

Did HP's package fail to pkgrm(1M) on your test system?

Once you repair your production system, try configuring
printing on your test system:
First, pkgrm(1M) HP's package.
Then run pkgchk(1M) to confirm that HP's package didn't
obviously foobar your test system.
Then install SUNWfppd SUNWffiltersu SUNWffiltersr from
your Solaris 10 installation media.
Then configure the printer per my prior post:
Message-ID: <i5pnld$h85m$1...@tr22n12.aset.psu.edu>

John
groe...@acm.org

Andy Neirman

unread,

Sep 8, 2010, 4:08:16 PM9/8/10

to

I deleted the printers on the print server and then reinstalled them -
this took c
a re of the long wait time problem, now commands like lpstat do not
take any time at qall.

Also I was working on another system and could successfully install
the printer, so it seems the software does work