Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Control: close -1 Hi. I was asked to take a look at #940034 and ended up reading this bug too. According to message #191 here, from the maintainer, | I can no longer reproduce the breakage that you reported. That this now works is a consequence of #935910 having been fixed by apt in bullseye. Mark wrote: | Are you satisfied that this bug can be closed? So, I think this bug should be closed now, unless there is something that remains to be done to improve things here. Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Simon, On Tue, Aug 27, 2019 at 05:46:32PM +0100, Mark Hindley wrote: > Simon, > > I think I have finally got to the bottom of this. As you suspected it is apt's > invocation of dpkg. See #935910. This is now resolved in apt version 1.8.4 which is in both sid and bullseye. I can no longer reproduce the breakage that you reported. Are you satisfied that this bug can be closed? Thanks. Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Sat, 21 Sep 2019, Mark Hindley wrote: > On Sat, Sep 21, 2019 at 06:51:16PM +0200, Cristian Ionescu-Idbohrn wrote: > > > Would you, please, start a new bug for this unless you really think > > > it is the same issue (apt being broken by continuing to uninstall > > > libsystemd0 after systemd prerm fails) and I will be happy to help. > > > > I really don't know what to think, but I do really feel this is not > > related to the systemd installed version. Any current systemd version > > should be removed without affecting the state. Am I wrong? > > I have to admit I am not clear exactly what you see is the problem. > Is it that removing systemd is taking lots of other packages with > it? > > Looking at the list of removals I think it is libpolkit-qt-1 that is > taking everything else out becuase it has not been patched to > support the new logind virtual packages. See #925344. > > But I still don't think it is the same as Simon's original bug here. Mark, I think you're right. I'll wait until the polkit-qt packages are patched, and if that does not solve my problem I'll submit a bug. Cheers, -- Cristian
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Sat, Sep 21, 2019 at 06:51:16PM +0200, Cristian Ionescu-Idbohrn wrote: > > Would you, please, start a new bug for this unless you really think > > it is the same issue (apt being broken by continuing to uninstall > > libsystemd0 after systemd prerm fails) and I will be happy to help. > > I really don't know what to think, but I do really feel this is not > related to the systemd installed version. Any current systemd version > should be removed without affecting the state. Am I wrong? I have to admit I am not clear exactly what you see is the problem. Is it that removing systemd is taking lots of other packages with it? Looking at the list of removals I think it is libpolkit-qt-1 that is taking everything else out becuase it has not been patched to support the new logind virtual packages. See #925344. But I still don't think it is the same as Simon's original bug here. HTH. Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Sat, 21 Sep 2019, Mark Hindley wrote: > On Sat, Sep 21, 2019 at 04:35:39PM +0200, Cristian Ionescu-Idbohrn wrote: > > I'm interested in this, but my systems (unstable and testing) are > > in a slightly different state. Let's take unstable, for example: > > Thanks for this. However, I really don't see it as relating to > Simon's original report. > > Would you, please, start a new bug for this unless you really think > it is the same issue (apt being broken by continuing to uninstall > libsystemd0 after systemd prerm fails) and I will be happy to help. I really don't know what to think, but I do really feel this is not related to the systemd installed version. Any current systemd version should be removed without affecting the state. Am I wrong? Cheers, -- Cristian
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Cristian, On Sat, Sep 21, 2019 at 04:35:39PM +0200, Cristian Ionescu-Idbohrn wrote: > I'm interested in this, but my systems (unstable and testing) are in a > slightly different state. Let's take unstable, for example: Thanks for this. However, I really don't see it as relating to Simon's original report. Would you, please, start a new bug for this unless you really think it is the same issue (apt being broken by continuing to uninstall libsystemd0 after systemd prerm fails) and I will be happy to help. Thanks. Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Sat, 21 Sep 2019, Mark Hindley wrote: > > Removing the pending tag as I don't think there is anything for > elogind to do to fix this. Hi, I'm interested in this, but my systems (unstable and testing) are in a slightly different state. Let's take unstable, for example: , | # apt-cache policy systemd-sysv | systemd-sysv: | Installed: (none) | Candidate: (none) ` , | # apt-cache policy sysvinit-core | sysvinit-core: | Installed: 2.96~beta-1 | Candidate: 2.96~beta-1 ` , | # apt-cache policy systemd | systemd: | Installed: 238-5 | Candidate: 238-5 ` (that is an older version). And that's because i have: , | # cat /etc/apt/preferences.d/no-systemd | Package: systemd systemd-sysv libsystemd0 libpam-systemd | Pin: release o=Debian | Pin-Priority: -1 ` So, pid 1 is already: , | -rwxr-xr-x 1 root root 53176 Aug 24 16:46 /sbin/init ` Systemd stuff was forcibly installed, but systemd is _not_ pid 1. Attempting to install: , | # apt-get install libpam-elogind elogind libelogind0 ` gives me a list of: , | 4 upgraded, 3 newly installed, 97 to remove and 146 not upgraded. ` Most of the packages to be removed are kde-related: , | The following packages will be REMOVED: | akonadi-server breeze drkonqi ffmpegthumbs frameworkintegration k3b | kactivitymanagerd kaffeine kamera kamoso kcachegrind kde-cli-tools | kde-config-cddb kde-config-screenlocker kde-runtime kde-style-breeze | kdeconnect kdelibs5-plugins kdesudo kinit kio kmahjongg kmenuedit kommander | kpat krusader kwin-common kwin-style-breeze libcolorcorrect5 libk3b7 | libkf5akonadicore5abi2 libkf5akonadiwidgets5abi1 libkf5auth5 libkf5authcore5 | libkf5bookmarks5 libkf5cddb5 libkf5configwidgets5 libkf5declarative5 | libkf5iconthemes5 libkf5kcmutils5 libkf5kdegames7 libkf5kdelibs4support5 | libkf5kdelibs4support5-bin libkf5kiocore5 libkf5kiofilewidgets5 | libkf5kiogui5 libkf5kiowidgets5 libkf5kmahjongglib5 libkf5newstuff5 | libkf5newstuffcore5 libkf5notifyconfig5 libkf5parts5 libkf5plasma5 | libkf5plasmaquick5 libkf5purpose-bin libkf5purpose5 libkf5quickaddons5 | libkf5runner5 libkf5sane5 libkf5style5 libkf5texteditor-bin | libkf5texteditor5 libkf5textwidgets5 libkf5wallet-bin libkf5xmlgui5 | libkf5xmlrpcclient5 libkscreenlocker5 libkwin4-effect-builtins1 | libokular5core8 libpam-systemd libpolkit-backend-1-0 libpolkit-qt-1-1 | libpolkit-qt5-1-1 libprocessui7 libsystemd0 libtaskmanager6 libweather-ion7 | milou okular plasma-desktop plasma-framework plasma-integration | plasma-workspace polkit-kde-agent-1 qml-module-org-kde-draganddrop | qml-module-org-kde-kconfig qml-module-org-kde-kcoreaddons | qml-module-org-kde-kquickcontrols qml-module-org-kde-kquickcontrolsaddons | qml-module-org-kde-kwindowsystem qml-module-org-kde-purpose | qml-module-org-kde-qqc2desktopstyle rasdaemon skanlite skrooge systemd | udisks2 ` but not only (some *polkit* among them, I guess kde-related). Of course I could let them be removed and later reinstall them. But that's not smooth/optimal. Still: , | The following additional packages will be installed: | gir1.2-polkit-1.0 libpolkit-agent-1-0 libpolkit-gobject-1-0 policykit-1 ` Looking deeper I notice both libelogind0 and libpam-elogind provide a certain version of systemd packages: , | Package: libelogind0 | Provides: libsystemd0 (= 241.3) ` , | Package: libpam-elogind | Provides: logind (= 241.3-1+debian1) ` but can't help wondering if that is necessary/relevant. Shouldn't they provide _any_ current version of libsystemd0 and logind and remove _any_ earlier versions? Isn't installing the current versions of systemd-related packages an unnecessary step? Cheers, -- Cristian
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Control: tags -1 - pending On Fri, Sep 20, 2019 at 04:30:00PM +0200, Thorsten Glaser wrote: > On Thu, 19 Sep 2019, Mark Hindley wrote: > > > On irc he also said there was little point in adding the Breaks: as apt > > doesn't > > rexec itself. > > Yes, even a Pre-Depends would not achieve anything TTBOMK. OK. Thanks. Removing the pending tag as I don't think there is anything for elogind to do to fix this. Simon, Are you happy for me to close this as resolved? Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Thu, 19 Sep 2019, Mark Hindley wrote: > On irc he also said there was little point in adding the Breaks: as apt > doesn't > rexec itself. Yes, even a Pre-Depends would not achieve anything TTBOMK. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Thu, Sep 19, 2019 at 08:36:53PM +0100, Mark Hindley wrote: > Control: tags -1 pending > > Simon, > > On Tue, Aug 27, 2019 at 05:46:32PM +0100, Mark Hindley wrote: > > I think I have finally got to the bottom of this. As you suspected it is > > apt's > > invocation of dpkg. See #935910. > > This has now been fixed in apt 1.9.4 (experimental). > > I propose to add > > Breaks: apt (<< 1.9.4) > > to the libelogind0 stanza in d/control. > > In my testing with apt v1.9.4 system breakage is avoided. After the systemd > prerm fails, dpkg returns immediately and apt is still available to fix the > system. Actually, Julian has just uploaded apt 1.8.4 with the same fix to unstable. On irc he also said there was little point in adding the Breaks: as apt doesn't rexec itself. I suppose the only thing it might achieve is to ensure apt had been updated to the latest version already. Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Control: tags -1 pending Simon, On Tue, Aug 27, 2019 at 05:46:32PM +0100, Mark Hindley wrote: > I think I have finally got to the bottom of this. As you suspected it is apt's > invocation of dpkg. See #935910. This has now been fixed in apt 1.9.4 (experimental). I propose to add Breaks: apt (<< 1.9.4) to the libelogind0 stanza in d/control. In my testing with apt v1.9.4 system breakage is avoided. After the systemd prerm fails, dpkg returns immediately and apt is still available to fix the system. Are you happy with this? Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Control: block -1 935910 On Thu, Aug 15, 2019 at 08:42:35PM +0100, Mark Hindley wrote: > > > Unsure if that’s apt or dpkg. Plus, the failing prerm is in systemd, > > > not in libsystemd0. > > > > I think this is probably dpkg, but it's dpkg being told what to do by > > apt, so it could be either one causing this. I would have hoped that if > > systemd.prerm fails, that's a fairly heavy hint that not only is it not > > OK to remove systemd at this time, it's also not OK to remove systemd's > > dependencies. Simon, I think I have finally got to the bottom of this. As you suspected it is apt's invocation of dpkg. See #935910. Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Thu, 15 Aug 2019, Mark Hindley wrote:
> I don't think so because the versions are different. systemd 241-7 Depends on
> libsystemd0 =241-7 (= ${binary:Version}). libelogind0 Provides libsystemd0
> =241.3 (= ${source:Upstream-Version}. That can never satisfy the systemd
> dependency.
The idea here is that systemd depends on implementation details
of its library, whereas libelogind0 stubs only enough to get all
other applications working, so it is not expected to satisfy the
dependency of systemd, rightfully.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
**
Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.
Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.
**
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Thu, Aug 15, 2019 at 08:02:51PM +0100, Simon McVittie wrote:
> On Thu, 15 Aug 2019 at 18:33:20 +0200, Thorsten Glaser wrote:
> > On Thu, 15 Aug 2019, Mark Hindley wrote:
> > > At this point apt has failed to remove systemd/241-7 which depends on
> > > libsystemd
> > > (=241-7). Surely it should not then go on to try and remove the systemd
> > > dependency?
> >
> > Unsure if that’s apt or dpkg. Plus, the failing prerm is in systemd,
> > not in libsystemd0.
>
> I think this is probably dpkg, but it's dpkg being told what to do by
> apt, so it could be either one causing this. I would have hoped that if
> systemd.prerm fails, that's a fairly heavy hint that not only is it not
> OK to remove systemd at this time, it's also not OK to remove systemd's
> dependencies.
Yes, but that appears not to happen.
> I still wonder whether apt/dpkg are being forced into this by libelogind0
> using Conflicts rather than Breaks - Conflicts is a stronger relationship
> than Breaks, and forces libsystemd0 to be removed altogether, not just
> deconfigured (marked as "broken"), before unpacking libelogind0. That
> means there's an unavoidable window during which libsystemd0 no longer
> provides libsystemd.so.0, but libelogind0 doesn't provide it yet.
I don't think so because the versions are different. systemd 241-7 Depends on
libsystemd0 =241-7 (= ${binary:Version}). libelogind0 Provides libsystemd0
=241.3 (= ${source:Upstream-Version}. That can never satisfy the systemd
dependency.
I am pretty sure I tried with Breaks and the result was the same.
Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Thu, 15 Aug 2019, Simon McVittie wrote: > I still wonder whether apt/dpkg are being forced into this by libelogind0 > using Conflicts rather than Breaks - Conflicts is a stronger relationship AFAICT file-level conflicts still need Provides+Conflicts+Replaces, and these are what we have here. (Otherwise, we could just have called Breaks Conflicts and dropped the original latter.) > That > means there's an unavoidable window during which libsystemd0 no longer > provides libsystemd.so.0, but libelogind0 doesn't provide it yet. Sure, but that’s business as usual in many cases. The dependency of apt on libsystemd.so.0 is unfortunate, but apparently easy to fix. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Thu, 15 Aug 2019 at 18:33:20 +0200, Thorsten Glaser wrote: > On Thu, 15 Aug 2019, Mark Hindley wrote: > > At this point apt has failed to remove systemd/241-7 which depends on > > libsystemd > > (=241-7). Surely it should not then go on to try and remove the systemd > > dependency? > > Unsure if that’s apt or dpkg. Plus, the failing prerm is in systemd, > not in libsystemd0. I think this is probably dpkg, but it's dpkg being told what to do by apt, so it could be either one causing this. I would have hoped that if systemd.prerm fails, that's a fairly heavy hint that not only is it not OK to remove systemd at this time, it's also not OK to remove systemd's dependencies. I still wonder whether apt/dpkg are being forced into this by libelogind0 using Conflicts rather than Breaks - Conflicts is a stronger relationship than Breaks, and forces libsystemd0 to be removed altogether, not just deconfigured (marked as "broken"), before unpacking libelogind0. That means there's an unavoidable window during which libsystemd0 no longer provides libsystemd.so.0, but libelogind0 doesn't provide it yet. smcv
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Thu, 15 Aug 2019, Simon McVittie wrote: > On Thu, 15 Aug 2019 at 18:34:39 +0200, Thorsten Glaser wrote: > > On Thu, 15 Aug 2019, Mark Hindley wrote: > > > Can you point me to any official documentation that says packages > > > should not depend on systemd-sysv? > > > > No, but why should they? > > For documentation value, if nothing else: it's a way to say "this package > genuinely does need systemd as pid 1, and won't work without it". OK, good point. Back to finding a migration path, then (perhaps even both ways)… bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Thu, 15 Aug 2019 at 18:34:39 +0200, Thorsten Glaser wrote: > On Thu, 15 Aug 2019, Mark Hindley wrote: > > Can you point me to any official documentation that says packages > > should not depend on systemd-sysv? > > No, but why should they? For documentation value, if nothing else: it's a way to say "this package genuinely does need systemd as pid 1, and won't work without it". > It does not guarantee that systemd is the currently-running init, > nor that this will be so at the next boot. No, and it's imperfect for those reasons; but for this not to be the case, you have to override the init system in ways that you will hopefully remember that you have done. smcv
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Thu, 15 Aug 2019, Mark Hindley wrote: > Can you point me to any official documentation that says packages > should not depend on systemd-sysv? No, but why should they? It’s an almost empty package, and it can be fulfilled by just depending on systemd. It does not guarantee that systemd is the currently-running init, nor that this will be so at the next boot. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Thu, 15 Aug 2019, Mark Hindley wrote: > I am now wondering if the prime responsibliity for the system breakage here is > down to apt's behaviour. […] > At this point apt has failed to remove systemd/241-7 which depends on > libsystemd > (=241-7). Surely it should not then go on to try and remove the systemd > dependency? Unsure if that’s apt or dpkg. Plus, the failing prerm is in systemd, not in libsystemd0. For dpkg, it makes sense to remove libsystemd0 nevertheless, when called literally; for apt, it doesn’t. (Interestingly enough, the dpkg developer has been telling the apt developers for ages that dpkg now can handle this kind of dependencies, and not to use the “do what I said and ignore dependencies” mode any more.) It does make sense to bring the developers of both apt and dpkg into this, irrelevant of where an improvement can be done, unless my beer-induced idea I already posted works. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Thanks for everybody's input with this thorny issue. I am now wondering if the prime responsibliity for the system breakage here is down to apt's behaviour. On Sun, Aug 11, 2019 at 03:31:00PM +0100, Simon McVittie wrote: > Actual result (transcript below): > > * systemd-sysv is removed > * sysvinit-core is unpacked > * systemd is also removed > * systemd's prerm fails because it is still the active init system > (this check is present since Debian systemd commit c3f5f249 in 44-6, > released in 2012 - it appears the intention is that anyone wishing to > switch from systemd to sysvinit should replace systemd-sysv with > sysvinit-core, then reboot into sysvinit, and only (auto)remove > systemd after that reboot) At this point apt has failed to remove systemd/241-7 which depends on libsystemd (=241-7). Surely it should not then go on to try and remove the systemd dependency? libelogind0 provides libsystemd0 (=241.3) so could never satisfy that requirement. > * libsystemd0 is removed anyway That is wrong and breaks systemd, never mind apt… Am I missing something? Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Tue, Aug 13, 2019 at 04:46:32PM +0200, Thorsten Glaser wrote: > But TTBOMK it is possible to install sysvinit alongside systemd, > then reboot and select sysvinit as “alternative” init from the > GRUB menu, then remove everything else. Now that I see /sbin/init > is part of sysvinit-core, I wonder if this is really possible any > more and, if not, why not… packages are not supposed to depend on > systemd-sysv… (but, ouch, libpam-systemd does). Can you point me to any official documentation that says packages should not depend on systemd-sysv? Thanks. Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Wed, 14 Aug 2019 at 19:41:08 +0100, Mark Hindley wrote: > I have managed to work around this today. It requires circumventing the > systemd > prerm failure. I am not recommending that as a final solution, but maybe we > can > have another go at asking the systemd maintainers to review it? Please do; they might have a better idea of how this can work, and it's them that you'll need to coordinate with for the libsystemd0 and libelogind0 providers of libsystemd.so.0 to not fight (more than they have to) anyway. smcv
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Tue, Aug 13, 2019 at 07:58:09PM +0100, Mark Hindley wrote: > Thorsten, > > Thanks for this. > > On Tue, Aug 13, 2019 at 04:46:32PM +0200, Thorsten Glaser wrote: > > On Sun, 11 Aug 2019, Simon McVittie wrote: > > > > > Found while preparing a test VM to test #923240. Please raise this to > > > RC severity if you think it is justified - I don't want to create the > > > > I don’t think it’s RC in any of the involved packages (elogind, > > systemd (shock!), apt) because it’s really a whole-system / package > > management issue. > > Yes, that is my conclusion after 2 days of trying different things. Certainly > systemd's prerm failure is pretty brutal. But this happens before any of the > src:elogind preinsts run, so I can't see a way around it. If anything, it is a > limitation in apt (although I am not trying to pass the buck here). I have managed to work around this today. It requires circumventing the systemd prerm failure. I am not recommending that as a final solution, but maybe we can have another go at asking the systemd maintainers to review it? What works for me on a sid VM: 1) rmdir /run/systemd/system This is the directory that the systemd prerm checks for. 2) apt install libpam-elogind systemd- 3) Immediate reboot with shutdown -r -n Although systemd as PID 1 no longer functions, all processes are sent SIGTERM, filesystems are synced and unmounted. I realise this is not graceful or elegant and I am unsure how safe it is. Comments? Perhaps we could ask that the systemd prerm no longer fails but instead prints a message saying immediate reboot is required and how to achieve it? Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Tue, 13 Aug 2019, Adam Borowski wrote: > > 1. Merge elogind into libpam-elogind (not the other way round), > >as elogind without libpam-elogind is apparently (see the > >other thread) not useful in any way. > > I don't think it's reasonable to have the daemon in a library package. > > There's also multiarch to think about: > foo:pdp11 Depends libpam-systemd:pdp11 Not exactly what you wrote, but I see it now (M-A same vs foreign, even though libpam-elogind is no library package and contains a conffile additioinally). There is no libpam-systemd in this equation. So then, rename elogind to elogind-daemon instead of merging it, and let libpam-elogind depend on elogind-daemon. The rest still stands (it is important that installing a package called simply “elogind” is the final step after a potential reboot, for being able to tell people to “just install elogind”). This would solve two of my confusions. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Tue, Aug 13, 2019 at 10:43:30PM +0200, Thorsten Glaser wrote: > On Tue, 13 Aug 2019, Adam Borowski wrote: > > > The prerm also makes systemd non-removable without uninstalling most > > packages, > > rebooting, then installing anew. Requiring such a reinstall is pretty much > > RC in by book. > > > > I've reported this before as #930105 but this got insta-closed+downgraded by > > Hm ☹ but I just had this crazy idea: > > 1. Merge elogind into libpam-elogind (not the other way round), >as elogind without libpam-elogind is apparently (see the >other thread) not useful in any way. I don't think it's reasonable to have the daemon in a library package. There's also multiarch to think about: foo:pdp11 Depends libpam-systemd:pdp11 > If this is not suitable I’m blaming the beer I’ve had with supper. [The queue to board is almost over...] -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian is one big family. Including that weird uncle ⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws. ⠈⠳⣄
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Tue, Aug 13, 2019 at 10:36:04PM +0200, Thorsten Glaser wrote: > > > I would also add that it surprises me that apt requires symbols from > > > libsystemd.so. > > > > libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one > > provided by libelogind), to tell systemd-logind (or elogind) not to > > shut down while an apt frontend is still installing packages. > > Ah. > > Can that be moved into a separate subprocess (does sd-bus have > a command-line interface) or, if not, dlopen() so it can be > downgraded to a Recommends? (libsystemd0 is still quasi-Essential > as most dæmons also Depend on it, but this would make apt at > least work.) The use is contained to a single function (apt-pkg/contrib/fileutl.cc Inhibit()) thus implementing dlopen() should be easy. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian is one big family. Including that weird uncle ⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws. ⠈⠳⣄
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Tue, 13 Aug 2019, Adam Borowski wrote: > The prerm also makes systemd non-removable without uninstalling most packages, > rebooting, then installing anew. Requiring such a reinstall is pretty much > RC in by book. > > I've reported this before as #930105 but this got insta-closed+downgraded by Hm ☹ but I just had this crazy idea: 1. Merge elogind into libpam-elogind (not the other way round), as elogind without libpam-elogind is apparently (see the other thread) not useful in any way. 2. Make libpam-elogind (which apparently Provides logind) work with libsystemd0 and not Conflict with systemd, only systemd-sysv. This means code changes (so it works with either library) and packaging changes: Depends: libelogind0 (>= …) | libsystemd0 (>= …) (note libelogind0 is first, for fresh installs) 3. Create a new package elogind which Depends on libelogind0 and libpam-elogind and Conflicts with systemd, to finish the install. It probably belongs into Section metapackages and has no content and can use dh_installdocs --link-doc=libpam-elogind so even its /usr/share/doc/elogind is just a symlink. This way, a sequence would look like: - apt-get install libpam-elogind ⇒ removes libpam-systemd and systemd-sysv ⇒ installs libpam-elogind and sysvinit-core - reboot - apt-get install elogind ⇒ removes systemd ⇒ replaces libsystemd0 with libelogind0 If this is not suitable I’m blaming the beer I’ve had with supper. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Tue, 13 Aug 2019, Simon McVittie wrote: > Ah, that's a major constraint on finding a correct solution here. systemd > is from the same source package as libsystemd0, so I think it's > reasonable for them to be in lockstep: systemd executables could well be > using private symbols or relying on specific behaviour beyond what the Indeed. > > I would also add that it surprises me that apt requires symbols from > > libsystemd.so. > > libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one > provided by libelogind), to tell systemd-logind (or elogind) not to > shut down while an apt frontend is still installing packages. Ah. Can that be moved into a separate subprocess (does sd-bus have a command-line interface) or, if not, dlopen() so it can be downgraded to a Recommends? (libsystemd0 is still quasi-Essential as most dæmons also Depend on it, but this would make apt at least work.) Thanks for the explanation, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Tue, 13 Aug 2019, Mark Hindley wrote: > I would also add that it surprises me that apt requires symbols from > libsystemd.so. I haven't yet investigated what functionality that is. But that > is a side issue. Probably for “modern Poett^WLinux desktop” logging, or somesuch. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Tue, Aug 13, 2019 at 09:10:12PM +0100, Simon McVittie wrote: > On Tue, 13 Aug 2019 at 19:58:09 +0100, Mark Hindley wrote: > > I would also add that it surprises me that apt requires symbols from > > libsystemd.so. > > libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one > provided by libelogind), to tell systemd-logind (or elogind) not to > shut down while an apt frontend is still installing packages. > > If apt wants to talk to D-Bus, sd-bus is certainly not a terrible choice: > newer D-Bus implementations like GDBus and sd-bus have had the opportunity > to learn from libdbus' mistakes. Because of consequences of apt failing to run, perhaps this could be ldopened instead? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian is one big family. Including that weird uncle ⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws. ⠈⠳⣄
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Tue, Aug 13, 2019 at 07:58:09PM +0100, Mark Hindley wrote: > On Tue, Aug 13, 2019 at 04:46:32PM +0200, Thorsten Glaser wrote: > > On Sun, 11 Aug 2019, Simon McVittie wrote: > > > Found while preparing a test VM to test #923240. Please raise this to > > > RC severity if you think it is justified - I don't want to create the > > > > I don’t think it’s RC in any of the involved packages (elogind, > > systemd (shock!), apt) because it’s really a whole-system / package > > management issue. > > Yes, that is my conclusion after 2 days of trying different things. Certainly > systemd's prerm failure is pretty brutal. But this happens before any of the > src:elogind preinsts run, so I can't see a way around it. The prerm also makes systemd non-removable without uninstalling most packages, rebooting, then installing anew. Requiring such a reinstall is pretty much RC in by book. I've reported this before as #930105 but this got insta-closed+downgraded by mbiebl. On the other hand, mbiebl routinely does this (or reports RC bugs on perfectly working packages without naming a reason), thus the closure might have not been related to merits or lack thereof. [I'm in Sao Paulo airport, after a day of travel and about to embark again, thus I can't investigate yet. Not before going home then around a week of sleep.] Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian is one big family. Including that weird uncle ⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws. ⠈⠳⣄
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Tue, 13 Aug 2019 at 19:58:09 +0100, Mark Hindley wrote: > systemd depends on a specific pacakged version of libsystemd0 (currently 241-7 > in sid) whilst all other packages at most depend on a particular src version > (eg. >= 213). Ah, that's a major constraint on finding a correct solution here. systemd is from the same source package as libsystemd0, so I think it's reasonable for them to be in lockstep: systemd executables could well be using private symbols or relying on specific behaviour beyond what the stable public API guarantees. (dbus-daemon and libdbus have a similar relationship.) > I would also add that it surprises me that apt requires symbols from > libsystemd.so. libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one provided by libelogind), to tell systemd-logind (or elogind) not to shut down while an apt frontend is still installing packages. If apt wants to talk to D-Bus, sd-bus is certainly not a terrible choice: newer D-Bus implementations like GDBus and sd-bus have had the opportunity to learn from libdbus' mistakes. smcv
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Thorsten,
Thanks for this.
On Tue, Aug 13, 2019 at 04:46:32PM +0200, Thorsten Glaser wrote:
> On Sun, 11 Aug 2019, Simon McVittie wrote:
>
> > Found while preparing a test VM to test #923240. Please raise this to
> > RC severity if you think it is justified - I don't want to create the
>
> I don’t think it’s RC in any of the involved packages (elogind,
> systemd (shock!), apt) because it’s really a whole-system / package
> management issue.
Yes, that is my conclusion after 2 days of trying different things. Certainly
systemd's prerm failure is pretty brutal. But this happens before any of the
src:elogind preinsts run, so I can't see a way around it. If anything, it is a
limitation in apt (although I am not trying to pass the buck here).
> > Actual result (transcript below):
> >
> > * systemd-sysv is removed
> > * sysvinit-core is unpacked
> > * systemd is also removed
> > * systemd's prerm fails because it is still the active init system
>
> Interesting. But this probably happens before the preinst of
> libelogind0 and does prevent its installation, which is not
> something easily circumvented.
systemd depends on a specific pacakged version of libsystemd0 (currently 241-7
in sid) whilst all other packages at most depend on a particular src version
(eg. >= 213). libelogind Provides libsystemd0 (= ${source:Upstream-Version}) so
the attempted removal of systemd is not triggered by any Conflict with
libelogind, but by the removal of libsystemd0 *before* replacing it with
libelogind0.
So far, I haven't discovered a way to mitigate or preempt that.
I would also add that it surprises me that apt requires symbols from
libsystemd.so. I haven't yet investigated what functionality that is. But that
is a side issue.
Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
On Sun, 11 Aug 2019, Simon McVittie wrote: > Found while preparing a test VM to test #923240. Please raise this to > RC severity if you think it is justified - I don't want to create the I don’t think it’s RC in any of the involved packages (elogind, systemd (shock!), apt) because it’s really a whole-system / package management issue. > Actual result (transcript below): > > * systemd-sysv is removed > * sysvinit-core is unpacked > * systemd is also removed > * systemd's prerm fails because it is still the active init system Interesting. But this probably happens before the preinst of libelogind0 and does prevent its installation, which is not something easily circumvented. > (this check is present since Debian systemd commit c3f5f249 in 44-6, > released in 2012 - it appears the intention is that anyone wishing to > switch from systemd to sysvinit should replace systemd-sysv with > sysvinit-core, then reboot into sysvinit, and only (auto)remove > systemd after that reboot) Yes but see below. > Maybe libelogind0 and elogind would be better off having Breaks (inverse > Depends) relationships with their systemd equivalents, instead of > Conflicts (inverse Pre-Depends) which are maybe too strong? Conflicts is needed since there are file-level conflicts; otherwise, the files from libelogind0 would vanish. > Maybe libelogind0 should install into a different directory, and use > maintainer scripts (perhaps involving dpkg-divert) to get itself to be > loaded instead of libsystemd, so that it doesn't have to have file-level > conflicts with libsystemd at all? Might be a path worth looking at, but… > Maybe libelogind0 should have (Conflicts or) Breaks on libpam-systemd and > systemd-sysv, but not on systemd, because packages that depend on a > working systemd-logind are meant to depend on libpam-systemd and not just > systemd? … just like this one, both won’t _really_ work: they’d allow the installation to continue, but the system is not rebootable afterwards either. We cannot even use a Pre-Depends on a non-systemd init, because… see below. > The only way I have managed to migrate systems reasonably cleanly is to boot > with init=/bin/sh, replace systemd with whatever else and then reboot again. > But > as you point out, that is not the obvious migration route that a normal > sysadmin > might take. > > The problem is that the route recommended in #930105 (et al.) is to first > install sysvinit-core, reboot and then remove systemd. The first step of this > will require removal of almost the entire GUI environment -- something few > would > persist with even though it could all be reinstalled later. Hmm, interesting… had not thought of that (you’d probably have to do that on systems before installing anything desktop-y, or use my unofficial packages in the middle). But TTBOMK it is possible to install sysvinit alongside systemd, then reboot and select sysvinit as “alternative” init from the GRUB menu, then remove everything else. Now that I see /sbin/init is part of sysvinit-core, I wonder if this is really possible any more and, if not, why not… packages are not supposed to depend on systemd-sysv… (but, ouch, libpam-systemd does). On the other hand, libpam-systemd Provides logind, so I guess it is one of the packages replaced by elogind. So some kind of transition and cross-package/maintainerscript communication is needed. And no matter what route is chosen, something will always break in an intermediate state (even the Depends from libpam-systemd on systemd-sysv will not ensure that systemd is actually the init system currently running, or used at next boot). This bears more thought. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Simon, Thanks for this. I was aware of this in the sense that I know systemd can't be uninstalled whilst it is PID 1. Most recently this was discussed in #930105 and tagged wontfix. The only way I have managed to migrate systems reasonably cleanly is to boot with init=/bin/sh, replace systemd with whatever else and then reboot again. But as you point out, that is not the obvious migration route that a normal sysadmin might take. The problem is that the route recommended in #930105 (et al.) is to first install sysvinit-core, reboot and then remove systemd. The first step of this will require removal of almost the entire GUI environment -- something few would persist with even though it could all be reinstalled later. On Sun, Aug 11, 2019 at 03:31:00PM +0100, Simon McVittie wrote: > Possible solutions: > > (I don't know which of these would be helpful, I'm just speculating...) These are useful, thank you. I will experiment and see. Mark
Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing
Package: libelogind0
Version: 241-7
Severity: important
Found while preparing a test VM to test #923240. Please raise this to
RC severity if you think it is justified - I don't want to create the
impression that I'm using RC bugs as a way to push an agenda, but I think
this might deserve critical severity, since it breaks the most obvious
migration path from systemd-logind to elogind, in a way that makes it
hard to recover.
Preconditions:
* A relatively minimal VM where libpam-systemd was installed
by autopkgtest's /usr/share/autopkgtest/setup-commands/setup-testbed,
resembling the result of autopkgtest-build-qemu(1) (I also installed
sudo and openssh-server but they shouldn't be relevant here)
Steps to reproduce:
* apt install sysvinit-core elogind libelogind0
(I had to list all of these packages explicitly for apt to find a
solution, but I don't think that's a bug. Nobody should be switching
from the default logind to elogind without making it clear that they
specifically want that.)
Expected result:
* systemd-sysv is removed
* sysvinit-core and elogind are installed
* the system continues to work
* after a reboot, the system comes up with sysvinit as pid 1, after which
I can remove the systemd package if I want to
Actual result (transcript below):
* systemd-sysv is removed
* sysvinit-core is unpacked
* systemd is also removed
* systemd's prerm fails because it is still the active init system
(this check is present since Debian systemd commit c3f5f249 in 44-6,
released in 2012 - it appears the intention is that anyone wishing to
switch from systemd to sysvinit should replace systemd-sysv with
sysvinit-core, then reboot into sysvinit, and only (auto)remove
systemd after that reboot)
* libsystemd0 is removed anyway
* libelogind0 is not installed yet
* libsystemd.so.0 does not exist
* executables with DT_NEEDED on libsystemd.so.0, notably apt, cannot run
* recovering from this situation is not straightforward
Possible solutions:
(I don't know which of these would be helpful, I'm just speculating...)
Maybe libelogind0 and elogind would be better off having Breaks (inverse
Depends) relationships with their systemd equivalents, instead of
Conflicts (inverse Pre-Depends) which are maybe too strong?
Maybe libelogind0 should install into a different directory, and use
maintainer scripts (perhaps involving dpkg-divert) to get itself to be
loaded instead of libsystemd, so that it doesn't have to have file-level
conflicts with libsystemd at all?
Maybe libelogind0 should have (Conflicts or) Breaks on libpam-systemd and
systemd-sysv, but not on systemd, because packages that depend on a
working systemd-logind are meant to depend on libpam-systemd and not just
systemd?
Some coordination with the systemd maintainers is likely to be necessary
to make sure this works as gracefully as possible, does not leave the
system in a broken state if the migration fails, and does not result in
unsupportable combinations of packages (like libpam-systemd + libelogind0)
being installable.
Regards,
smcv
root@host:~# dpkg-query -W | grep systemd
libnss-systemd:amd64241-7
libpam-systemd:amd64241-7
libsystemd0:amd64 241-7
systemd 241-7
systemd-sysv241-7
root@host:~# apt install sysvinit-core elogind libelogind0
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
initscripts insserv psmisc startpar sysv-rc
Suggested packages:
bootchart2 bootlogd
Recommended packages:
policykit-1
The following packages will be REMOVED:
libnss-systemd libpam-systemd libsystemd0 systemd systemd-sysv
The following NEW packages will be installed:
elogind initscripts insserv libelogind0 psmisc startpar sysv-rc
sysvinit-core
0 upgraded, 8 newly installed, 5 to remove and 9 not upgraded.
Need to get 1461 kB of archives.
After this operation, 11.3 MB disk space will be freed.
Do you want to continue? [Y/n]
Get:1 http://deb.debian.org/debian sid/main amd64 insserv amd64 1.20.0-2 [68.5
kB]
Get:2 http://deb.debian.org/debian sid/main amd64 startpar amd64 0.63-1 [22.3
kB]
Get:3 http://deb.debian.org/debian sid/main amd64 sysv-rc all 2.95-4 [71.4 kB]
Get:4 http://deb.debian.org/debian sid/main amd64 initscripts amd64 2.95-4
[96.0 kB]
Get:5 http://deb.debian.org/debian sid/main amd64 sysvinit-core amd64 2.95-4
[151 kB]
Get:6 http://deb.debian.org/debian sid/main amd64 libelogind0 amd64
241.3-1+debian1 [224 kB]
Get:7 http://deb.debian.org/debian sid/main amd64 elogind amd64 241.3-1+debian1
[701 kB]
Get:8 http://deb.debian.org/debian sid/main amd64 psmisc amd64 23.2-1+b1 [126
kB]
Fetched 1461 kB in 1s (2056 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_GB.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot
