package nfs-common 1:1.2.8-9ubuntu8.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 100

[Timothy G. Rundle]

Error occurred when upgrading to Wily

ProblemType: Package
DistroRelease: Ubuntu 15.10
Package: nfs-common 1:1.2.8-9ubuntu8.1
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
ApportVersion: 2.18-0ubuntu2
Architecture: amd64
Date: Sun Jul 19 12:47:15 2015
DuplicateSignature: package:nfs-common:1:1.2.8-9ubuntu8.1:subprocess installed post-installation script returned error exit status 100
ErrorMessage: subprocess installed post-installation script returned error exit status 100
RelatedPackageVersions:
 dpkg 1.17.25ubuntu1
 apt 1.0.9.10ubuntu1
SourcePackage: nfs-utils
Title: package nfs-common 1:1.2.8-9ubuntu8.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 100
UpgradeStatus: Upgraded to wily on 2015-07-19 (0 days ago)
upstart.statd-mounting.override: manual
upstart.statd.override: manual

[Steve Langasek (vorlon)]

Martin, could you have a look at this bug when you have a chance, please? The cause is quite simple, the systemd unit and the upstart job have differing names. I'm not sure about the correct fix - not least of all because of the interactions between invoke-rc.d and deb-systemd-invoke (which I still consider a bad case of NIH that we should correct at some point) and the differences in the top-level invocations for systemd vs. not ('nfs-utils.service' vs. individual units).

The semantics of the deb-systemd-invoke aren't even right for the postinst currently anyway, because we're calling 'deb-systemd-invoke try-restart' for nfs-utils.service, which is a one-shot service and therefore 'try-restart' has no effect. This looks like a serious bug in the semantics of dh_systemd, as 'try-restart' is a deviation from the established policy that services should be started on upgrade *even if they were not running before*, *unless* the admin has done something to specifically declare the service should not be started. (update-rc.d disable, etc).

[Martin Pitt (pitti)]

Relevant log excerpt:

Unpacking nfs-common (1:1.2.8-9ubuntu8.1) over (1:1.2.8-9ubuntu8) ...
Setting up nfs-common (1:1.2.8-9ubuntu8.1) ...
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
invoke-rc.d: unknown initscript, /etc/init.d/gssd not found.
dpkg: error processing package nfs-common (--configure):
 subprocess installed post-installation script returned error exit status 100

So this wasn't actually a vivid → wily dist-upgrade, but just upgrading vivid to vivid-updates. Not that it matters much in this case as wily's package is by and large the same.

I tried to reproduce this on vivid, bot with the default (no gssd) and with enabling gssd; but the upgrade, while noisy, works:

Setting up nfs-common (1:1.2.8-9ubuntu8.1) ...
invoke-rc.d: gssd.service doesn't exist but the upstart job does. Nothing to start or stop until a systemd or init job is present.
invoke-rc.d: idmapd.service doesn't exist but the upstart job does. Nothing to start or stop until a systemd or init job is present.

https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-53.2ubuntu4 was supposed to fix this. But the original reporter has 2.88dsf-53.2ubuntu12 installed already, so that's not it.

So I can't yet write a working test case for an SRU. Timothy, can you still reproduce this (try "sudo apt-get install --reinstall nfs-common")? If so, can you run these commands to create the naming compatibility symlinks:

   sudo ln -s rpc-gssd.service /lib/systemd/system/gssd.service
   sudo ln -s nfs-idmapd.service /lib/systemd/system/idmapd.service

and verify that this works now? After that, if you can still reproduce the install error without the symlinks I'd like to ask you some further questions.

> try-restart' is a deviation from the established policy that services should be started on upgrade *even if they were not running before*

try-restart is only done for dh_systemd_start, which handles all units which are not "the main .service" (which is usually accompanied by an init.d script). I. e. timers, .paths, auxiliary services which might be disabled on purpose, etc. It would be dangerous to just restart them all. In this particular case gssd should be handled by the dh_installinit generated snippet, which is just lacking the naming symlink as you already pointed out.

[Martin Pitt (pitti)]

> can you run these commands to create the naming compatibility symlinks:

Sorry, this was wrong. Please use these:

   sudo ln -s rpc-gssd.service /lib/systemd/system/gssd.service
   sudo ln -s /dev/null /lib/systemd/system/idmapd.service

Background: nfs-idmapd.service cnanot be restarted independently. It is bound to/handled by nfs-server.service already.

[Launchpad Janitor (janitor)]

This bug was fixed in the package nfs-utils - 1:1.2.8-9ubuntu10

---------------
nfs-utils (1:1.2.8-9ubuntu10) wily; urgency=medium

  * debian/nfs-common.links: Add naming compatibility symlinks for
    gssd.service → rpc-gssd.service and idmapd.service → /dev/null (as this
    is bound to/handled by nfs-server.service) to provide a match for the
    upstart job names. (LP: #1476010).

 -- Martin Pitt <email address hidden> Fri, 28 Aug 2015 09:59:48 +0200

[Timothy G. Rundle (tgrundle)]

HI Martin,

I believe I have upgraded past the version as well. When I run the reinstall I got a 404. After an apt-get update && apt-get upgrade, the reinstall worked without issue.

[Carlos Silva (mtbf99)]

Today i tried to upgrade xubuntu from 15.04 and i got the same error

[Nicolae Istratii (tallman9)]

Stragely, I still got the same error today during upgrade 15.04 -> 15.10.

[Christopher Barrington-Leigh (cpbl)]

I got the error today on upgrade 15.04 -> 15.10, which was carried out immediately after upgrading from 14.04-14.10-15.04.

[Stack (i-am-stack+ubuntuone)]

I did a fresh install of 15.04 a few months ago. Today I updated to 15.10 and got the error.

[Alberto Alvarellos González (mereshow)]

I got the error today on upgrade 15.04 -> 15.10.

[Vincent Ladeuil (vila)]

I got the error today on upgrade 15.04 -> 15.10.

[Jon Warner (f-jon-m)]

I got the error today on upgrade 15.04 -> 15.10. Has anyone found a workaround for this? The following symlinks did not work for me.

   sudo ln -s rpc-gssd.service /lib/systemd/system/gssd.service
   sudo ln -s /dev/null /lib/systemd/system/idmapd.service

Thank you,
Jon