failure to update libpam-systemd in 14.04 due to missing logind init script

Interesting that the last step of the libpam-systemd .postinst script is to remove the systemd-logind service, that the new version of the package compains about not being able to find..?
(or does that just clean up any left over cruft in /etc/init.d/, and not /etc/init/ ?)

Hamish

Status changed to 'Confirmed' because the bug affects multiple users.

I ran into this one while building a custom LiveCD. My work-around was to comment out the daemon start and stop in /var/lib/dpkg/info/libpam-systemd\:amd64.postinst and /var/lib/dpkg/info/libpam-systemd\:amd64.prerm. I then ran apt-get -f install and then uncommented the lines. This allowed me to build the CD but it still issues an error message on the CD until I do apt-get --reinstall install libpam-systemd.

A similar problem

Today a package upgrade to whoopsie in 14.04 is also triggering the same missing init.d script problem.

Preparing to unpack .../whoopsie_0.2.24.6_i386.deb ...
invoke-rc.d: unknown initscript, /etc/init.d/whoopsie not found.
dpkg: warning: subprocess old pre-removal script returned error exit status 100
dpkg: trying script from the new package instead ...
invoke-rc.d: unknown initscript, /etc/init.d/whoopsie not found.
dpkg: error processing archive /var/cache/apt/archives/whoopsie_0.2.24.6_i386.deb (--unpack):
 subprocess new pre-removal script returned error exit status 100
invoke-rc.d: unknown initscript, /etc/init.d/whoopsie not found.
/bin/df: no file systems processed
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 100
Preparing to unpack .../libwhoopsie0_0.2.24.6_i386.deb ...
[...]
Errors were encountered while processing:
 /var/cache/apt/archives/whoopsie_0.2.24.6_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
[...]
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).

I assume the same hack of editing the pre/post inst/rm scripts to exit with a warning and 0 exit code instead of $? can temporarily work around it.

Hamish

Hi all,
i have the exact same problem with libpam-systemd and whoopsie ...

Matthew, can you tell us which line you comment in thoses scripts ?
Someone knows why this problem is only happening in a chroot ??

Julius wrote:
> can you tell us which line you comment in thoses scripts ?

my quick-fix work-around was to change the exit code errors into warnings:

apt-get -q update

# on 32bit version:
sed -i -e 's/exit $?/exit 0/' \
   "/var/lib/dpkg/info/libpam-systemd:i386.prerm"
service systemd-logind stop

apt-get --yes install systemd-services

sed -i -e 's/exit $?/exit 0/' \
   "/var/lib/dpkg/info/libpam-systemd:i386.postinst"

apt-get --yes install libpam-systemd
apt-get -f install --yes

sed -i -e 's/exit $?/exit 0/' \
   "/var/lib/dpkg/info/whoopsie.prerm"
apt-get --yes remove whoopsie libwhoopsie0

apt-get --yes upgrade

Hamish

Thank you hamish, i will try that.

Hi,

first of all, I've got the same problem, but everytime when I was configuring my own live in chroot.

Here is how I turned around the problem:

in chroot I've stated not to upgrade libpam-systemd, to keep it back:

      echo "libpam-systemd hold"|dpkg --set-selections

then I've dist-upgraded the distro without any error.

To test it, Ive installed from that live dvd (an iso, actually) on a VM, and, once logged in the new VM, I've revoked my previous directive (as root):

      echo "libpam-systemd install"|dpkg --set-selections

and finally dist-upgraded without any error.

Hoping this could help.

Cheers,
Silvia

Similar problem here. I'm using UCK (Ubuntu Customization Kit) to create a custom 64-bit Xubuntu 14.04 image.

When in chroot (via uck-remaster-chroot-rootfs) it is not possible to upgrade oder dist-upgrade. It will fail with the described dependency errors.

Besides libpam-systemd and whoopsie I also have it happening on the linux-image:

linux-signed-image-3.13.0-24-generic : Depends: linux-image-3.13.0-24-generic (= 3.13.0-24.47) but 3.13.0-24.46 is installed
                                        Depends: linux-image-extra-3.13.0-24-generic (= 3.13.0-24.47) but 3.13.0-24.46 is installed

For libpam-systemd and whoopsie I can workaround it by editing the following files as described by hamish:

  /var/lib/dpkg/info/whoopsie.prerm
  /var/lib/dpkg/info/libpam-systemd\:amd64.prerm
  /var/lib/dpkg/info/libpam-systemd\:amd64.postinst

(change "exit $?" to "exit 0" in the invoke-rc.d lines)

The linux-image fails on something different. There is a "unexpected fi" occurring in the following files:

  /etc/kernel/postrm.d/zz-update-grub
  /etc/kernel/postinst.d/zz-update-grub

They contain an if statement with the if body commented out so the 'fi' directly follows the 'then' which is a syntax error:

  if [ -e /boot/grub/grub.cfg ]; then
      #exec update-grub
  fi

Also commenting out the 'if' and 'fi' lines works around it.

Btw. the method by Silvia (putting the packages on hold) does not work for me, because it will fail to create the /boot/vmlinz-* files which I need for my modifications.

I get this issue with a chroot ubuntu 14.04 armhf build running with android on a samsung galaxy tab 10.1.

This is fixed in utopic, as the init script went away completely, in favor of always using D-BUS activation.

I just ran into this a second time during a trusty update

I wonder if mounting /run in the chroot with --bind would help?

Steve C wrote:
> I just ran into this a second time during a trusty update

yes, 14.04.1 was ok until there was again a new security update for the package to upgrade to.

I have this issue, not sure if it's related:

Setting up libpam-systemd:amd64 (204-5ubuntu20.4) ...
start: Job failed to start
invoke-rc.d: initscript systemd-logind, action "start" failed.
dpkg: error processing package libpam-systemd:amd64 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 libpam-systemd:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

> I'm using UCK (Ubuntu Customization Kit) to create a custom 64-bit Xubuntu 14.04 image.

same here.

>For libpam-systemd and whoopsie I can workaround it by editing the following files as described by hamish:
> /var/lib/dpkg/info/whoopsie.prerm
> /var/lib/dpkg/info/libpam-systemd\:amd64.prerm
> /var/lib/dpkg/info/libpam-systemd\:amd64.postinst
> (change "exit $?" to "exit 0" in the invoke-rc.d lines)

this, however, doesn't work for me (see below)

Reproducable by:

$ uck-gui

# welcome to
click OK

# language packs
select de + en
click OK

# languages at boot time
select de + en
click OK

# default language
select en
click OK

# desktop environments
select Other (for xubuntu desktop)
click OK

# select iso image
select xubuntu-14.04.1-desktop-amd64.iso
click OK

# Please enter the name for your CD
click OK

# customize
select yes
click OK

# windows related files
select yes
click OK

# hyprid image
select yes
click OK

# ready to build
click OK

-> enter sudo password if you are asked for it <-

# Select items from list (Run console, continue building)
select Run console application
click OK

# in root console
apt-get update

=> all fine, no messages

apt-get upgrade

=> error msg as above
=> files modified as proposed by jox above (5 files)

apt-get upgrade

Result:

update-initramfs: Generating /boot/initrd.img-3.13.0-32-generic
/tmp/mkinitramfs_QAcwho/scripts/casper-bottom/48xubuntu_maybe_ubiquity: 6: .: Can't open /scripts/casper-functions
Errors were encountered while processing:
 libpam-systemd:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Any news on this issue?
Is uck broken or just the libpam update?

PS
$ dpkg -l | grep uck
ii uck 2.4.7-0ubuntu1 all Tool to customize official Ubuntu Live CDs

I have investigated this some more. I will provide a solution for UCK (Ubuntu Customization Kit) but it might apply to other contexts as well.

It is actually 3 distinct issues:

The main problem is the missing init scripts. This is a result from UCK deactivating initctl (see also in the output of uck-chroot-rootfs: "Deactivating initctl..."). This makes invoke-rc.d fail when trying to run upstart jobs (Ubuntu uses upstart (not init) for the services in question). The "/etc/init.d/* not found" is a followup error and actually misleading.

The fix described previously (modifying .prerm/.postinst files) does work, but it's better to fix it globally and not for each affected package. I found it's best to do it right in invoke-rc.d. Just change all "exit 100" to "exit 0" in /usr/sbin/invoke-rc.d (in the chroot!). That will generally ignore missing init scripts. Don't forget to revert the change afterwards.

The second problem is the missing /scripts directory ("Can't open /scripts/casper-functions" error). This can be fixed with the following command (in the chroot!):

  ln -s /usr/share/initramfs-tools/scripts /scripts

The third problem is that the UCK applies a hack on the zz-update-grub scripts which in my case creates an invalid syntax and thus breaks the upgrade as well (dependency problems on the linux-image-generic package). The fix is described in my comment #10.

In order to avoid applying these patches manually each time, I modified UCK to apply it when entering chroot, and revert it when exiting (amongst the other stuff that UCK does in these stages). It's all in /usr/lib/uck/remaster-live-cd.sh.

I made a fork of the UCK source code on github and applied the changes. You may just get the follwing file

  https://raw.githubusercontent.com/jox/UCK/master/libraries/remaster-live-cd.sh

and replace your /usr/lib/uck/remaster-live-cd.sh with it (this time *not* in the chroot...).

You might also apply the attached patch as follows:

  $ cd /usr/lib/uck
  $ sudo patch -p2 remaster-live-cd.sh.bak < \
      /path/to/fix-uck-missing-initd-scripts-1.patch

(The path in the patch is different since it is from the source code. Running patch with -p2 from the directory the file is located will apply it properly.)

You may view the changes on github as well:

Fixed missing /scripts dir in chroot.
https://github.com/jox/UCK/commit/2f14005cd47845d7496e6a2b1bdd72a553fd6be2

Fixed "grub-probe postinst/postrm hack" in chroot.
https://github.com/jox/UCK/commit/d2e2ffbbae80392357b8bf442d28678f9298c52a

Added hack to invoke-rc.d in chroot to ignore missing init scripts.
https://github.com/jox/UCK/commit/4c8277459c42f089fd73e6ae9a25d3e73177f491

Hope this helps

Sorry, there is a typo (the ".bak" is wrong). Let me correct this:

--
You might also apply the attached patch as follows:

  $ cd /usr/lib/uck
  $ sudo patch -p2 remaster-live-cd.sh < \
      /path/to/fix-uck-missing-initd-scripts-1.patch
--

(Please note that I actually meant "You might *alternatively* apply...". Not "also". Just to be clear.)

#18 solved it....

If you are remastering Linux Mint 17 XFCE then only editing /usr/sbin/invoke-rc.d will do........

@jox :

hi,

i was able to make the custom live cd with ur edited remaster-live-cd.sh file, but while booting it from the live cd shows libpam-systemd installation/upgradation failure.apport crash report pasted below :

ProblemType: Package
Architecture: amd64
Date: Thu Sep 11 11:06:58 2014
Package: libpam-systemd 204-5ubuntu20.6
SourcePackage: systemd
ErrorMessage:
 subprocess new pre-removal script returned error exit status 100
DpkgTerminalLog:
DistroRelease: Ubuntu 14.04
DuplicateSignature: package:libpam-systemd:204-5ubuntu20.6:subprocess new pre-removal script returned error exit status 100
LiveMediaBuild: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 3.13.0-32.57-generic 3.13.11.4
Tags: trusty
Title: package libpam-systemd 204-5ubuntu20.6 failed to install/upgrade: subprocess new pre-removal script returned error exit status 100
Uname: Linux 3.13.0-32-generic x86_64

Please helpt to solve this problem...
detailed crash report file is attache.

Hi Paul,

could you provide some more details?

I suppose you were using the 'uck-gui' command to remaster a Ubuntu 14.04.1 amd64 image?

How are you booting (DVD or USB)?

Did you boot right into the Live CD (by choosing "Try Ubuntu")?

When and how exactly did you get this failure? (In fact "while booting"? Or after invoking some apt commands or using Software Center in the running Live Ubuntu?)

If possible, what happens if you invoke the following command in the running remastered Ubuntu: 'initctl show-config'?

I have disabled the apport crash report service while remastering.Now it is solves(no crash report seen)

Hi @jox,

Thank u for the quick Response..

Answers to ur quests :

I used 'uck-gui' command to remaster a Ubuntu 14.04.1 amd64 image.

Booting via USB

Yes , i boot right into the Live CD (by choosing "Try Ubuntu").

While booting/log-in i got the failure/crash report without trying to update or upgrade any packages.I Have installed the OS on my hard-disk, still i got the failure report.

While remastering, i have upgraded the OS.Is that the problem?

initctl show-config command returns no value while in the chroot env(remastering env)
root@paul-Inspiron-1525:/# initctl show-config
root@paul-Inspiron-1525:/#

Although i was able to supress the crash report by disabling the apport service in /etc/default/apport.

Hi Paul,

thanks for the details.

I meant the result of "initctl show-config" in the running Ubuntu booted from the remastered image. At the time when you get the crash report. Not in the chroot env.

The output you get in the chroot env (no value) is expected, since initctl is deactivated in that scope.

We have to check if the same thing (initctl deactivated) is still happening in your live (or installed) Ubuntu for some strange reason.

Maybe the chroot session while remastering was not reverted back properly.

How do you exit the chroot session?

It might also help if you attached your build.log from the remastering.

Another question: what happens when you "apt-get update" and "apt-get dist-upgrade" in the live or installed ubuntu (after you disabled apport).

@Paul:

Additionally you can run:

  ls -l /sbin/initctl /usr/sbin/update-grub /usr/sbin/grub-probe

If any of these is a symbolic link to /bin/true then something's wrong.

I have this issue on my current ubuntu 14.04. Is there a simple way to fix it. I see the "fix", but It seems to be for someone making a live disk. Its a bit over my head.

@wlraider70

What's your exact error message?

Do you have any output if you execute 'initctl show-config' in a terminal?

Sorry for the vauge message erlier.

server@gateway:~$ sudo apt-get upgrade -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done

start: Job is already running: systemd-logind
invoke-rc.d: initscript systemd-logind, action "start" failed.
dpkg: error processing package libpam-systemd:amd64 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 dbus
 language-selector-common
 libpam-systemd:amd64

E: Sub-process /usr/bin/dpkg returned an error code (1)

(hmmm, no way to edit comments? That's not good for me)

@wlraider70

This seems not to be directly related. Same as #16 by @Michael Heuberger.

The issue of this thread is about this message:

  invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind.

It can not find the initscript and thus is not able to execute it.

Whereas your message...

  invoke-rc.d: initscript systemd-logind, action "start" failed.

...indicates that the initscript was in fact executed, but did fail (even though it's strange that "Job is already running" produces a fail. On my system (14.04) it does not produce an error when I run "invoke-rc.d systemd-logind start" as root, while it is already running).

Maybe this thread helps (specifically #4):

"invoke-rc.d: initscript systemd-logind, action "start" failed."
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1320563

Btw. I was also surprised at not being able to edit comments. I guess it's because the posts end up in a mailing list.
e.g. http://<email address hidden>/msg4504011.html

Similar to #11, I was getting this error trying to install on Android, though I'm using merged (bind) mounts instead of chroot. The solution in #3 worked for me. The problem seems to be that the /var/lib/dpkg/info/libpam-systemd:armhf.postinst script is checking for /etc/init.d/systemd-logind (doesn't exist) OR /etc/init/systemd-logind.conf (does exist) before calling invoke-rc.d systemd-logind.

very bad experience. ubuntu server 14.04 64bit, trying to fresh install on some older DELL machine (poweredge 1950) with software raid with separate /boot, swap and /tmp. everything seems to run ok, and after reboot, grub works ok (except that one has to make fast boot = 0, otherwise error message, but that is another bug with that save environment thing not working on raid in grub anyway), but when actually booting the system, after swap is turned on in second 13 or so, booting stops, and the machine freezes before the consoles are open, machine not reachable on the network.

ok, rebooting from CD to rescue, but the network configuration is totally broken due to some misconfiguration of /etc/resolv.conf (pointing to ../run/resolvconf/whatever), needing to replace it manually with resolv.conf that is present while the live CD downloads the apt packages...

but still system doesn't boot, so finally finding this page, and manually editing the prerm and post scripts of this terrible libpam-systemd package, getting the apt-get go through the install, and only then getting the booting working.

hell with this ubuntu and my lost night! sorry, I am not going to produce any log files after the machine has been finally installed. no logfiles were produced anyway, the /target/var/log was just empty files.

@Jox

I am trying your solution in #18 with UCK. It allows me to upgrade as well as dist-upgrade and install my files, but once my .iso is made and I try to install it under a virtualbox, it sents me to a busybox shell instead of prompting me to install/try ubuntu.

To apply your solution I opened a terminal in ubuntu and ran the following commands:
~$ wget https://raw.githubusercontent.com/jox/UCK/master/libraries/remaster-live-cd.sh
~$ sudo mv remaster-live-cd.sh /usr/lib/uck/remaster-live-cd.sh

Im running ubuntu 14.04, UCK 2.4.7, and Virtualbox 4.3.10.

Any suggestions?

As an additional note to #35

This error only happens when I do a dist-upgrade.
I can install software and upgrade and everything seems to run smooth.

See Bug #1359740

Sorry I'm late to the party, but what about this as a workaround?

# dpkg-divert --local --add /etc/init.d/systemd-logind
# ln -s /bin/true /etc/init.d/systemd-logind

In the chroot, obviously. :-)

It's working for me, anyway. I did the same thing with /sbin/initctl, per Bug #430224.

#38 Thanks, Solved it.

This problem is solved :)

Errors were encountered while processing:
/var/cache/apt/archives/libpam-systemd_204-5ubuntu20.10_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Can you explain how you can fuck up an LTS release upgrade (not even a major upgrade)? If you just had *one* test system running, you would have been able to reproduce this. Amateurs...

apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libpam-systemd
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
19 not fully installed or removed.
Need to get 0 B/25.5 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
(Reading database ... 424067 files and directories currently installed.)
Preparing to unpack .../libpam-systemd_204-5ubuntu20.11_amd64.deb ...
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart-session/1001/2593: Connection refused
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
dpkg: warning: subprocess old pre-removal script returned error exit status 100
dpkg: trying script from the new package instead ...
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart-session/1001/2593: Connection refused
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
dpkg: error processing archive /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.11_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 100
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart-session/1001/2593: Connection refused
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 100
Errors were encountered while processing:
 /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.11_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

This thread recommends installing Debian :D

http://www.linuxforums.org/forum/ubuntu-linux/204157-libpam-systemd-dependency-error-unable-install-any-packages-anymo.html

I don't even know whether I can safely restart my computer in this state. Also, 14.04 LTS DOES NOT HAVE systemd. Where did you get the bright idea to even put the package in the repository in the first place? Are you paying your staff too little to fix this shit? If you are not able to program, just STOP doing it.

This bug's over a year old for Trusty and I just encountered it again.

Hi I am trying to build KDE packages for Kubuntu in Trusty and I now have a broken chroot.

scarlett@scarlett-lappy:~/Work/src/4.14.3/artikulate/artikulate-4.14.3$ sudo /usr/lib/pbuilder/pbuilder-satisfydepends
sudo: unable to resolve host scarlett-lappy
[sudo] password for scarlett:
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team <email address hidden>
Description: Dummy package to satisfy dependencies with aptitude - created by pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 9), cmake, kde-sc-dev-latest, pkg-kde-tools, kdelibs5-dev (>= 4:4.13.0), qtmobility-dev, libqtmultimediakit1
dpkg-deb: building package `pbuilder-satisfydepends-dummy' in `/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
(Reading database ... 39360 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) over (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring anyway as you requested:
 pbuilder-satisfydepends-dummy depends on qtmobility-dev; however:
  Package qtmobility-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libqtmultimediakit1; however:
  Package libqtmultimediakit1 is not installed.

Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
The following NEW packages will be installed:
  libasound2{a} libasound2-data{a} libasound2-plugins{a} libfftw3-single3{a} libgstreamer-plugins-base0.10-0{a} libgstreamer0.10-0{a}
  libjack-jackd2-0{a} libltdl7{a} libpam-systemd{a} libqt4-sql-sqlite{a} libqtconnectivity1{a} libqtcontacts1{a} libqtfeedback1{a}
  libqtgallery1{a} libqtlocation1{a} libqtmultimediakit1{a} libqtorganizer1{a} libqtpublishsubscribe1{a} libqtsensors1{a}
  libqtserviceframework1{a} libqtsysteminfo1{a} libqtversit1{a} libqtversitorganizer1{a} libsamplerate0{a} libspeexdsp1{a}
  libsystemd-daemon0{a} libtdb1{a} pulseaudio{a} qtmobility-dev{a} servicefw{a} systemd-services{a} systemd-shim{a}
The following packages will be REMOVED:
  libarchive-dev{u} libkonq-common{u} libkonq5-dev{u} libkonq5-templates{u} libkonq5abi1{u} libqjson-dev{u} libqjson0{u}
The following packages are RECOMMENDED but will NOT be installed:
  gstreamer0.10-pulseaudio pulseaudio-module-x11 pulseaudio-utils rtkit
0 packages upgraded, 32 newly installed, 7 to remove and 0 not upgraded.
Need to get 7726 kB/8114 kB of archives. After unpacking 27.1 MB will be used.
Get: 1 http://ubuntu.osuosl.org/ubuntu/ trusty/main libsystemd-daemon0 amd64 204-5ubuntu20 [9908 B]
Get: 2 http://ubuntu.osuosl.org/ubuntu/ trusty/main systemd-shim amd64 6-2bzr1 [11.4 kB]
Get: 3 http://ca.archive.ubuntu.com/ubuntu/ trusty/universe libqtconnectivity1 amd64 1.2.0-3ubuntu5 [180 kB]
Get: 4 http://ubuntu.osuosl.org/ubuntu/ trusty/main systemd-services amd64 204-5ubuntu20 [196 kB]
Get: 5 http://ca.archive.ubuntu.com/ubuntu/ trusty/univer...

ok looking at https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1326412

The package is not supported in Trusty?

I can't seem to even remove it, it fails with the same error.

I can reproduce this problem with Ubuntu 14.04 as guest and Fedora 22 as host.
The problem occurs 100% of the time with the script below.

The relevant error is:
INFO: apt-get -yf install
Reading package lists...
Building dependency tree...
Reading state information...
Correcting dependencies... Done
The following extra packages will be installed:
  libpam-systemd
The following packages will be upgraded:
  libpam-systemd
1 upgraded, 0 newly installed, 0 to remove and 55 not upgraded.
82 not fully installed or removed.
Need to get 0 B/25.5 kB of archives.
After this operation, 1024 B of additional disk space will be used.
(Reading database ... 54203 files and directories currently installed.)
Preparing to unpack .../libpam-systemd_204-5ubuntu20.13_amd64.deb ...
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
dpkg: warning: subprocess old pre-removal script returned error exit status 100
dpkg: trying script from the new package instead ...
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
dpkg: error processing archive /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.13_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 100
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 100
Errors were encountered while processing:
 /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.13_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Script:

cat > script.sh <<EOF
#!/bin/bash
echo "root:root" | chpasswd

export DEBIAN_FRONTEND=noninteractive

echo "INFO: apt-get update"
apt-get update

echo "INFO: apt-get -yf upgrade"
apt-get -yf upgrade

echo "INFO: apt-get -yf install"
apt-get -yf install

echo "INFO: apt-get -y install gcc"
apt-get -y install gcc

echo "INFO: apt-get -yf install"
apt-get -yf install

echo "INFO: apt-get -y install gcc"
apt-get -y install gcc

echo "INFO: end of script (also returncode 0)"
EOF

virt-builder -x -v ubuntu-14.04 --arch x86_64 \
 -o ubuntu.img \
 --format qcow2 \
 --run script.sh 2>&1 | tee output.txt

virt-cat -a ubuntu.img /tmp/builder.log > builder.log

Set root password of your VM to root:

virt-customize -a ubuntu.img --root-password "password:root"

This one-liner fails as well:

virt-builder -v -x ubuntu-14.04 -o output --root-password "password:root" --update

Has anyone made a shell script to fix this? I'm running on Android and it's a little difficult for me to follow how to fix.

Tried today on ubuntu 14.04 LTS as host for Ubuntu 14.04 LTS under LXC

the issue still occurs with libpam-systemd amd64 204-5ubuntu20.15

Managed to do a workaroud as suggested by Bill Gatliff (bgat) in #38.
git clone https://github.com/fgrehm/vagrant-lxc-base-boxes
edit https://github.com/fgrehm/vagrant-lxc-base-boxes/blob/master/debian/install-extras.sh

in line 17 change PACAKGES to
vim curl wget man-db bash-completion python-software-properties ca-certificates sudo ssh python rsync build-essential git subversion mc htop aptitude pbzip2 parallel pv debconf debconf-utils pbzip2 psmisc pwgen dh-make bzr-builddeb

and add between lines 24 and 25:

utils.lxc.attach dpkg-divert --local --add /etc/init.d/systemd-logind
utils.lxc.attach ln -s /bin/true /etc/init.d/systemd-logind

save, and invoke
make trusty

Attaching log, from such operation (well, I got some extra lines like locale-gen en_US.UTF-8 pl_PL.UTF-8 in line 23)

I'm also being bitten by this issue. I can't create chroots or VM images based on trusty due to polkit-1 bringing in libpam-systemd, which breaks as other commenters have described earlier...

This is very clearly not fixed on Ubuntu trusty, and the changelog of the package in trusty does not indicate any fix was applied.

Please remove the incorrect designation of "Fix Committed" for trusty.

I confirm that this is still an issue in Trusty. However, in #1326412, Dimitri John Ledkov wrote

> This is fixed in utopic, and will not be fixed in trusty.
> One will have to boot under upstart to dist-upgrade reliable within trusty.

https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1326412

I am reopening the Trusty task, as I've re-confirmed this bug in 14.04 chroot. apt upgrading will fail on libpam-systemd:

root@x250:/# apt dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  libfreetype6 os-prober
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
E: Can not write log (Is /dev/pts mounted?) - openpty (2: No such file or directory)
Setting up libpam-systemd:amd64 (204-5ubuntu20.19) ...
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
runlevel:/var/run/utmp: No such file or directory
dpkg: error processing package libpam-systemd:amd64 (--configure):
 subprocess installed post-installation script returned error exit status 100
Errors were encountered while processing:
 libpam-systemd:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Note that I can work around this by disabling policy-rc.d and initctl as such:

#!/bin/sh

# Ensure that apt upgrades work in Ubuntu on Windows
# environments, which do not use Ubuntu's /sbin/init
# Install a dummy, exit-non-zero policy-rc.d
cat >/usr/sbin/policy-rc.d <<EOF
#!/bin/sh
exit 101
EOF
chmod +x /usr/sbin/policy-rc.d
# Move initctl out of the way, install dummy initctl
dpkg-divert --local --rename --add /sbin/initctl
ln -sf /bin/true /sbin/initctl

Hi there!

Frankly, this issue requires some love. I hit it 10 different ways on a ridiculous variety of setups. And as many people pointed, we're talking about LTS here.

Could we just change the postinst script to something like this, and declare this issue over?

# Automatically added by dh_installinit
if [ -x "/etc/init.d/systemd-logind" ] || [ -e "/etc/init/systemd-logind.conf" ]; then
        if [ ! -e "/etc/init/systemd-logind.conf" ]; then
                update-rc.d systemd-logind defaults >/dev/null
        fi
        invoke-rc.d systemd-logind start || true
fi

It is longstanding practice, predating either upstart or systemd, that users of Debian and Ubuntu systems should create a /usr/sbin/policy-rc.d as part of their chroot setup. It is not a bug in the libpam-systemd package that it tries to start and stop its service using the policy-declared interface, only to have this fail because you're running in a chroot and nothing has told the system this.

The fix that was applied to utopic and later is not applicable to trusty. Later releases "fixed" this problem by removing the upstart job, no longer needed on systems that run systemd as init. That is not at all the appropriate fix in trusty.

It is likewise not appropriate to change the libpam-systemd package to silently ignore failures from invoke-rc.d when trying to start the systemd-logind service. Such a change would also negatively impact 14.04 systems for the benefit of chroot environments.

This is a systemic problem with the behavior of invoke-rc.d in chroots, and any fix must also be systemic. This problem is noticeable on the libpam-systemd package because it's a package that includes an upstart job but no init script; but many other packages will also misbehave, not by failing but by *succeeding* and running unsupervised processes that are not expected to start in the chroot.

So I am marking this bug 'wontfix' for trusty.

The proper package to discuss a fix against is sysvinit, which is where /usr/sbin/invoke-rc.d comes from in trusty.

I have briefly looked at backporting changes from the xenial /usr/sbin/invoke-rc.d. However, while the behavior of the xenial version in chroots appears to be what we're looking for (succeed silently), this also appears to work only if systemd is detected via the presence of /run/systemd/system. So this would not solve the problem for all use cases.