OpenSolaris

The following output can be seen on backout of current feature KU that is relying on /usr/sadm/install/scripts/r.manifest to handle SMF manifest removal:

<snip>
Loading smf(5) service descriptions: 11/11
Jun 26 16:55:37 svc.startd[7]: svc:/network/routing-setup:default: Method "/lib/svc/method/net-routing-setup" failed with exit status 1.
Jun 26 16:55:37 svc.startd[7]: svc:/network/routing-setup:default: Method "/lib/svc/method/net-routing-setup" failed with exit status 1.
Jun 26 16:55:37 svc.startd[7]: svc:/network/routing-setup:default: Method "/lib/svc/method/net-routing-setup" failed with exit status 1.
Jun 26 16:55:37 svc.startd[7]: network/routing-setup:default failed: transitioned to maintenance (see 'svcs -xv' for details)
...

# svcs -vx
svc:/network/routing-setup:default (Initial routing-related configuration.)
 State: maintenance since Tue Jun 26 16:55:37 2007
Reason: Start method failed repeatedly, last exited with status 1.
   See: http://sun.com/msg/SMF-8000-KS
   See: man -M /usr/share/man -s 1M routeadm
   See: /var/svc/log/network-routing-setup:default.log
Impact: 1 dependent service is not running:
        svc:/network/routing/route:default

svc:/network/initial:default (initial network services)
 State: maintenance since Tue Jun 26 16:55:24 2007
Reason: Start method failed repeatedly, last exited with status 1.
   See: http://sun.com/msg/SMF-8000-KS
   See: man -M /usr/share/man -s 1M ifconfig
   See: /var/svc/log/network-initial:default.log
Impact: This service is not running.
...

# cat /var/svc/log/network-routing-setup:default.log
...
[ Jun 26 16:55:37 Executing start method ("/lib/svc/method/net-routing-setup") ]
/sbin/sh: /lib/svc/method/net-routing-setup: not found
[ Jun 26 16:55:37 Method "start" exited with status 1 ]
[ Jun 26 16:55:37 Executing start method ("/lib/svc/method/net-routing-setup") ]
/sbin/sh: /lib/svc/method/net-routing-setup: not found
[ Jun 26 16:55:37 Method "start" exited with status 1 ]
[ Jun 26 16:55:37 Executing start method ("/lib/svc/method/net-routing-setup") ]
/sbin/sh: /lib/svc/method/net-routing-setup: not found
[ Jun 26 16:55:37 Method "start" exited with status 1 ]
</snip>

This newly introduced svc:/network/routing-setup is online even in single-user and hence with current r.manifest the removal is not handled correctly on patchrm, while corresponding method is being wiped out successfully.
bustos 2008-05-13

r.manifest was not designed to be run from a tool which
would ignore its failure, so I'm closing this bug as "Not a
Defect".  If you wish it to be changed for
that, please reopen this bug as an RFE.  If you want to
fix this specific instance, please transfer this bug to the
appropriate patch category to make the patch disable
the service before running r.manifest, or by using Alan's
solution in the Comments.
Actually to discern whether this is a bug or RFE, question needs to be answered (preferably with docs pointer):

What were the specifications for pkg removal action regarding SMF manifest. One would almost expect that it was to remove the service. But if it is enabled, then it fails the pkgrm with "$fmri remains enabled; aborting". Also please, note: SVR4 packaging expect checkinstall to be the only place where non-zero (error) return exit is expected/handled. pkgrm is even more problematic (but preremove would at least be less dangerous). I hope the design does not really mean to leave the customer with possibly partially removed package (anything that got processed before incorrectly placed CAS failure). I am sorry, but this seems plainly wrong (bug) to me and I will think so until I see approved specs (like ARC case) stating this is expected and intended behavior.
bustos 2008-05-14

The official way to remove a service manifest during
a patch backout on a live system is to disable the service
and then invoke r.manifest on the manifest.  This is
error-prone and seems more complicated than
necessary.  There should be a simpler way.

One way might be to set an environment variable which
instructs r.manifest to delete the service forcibly.
Another might be to delete the service forcibly with
svccfg without using r.manifest at all.

Disable the service prior to running patchrm manually.

N/A