[Touch-packages] [Bug 1325142] Re: failure to update libpam-systemd in 14.04 due to missing logind init script
@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://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg4504011.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1325142 Title: failure to update libpam-systemd in 14.04 due to missing logind init script Status in “systemd” package in Ubuntu: Fix Released Status in “systemd” source package in Trusty: Triaged Status in “systemd” source package in Utopic: Fix Released Bug description: Hi, while running inside an i386 lubuntu 14.04 chroot, upgrading libpam- systemd to version 204-5ubuntu20.2 fails leaving dpkg in a broken state. 'apt-get -f install' from within the chroot will not fix it, but if the build is made bootable and put into a iso/VM you can recover that way in a live session. the problem seems to be the /var/lib/dpkg/info/libpam-systemd:i386.prerm script failing to bring down the logind daemon with 'invoke-rc.d systemd-logind stop', because invoke-rd.d is only looking for the /etc/init.d/ script (doesn't exist) and not /etc/init/systemd-logind.conf (does exist). ? Reading package lists... Building dependency tree... Reading state information... The following packages will be upgraded: libpam-systemd 1 upgraded, 0 newly installed, 0 to remove and 113 not upgraded. 3 not fully installed or removed. Need to get 0 B/25.2 kB of archives. After this operation, 1024 B of additional disk space will be used. (Reading database ... 113986 files and directories currently installed.) Preparing to unpack .../libpam-systemd_204-5ubuntu20.2_i386.deb ... 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 ... invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found. dpkg: error processing archive /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb (--unpack): subprocess new pre-removal script returned error exit status 100 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.2_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Our build logs available upon request, but the scripts to setup the chroot to recreate it are here: https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/build_chroot_nightly.sh https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/inchroot_nightly.sh In a web-search I notice a few others running into the same bug, chatter on irc at [18:10], http://irclogs.ubuntu.com/2013/05/28 /%23ubuntu-devel.txt someone else's build log: https://launchpad.net/~qutim/+archive/qutim/+build/6039800 launchpad bug #1323575 seems to be a duplicate of this one. perhaps related to older launchpad bug #1305395 ? note we are also suffering from a failure with update-initramfs, not sure of the root cause of that one but I thought I'd mention it in case they were related, since they both started happening about the same time, a couple weeks ago. (launchpad bug #1317602) It all worked ok after the inital releases of 14.04, so something to do with a package update since then. thanks, Hamish To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1325142] Re: failure to update libpam-systemd in 14.04 due to missing logind init script
@wlraider70 What's your exact error message? Do you have any output if you execute 'initctl show-config' in a terminal? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1325142 Title: failure to update libpam-systemd in 14.04 due to missing logind init script Status in “systemd” package in Ubuntu: Fix Released Status in “systemd” source package in Trusty: Triaged Status in “systemd” source package in Utopic: Fix Released Bug description: Hi, while running inside an i386 lubuntu 14.04 chroot, upgrading libpam- systemd to version 204-5ubuntu20.2 fails leaving dpkg in a broken state. 'apt-get -f install' from within the chroot will not fix it, but if the build is made bootable and put into a iso/VM you can recover that way in a live session. the problem seems to be the /var/lib/dpkg/info/libpam-systemd:i386.prerm script failing to bring down the logind daemon with 'invoke-rc.d systemd-logind stop', because invoke-rd.d is only looking for the /etc/init.d/ script (doesn't exist) and not /etc/init/systemd-logind.conf (does exist). ? Reading package lists... Building dependency tree... Reading state information... The following packages will be upgraded: libpam-systemd 1 upgraded, 0 newly installed, 0 to remove and 113 not upgraded. 3 not fully installed or removed. Need to get 0 B/25.2 kB of archives. After this operation, 1024 B of additional disk space will be used. (Reading database ... 113986 files and directories currently installed.) Preparing to unpack .../libpam-systemd_204-5ubuntu20.2_i386.deb ... 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 ... invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found. dpkg: error processing archive /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb (--unpack): subprocess new pre-removal script returned error exit status 100 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.2_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Our build logs available upon request, but the scripts to setup the chroot to recreate it are here: https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/build_chroot_nightly.sh https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/inchroot_nightly.sh In a web-search I notice a few others running into the same bug, chatter on irc at [18:10], http://irclogs.ubuntu.com/2013/05/28 /%23ubuntu-devel.txt someone else's build log: https://launchpad.net/~qutim/+archive/qutim/+build/6039800 launchpad bug #1323575 seems to be a duplicate of this one. perhaps related to older launchpad bug #1305395 ? note we are also suffering from a failure with update-initramfs, not sure of the root cause of that one but I thought I'd mention it in case they were related, since they both started happening about the same time, a couple weeks ago. (launchpad bug #1317602) It all worked ok after the inital releases of 14.04, so something to do with a package update since then. thanks, Hamish To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1325142] Re: failure to update libpam-systemd in 14.04 due to missing logind init script
@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. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1325142 Title: failure to update libpam-systemd in 14.04 due to missing logind init script Status in “systemd” package in Ubuntu: Fix Released Status in “systemd” source package in Trusty: Triaged Status in “systemd” source package in Utopic: Fix Released Bug description: Hi, while running inside an i386 lubuntu 14.04 chroot, upgrading libpam- systemd to version 204-5ubuntu20.2 fails leaving dpkg in a broken state. 'apt-get -f install' from within the chroot will not fix it, but if the build is made bootable and put into a iso/VM you can recover that way in a live session. the problem seems to be the /var/lib/dpkg/info/libpam-systemd:i386.prerm script failing to bring down the logind daemon with 'invoke-rc.d systemd-logind stop', because invoke-rd.d is only looking for the /etc/init.d/ script (doesn't exist) and not /etc/init/systemd-logind.conf (does exist). ? Reading package lists... Building dependency tree... Reading state information... The following packages will be upgraded: libpam-systemd 1 upgraded, 0 newly installed, 0 to remove and 113 not upgraded. 3 not fully installed or removed. Need to get 0 B/25.2 kB of archives. After this operation, 1024 B of additional disk space will be used. (Reading database ... 113986 files and directories currently installed.) Preparing to unpack .../libpam-systemd_204-5ubuntu20.2_i386.deb ... 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 ... invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found. dpkg: error processing archive /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb (--unpack): subprocess new pre-removal script returned error exit status 100 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.2_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Our build logs available upon request, but the scripts to setup the chroot to recreate it are here: https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/build_chroot_nightly.sh https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/inchroot_nightly.sh In a web-search I notice a few others running into the same bug, chatter on irc at [18:10], http://irclogs.ubuntu.com/2013/05/28 /%23ubuntu-devel.txt someone else's build log: https://launchpad.net/~qutim/+archive/qutim/+build/6039800 launchpad bug #1323575 seems to be a duplicate of this one. perhaps related to older launchpad bug #1305395 ? note we are also suffering from a failure with update-initramfs, not sure of the root cause of that one but I thought I'd mention it in case they were related, since they both started happening about the same time, a couple weeks ago. (launchpad bug #1317602) It all worked ok after the inital releases of 14.04, so something to do with a package update since then. thanks, Hamish To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1325142] Re: failure to update libpam-systemd in 14.04 due to missing logind init script
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). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1325142 Title: failure to update libpam-systemd in 14.04 due to missing logind init script Status in “systemd” package in Ubuntu: Fix Released Status in “systemd” source package in Trusty: Triaged Status in “systemd” source package in Utopic: Fix Released Bug description: Hi, while running inside an i386 lubuntu 14.04 chroot, upgrading libpam- systemd to version 204-5ubuntu20.2 fails leaving dpkg in a broken state. 'apt-get -f install' from within the chroot will not fix it, but if the build is made bootable and put into a iso/VM you can recover that way in a live session. the problem seems to be the /var/lib/dpkg/info/libpam-systemd:i386.prerm script failing to bring down the logind daemon with 'invoke-rc.d systemd-logind stop', because invoke-rd.d is only looking for the /etc/init.d/ script (doesn't exist) and not /etc/init/systemd-logind.conf (does exist). ? Reading package lists... Building dependency tree... Reading state information... The following packages will be upgraded: libpam-systemd 1 upgraded, 0 newly installed, 0 to remove and 113 not upgraded. 3 not fully installed or removed. Need to get 0 B/25.2 kB of archives. After this operation, 1024 B of additional disk space will be used. (Reading database ... 113986 files and directories currently installed.) Preparing to unpack .../libpam-systemd_204-5ubuntu20.2_i386.deb ... 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 ... invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found. dpkg: error processing archive /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb (--unpack): subprocess new pre-removal script returned error exit status 100 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.2_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Our build logs available upon request, but the scripts to setup the chroot to recreate it are here: https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/build_chroot_nightly.sh https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/inchroot_nightly.sh In a web-search I notice a few others running into the same bug, chatter on irc at [18:10], http://irclogs.ubuntu.com/2013/05/28 /%23ubuntu-devel.txt someone else's build log: https://launchpad.net/~qutim/+archive/qutim/+build/6039800 launchpad bug #1323575 seems to be a duplicate of this one. perhaps related to older launchpad bug #1305395 ? note we are also suffering from a failure with update-initramfs, not sure of the root cause of that one but I thought I'd mention it in case they were related, since they both started happening about the same time, a couple weeks ago. (launchpad bug #1317602) It all worked ok after the inital releases of 14.04, so something to do with a package update since then. thanks, Hamish To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1325142] Re: failure to update libpam-systemd in 14.04 due to missing logind init script
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'? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1325142 Title: failure to update libpam-systemd in 14.04 due to missing logind init script Status in “systemd” package in Ubuntu: Fix Released Status in “systemd” source package in Trusty: Triaged Status in “systemd” source package in Utopic: Fix Released Bug description: Hi, while running inside an i386 lubuntu 14.04 chroot, upgrading libpam- systemd to version 204-5ubuntu20.2 fails leaving dpkg in a broken state. 'apt-get -f install' from within the chroot will not fix it, but if the build is made bootable and put into a iso/VM you can recover that way in a live session. the problem seems to be the /var/lib/dpkg/info/libpam-systemd:i386.prerm script failing to bring down the logind daemon with 'invoke-rc.d systemd-logind stop', because invoke-rd.d is only looking for the /etc/init.d/ script (doesn't exist) and not /etc/init/systemd-logind.conf (does exist). ? Reading package lists... Building dependency tree... Reading state information... The following packages will be upgraded: libpam-systemd 1 upgraded, 0 newly installed, 0 to remove and 113 not upgraded. 3 not fully installed or removed. Need to get 0 B/25.2 kB of archives. After this operation, 1024 B of additional disk space will be used. (Reading database ... 113986 files and directories currently installed.) Preparing to unpack .../libpam-systemd_204-5ubuntu20.2_i386.deb ... 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 ... invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found. dpkg: error processing archive /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb (--unpack): subprocess new pre-removal script returned error exit status 100 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.2_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Our build logs available upon request, but the scripts to setup the chroot to recreate it are here: https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/build_chroot_nightly.sh https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/inchroot_nightly.sh In a web-search I notice a few others running into the same bug, chatter on irc at [18:10], http://irclogs.ubuntu.com/2013/05/28 /%23ubuntu-devel.txt someone else's build log: https://launchpad.net/~qutim/+archive/qutim/+build/6039800 launchpad bug #1323575 seems to be a duplicate of this one. perhaps related to older launchpad bug #1305395 ? note we are also suffering from a failure with update-initramfs, not sure of the root cause of that one but I thought I'd mention it in case they were related, since they both started happening about the same time, a couple weeks ago. (launchpad bug #1317602) It all worked ok after the inital releases of 14.04, so something to do with a package update since then. thanks, Hamish To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1325142] Re: failure to update libpam-systemd in 14.04 due to missing logind init script
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.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1325142 Title: failure to update libpam-systemd in 14.04 due to missing logind init script Status in “systemd” package in Ubuntu: Fix Released Status in “systemd” source package in Trusty: Triaged Status in “systemd” source package in Utopic: Fix Released Bug description: Hi, while running inside an i386 lubuntu 14.04 chroot, upgrading libpam- systemd to version 204-5ubuntu20.2 fails leaving dpkg in a broken state. 'apt-get -f install' from within the chroot will not fix it, but if the build is made bootable and put into a iso/VM you can recover that way in a live session. the problem seems to be the /var/lib/dpkg/info/libpam-systemd:i386.prerm script failing to bring down the logind daemon with 'invoke-rc.d systemd-logind stop', because invoke-rd.d is only looking for the /etc/init.d/ script (doesn't exist) and not /etc/init/systemd-logind.conf (does exist). ? Reading package lists... Building dependency tree... Reading state information... The following packages will be upgraded: libpam-systemd 1 upgraded, 0 newly installed, 0 to remove and 113 not upgraded. 3 not fully installed or removed. Need to get 0 B/25.2 kB of archives. After this operation, 1024 B of additional disk space will be used. (Reading database ... 113986 files and directories currently installed.) Preparing to unpack .../libpam-systemd_204-5ubuntu20.2_i386.deb ... 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 ... invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found. dpkg: error processing archive /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb (--unpack): subprocess new pre-removal script returned error exit status 100 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.2_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Our build logs available upon request, but the scripts to setup the chroot to recreate it are here: https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/build_chroot_nightly.sh https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/inchroot_nightly.sh In a web-search I notice a few others running into the same bug, chatter on irc at [18:10], http://irclogs.ubuntu.com/2013/05/28 /%23ubuntu-devel.txt someone else's build log: https://launchpad.net/~qutim/+archive/qutim/+build/6039800 launchpad bug #1323575 seems to be a duplicate of this one. perhaps related to older launchpad bug #1305395 ? note we are also suffering from a failure with update-initramfs, not sure of the root cause of that one but I thought I'd mention it in case they were related, since they both started happening about the same time, a couple weeks ago. (launchpad bug #1317602) It all worked ok after the inital releases of 14.04, so something to do with a package update since then. thanks, Hamish To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1325142] Re: failure to update libpam-systemd in 14.04 due to missing logind init script
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
** Patch added: "Patch to apply fixes to /usr/lib/uck/remaster-live-cd.sh"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142/+attachment/4190563/+files/fix-uck-missing-initd-scripts-1.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1325142
Title:
failure to update libpam-systemd in 14.04 due to missing logind init
script
Status in “systemd” package in Ubuntu:
Fix Released
Status in “systemd” source package in Trusty:
Triaged
Status in “systemd” source package in Utopic:
Fix Released
Bug description:
Hi,
while running inside an i386 lubuntu 14.04 chroot, upgrading libpam-
systemd to version 204-5ubuntu20.2 fails leaving dpkg in a broken
state. 'apt-get -f install' from within the chroot will not fix it,
but if the build is made bootable and put into a iso/VM you can
recover that way in a live session.
the problem seems to be the /var/lib/dpkg/info/libpam-systemd:i386.prerm
script failing to bring down the logind daemon with 'invoke-rc.d systemd-logind
stop', because invoke-rd.d is only looking for the /etc/init.d/ script (doesn't
exist) and not /etc/init/systemd-logind.conf (does exist).
?
Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be upgraded:
libpam-systemd
1 upgraded, 0 newly installed, 0 to remove and 113 not upgraded.
3 not fully installed or removed.
Need to get 0 B/25.2 kB of archives.
After this operation, 1024 B of additional disk space will be used.
(Reading database ... 113986 files and directories currently installed.)
Preparing to unpack .../libpam-systemd_204-5ubuntu20.2_i386.deb ...
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 ...
invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found.
dpkg: error processing archive
/var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2
[Touch-packages] [Bug 1338183] Re: libpam-systemd and whoopsie upgrade failed from a clean install of Xubuntu 14.04
*** This bug is a duplicate of bug 1325142 *** https://bugs.launchpad.net/bugs/1325142 ** This bug has been marked a duplicate of bug 1325142 failure to update libpam-systemd in 14.04 due to missing logind init script -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1338183 Title: libpam-systemd and whoopsie upgrade failed from a clean install of Xubuntu 14.04 Status in “shadow” package in Ubuntu: Confirmed Bug description: System: Xubuntu 14.04 LTS Package info: PackageName CurrentUpgradeTo whoopsie 0.2.24.50.2.24.6 libpam-systemd 204-5ubuntu20 204-5ubuntu20.2 Error shown: Errors were encountered while processing: /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.3_i386.deb /var/cache/apt/archives/whoopsie_0.2.24.6_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) How to reproduce: 1. Run the following commands to prepare the image customization environment: sudo apt-get install squashfs-tools genisoimage mkdir ~/livecdtmp cp ~/Desktop/xubuntu-14.04-desktop-i386.iso ~/livecdtmp cd ~/livecdtmp mkdir mnt sudo mount -o loop xubuntu-14.04-desktop-i386.iso mnt mkdir extract-cd sudo rsync --exclude=/casper/filesystem.squashfs -a mnt/ extract-cd sudo unsquashfs mnt/casper/filesystem.squashfs sudo mv squashfs-root edit sudo cp /etc/resolv.conf edit/etc/ sudo cp /etc/hosts edit/etc/ sudo mount --bind /dev/ edit/dev sudo chroot edit mount -t proc none /proc mount -t sysfs none /sys mount -t devpts none /dev/pts export HOME=/root export LC_ALL=C dbus-uuidgen > /var/lib/dbus/machine-id dpkg-divert --local --rename --add /sbin/initctl ln -s /bin/true /sbin/initctl 2. Enable the partner source by adding the following line to source.list: deb http://archive.canonical.com/ubuntu trusty partner deb-src http://archive.canonical.com/ubuntu trusty partner deb http://extras.ubuntu.com/ubuntu trusty main deb-src http://extras.ubuntu.com/ubuntu trusty main 3. apt-get update && apt-get upgrade to get the error mentioned. Troubleshooting steps I have tried: 1. clean the apt cache folder and download the updates again, still failed. 2. empty the folder for customization environment(livecdtmp in this example), and do the steps again, tried at least 4 times, still failed. 3. tried to completely remove and reinstall whoopsie package, but failed to remove and reinstall To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1338183/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1325142] Re: failure to update libpam-systemd in 14.04 due to missing logind init script
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. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1325142 Title: failure to update libpam-systemd in 14.04 due to missing logind init script Status in “systemd” package in Ubuntu: Confirmed Bug description: Hi, while running inside an i386 lubuntu 14.04 chroot, upgrading libpam- systemd to version 204-5ubuntu20.2 fails leaving dpkg in a broken state. 'apt-get -f install' from within the chroot will not fix it, but if the build is made bootable and put into a iso/VM you can recover that way in a live session. the problem seems to be the /var/lib/dpkg/info/libpam-systemd:i386.prerm script failing to bring down the logind daemon with 'invoke-rc.d systemd-logind stop', because invoke-rd.d is only looking for the /etc/init.d/ script (doesn't exist) and not /etc/init/systemd-logind.conf (does exist). ? Reading package lists... Building dependency tree... Reading state information... The following packages will be upgraded: libpam-systemd 1 upgraded, 0 newly installed, 0 to remove and 113 not upgraded. 3 not fully installed or removed. Need to get 0 B/25.2 kB of archives. After this operation, 1024 B of additional disk space will be used. (Reading database ... 113986 files and directories currently installed.) Preparing to unpack .../libpam-systemd_204-5ubuntu20.2_i386.deb ... 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 ... invoke-rc.d: unknown initscript, /etc/init.d/systemd-logind not found. dpkg: error processing archive /var/cache/apt/archives/libpam-systemd_204-5ubuntu20.2_i386.deb (--unpack): subprocess new pre-removal script returned error exit status 100 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.2_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Our build logs available upon request, but the scripts to setup the chroot to recreate it are here: https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/build_chroot_nightly.sh https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/inchroot_nightly.sh In a web-search I notice a few others running into the same bug, chatter on irc at [18:10], http://irclogs.ubuntu.com/2013/05/28 /%23ubuntu-devel.txt someone else's build log: https://launchpad.net/~qutim/+archive/qutim/+build/6039800 launchpad bug #1323575 seems to be a duplicate of this one. perhaps related to older launchpad bug #1305395 ? note we are also suffering from a failure with update-initramfs, not sure of the root cause of that one but I thought I'd mention it in case they were related, since they both started happening about the same time, a couple weeks ago. (launchpad bug #1317602) It all worked ok after the inital releases of 14.04, so something to do with a package update since then. thanks, Hamish To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1325142/+subscriptions -- Mailing lis
