Bug#1015015: unable to upgrade due to elogind vs systemd conflict

[Craig Sanders]

Package: elogind
Version: 246.9.1-1+debian1

I don't know if a newer version of elogind would help here, but it
probably wouldn't hurt. elogind in debian hasn't been updated since
Dec 23.

# apt -u dist-upgade
[...]
The following packages will be REMOVED:
alsa-firmware-loaders bluez brasero fwupd gnome-disk-utility
gnome-session-bin gvfs gvfs-backends gvfs-daemons i2c-tools kpartx
lcdproc libblockdev-mdraid2 libtss2-esys-3.0.2-0 libtss2-mu0
libtss2-sys1 libtss2-tcti-cmd0 libtss2-tcti-device0 libtss2-tcti-mssim0
libtss2-tcti-swtpm0 linux-image-5.16.0-6-amd64 linux-image-5.17.0-3-amd64
linux-image-5.18.0-2-amd64 linux-image-amd64 mdadm tpm-udev udisks2
upower xfce4-power-manager xfce4-power-manager-plugins xserver-xorg
xserver-xorg-input-evdev xserver-xorg-input-kbd xserver-xorg-input-mouse

Most of those I don't care about, but I really don't want linux-* packages or
mdadm or xserver-* packages to be force-removed.


Aborting that and running 'apt upgrade' just highlights the cause:

# apt -u upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
elogind : Conflicts: systemd
Conflicts: systemd:i386
libelogind0 : Conflicts: libsystemd0
Conflicts: systemd
Conflicts: systemd:i386
E: Broken packages




systemd creeps ever closer to de-facto Essential status in debian,
contradicting promises made during the init systems vote years
ago (but we always knew that the systemd pushers were lying about
that). Something in recent sid systemd depends directly on systemd,
conflicting with elogind and forcing removal of several packages with
dist-upgrade.

I gave up resisting the systemd borg years ago, except on this one
machine: every attempt to switch it over to systemd has failed - IT
WILL NOT BOOT AT ALL WITH SYSTEMD, so it has to stay on sysvinit.
Looks like that's not going to be viable any longer.

and the worst of it is that systemd actually makes a fairly decent
init system - nothing ground-breaking or innovative but certainly
adequate. As init, it's good enough. It's all the other things that
it attempts to borg (and does a shitty half-arsed job of) that are
the problem: logind, policy kit, journald, shitty replacements for
ntp, dns resolver, grub, and much more. systemd would be OK if it
wasn't trying to do things an init system has no business doing, if
you didn't have to carefully check it on every upgrade to disable the
next thing it's incompetently trying to take over.



craig

[Mark Hindley]

Craig,

Thanks for this.

What release are you upgrading from an to?

On Sat, Jul 16, 2022 at 06:34:35PM +1000, Craig Sanders wrote:
> Package: elogind
> Version: 246.9.1-1+debian1
>
> I don't know if a newer version of elogind would help here, but it
> probably wouldn't hurt. elogind in debian hasn't been updated since
> Dec 23.
>
> # apt -u dist-upgade
> [...]
> The following packages will be REMOVED:
> alsa-firmware-loaders bluez brasero fwupd gnome-disk-utility
> gnome-session-bin gvfs gvfs-backends gvfs-daemons i2c-tools kpartx
> lcdproc libblockdev-mdraid2 libtss2-esys-3.0.2-0 libtss2-mu0
> libtss2-sys1 libtss2-tcti-cmd0 libtss2-tcti-device0 libtss2-tcti-mssim0
> libtss2-tcti-swtpm0 linux-image-5.16.0-6-amd64 linux-image-5.17.0-3-amd64
> linux-image-5.18.0-2-amd64 linux-image-amd64 mdadm tpm-udev udisks2
> upower xfce4-power-manager xfce4-power-manager-plugins xserver-xorg
> xserver-xorg-input-evdev xserver-xorg-input-kbd xserver-xorg-input-mouse
>
> Most of those I don't care about, but I really don't want linux-* packages or
> mdadm or xserver-* packages to be force-removed.

I can't immediately see the package that might be causing the conflict here.

> Aborting that and running 'apt upgrade' just highlights the cause:
>
> # apt -u upgrade
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Calculating upgrade... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
> elogind : Conflicts: systemd
> Conflicts: systemd:i386
> libelogind0 : Conflicts: libsystemd0
> Conflicts: systemd
> Conflicts: systemd:i386
> E: Broken packages

AFAIK this should still work, but apt might need a bit of help to find the
solution you want: it uses the first/default option which can lead it down the
systemd route.

My suggestions:

- Ensure you have the correct apt sources and remove any pinning or held
packages.

- apt update

- Manually install the new elogind, libelogind and libpam-elogind.

- apt upgrade

- apt dist-upgrade

If you find apt is trying to install systemd at any of these steps, we need to
identify the package that has a hard systemd dependency and deal with it.

HTH. Let me know how you get on.

Mark

[Craig Sanders]

On Sat, Jul 16, 2022 at 10:00:27AM +0100, Mark Hindley wrote:
> What release are you upgrading from an to?

Version of what? There's no new version of elogind. That's kind of what my
bug report is asking for.

The machine is running sid, so this was just a routine dist-upgrade.

> On Sat, Jul 16, 2022 at 06:34:35PM +1000, Craig Sanders wrote:
>
> I can't immediately see the package that might be causing the conflict here.

A little more investigation reveals that it's udev.

udev 2.51.3-1 (Wed, 13 Jul 2022 23:05:40 +0200) now depends on 'systemd | systemd-tmpfiles'.

The previous version of udev, 251.2-7 (Tue, 28 Jun 2022 14:33:37 +0200) did NOT.

Package: udev
Version: 251.3-1
Depends: libacl1 (>= 2.2.23), libblkid1 (>= 2.37.2), libc6 (>= 2.33), libcap2 (>= 1:2.10), libkmod2 (>= 5~), libselinux1 (>= 3.1~), systemd | systemd-tmpfiles, adduser, libudev1 (= 251.3-1)

Package: udev
Version: 251.2-7
Depends: libacl1 (>= 2.2.23), libblkid1 (>= 2.37.2), libc6 (>= 2.33), libcap2 (>= 1:2.10), libkmod2 (>= 5~), libselinux1 (>= 3.1~), adduser, libudev1 (= 251.2-7)


Yep. So much for the "systemd will never be mandatory in Debian"
promises. What a surprise! Debian's systemd zealots haven't even been
pretending they meant that for years now. It was discarded almost as soon as
they no longer needed it to get enough votes.

udev may not be flagged as "Essential: yes" but it is not an optional
package. Certainly not on a machine with X installed - xserver-xorg-core,
pulse-audio and about 100 other packages depend on it directly.

> > Aborting that and running 'apt upgrade' just highlights the cause:
> >
> > # apt -u upgrade

> > [...]

> >
> > The following packages have unmet dependencies:
> > elogind : Conflicts: systemd
> > Conflicts: systemd:i386
> > libelogind0 : Conflicts: libsystemd0
> > Conflicts: systemd
> > Conflicts: systemd:i386
> > E: Broken packages
>
> AFAIK this should still work, but apt might need a bit of help to find the
> solution you want: it uses the first/default option which can lead it down the
> systemd route.

Nope, it doesn't. udev depends on systemd now. There is no alternative.

> My suggestions:
>
> - Ensure you have the correct apt sources and remove any pinning or held
> packages.

My apt sources are fine - pointing at sid in my own local debian mirrors (i've
been mirroring debian since the 90s).

The only relevant held packages are sysvinit related. If I unhold them, then
'apt dist-upgrade' just offers to remove them and install systemd instead.

> - apt update

> - Manually install the new elogind, libelogind and libpam-elogind.

Unless it was released today, there is no new debian package of elogind. or
related packages. That's still 246.9.1-1+debian1 as it has been since Dec 23
2020.

I've been running apt update and then trying upgrade or dist-upgrade for the
last few days and getting the same result, hoping a new version of elogind
will be released. And then I realised that's probably not going to happen
until someone files a bug report.

> - apt upgrade
>
> - apt dist-upgrade
>
> If you find apt is trying to install systemd at any of these steps, we need to
> identify the package that has a hard systemd dependency and deal with it.


> HTH. Let me know how you get on.

I'm going to make another attempt to switch this machine to systemd. It's
been at least two years since I last tried. Hopefully it will either work or
I'll be able to revert back to sysvinit (I've been able to do so in the past,
but it's always been a PITA chore).

Much as I loathe the way systemd steadily absorbs more and more stuff that has
nothing to do with init, it does make a decent init system as long as I can
disable all the unwanted bullshit.

This machine would have been switched to systemd years ago if systemd was
actually capable of booting it. Having to maintain one machine that's
different from all my other machines is a PITA...a bigger PITA than the
constant vigilance against systemd's encroachments.

And, no, there's nothing unusual about this machine. It's an AMD FX 8150 on an
Asus Sabertooth 990FX motherboard. I have another identical motherboard with
an AMD Phenom II 1090T which runs systemd without a problem. And it's not the
FX 8150 CPU - this machine used to have an identical 1090T CPU, and systemd
wouldn't boot on it back then either.


craig

--
craig sanders <c...@taz.net.au>

[Adam Borowski]

On Sat, Jul 16, 2022 at 11:07:47PM +1000, Craig Sanders wrote:
> The machine is running sid, so this was just a routine dist-upgrade.
>

> > I can't immediately see the package that might be causing the conflict here.
> A little more investigation reveals that it's udev.
>
> udev 2.51.3-1 (Wed, 13 Jul 2022 23:05:40 +0200) now depends on 'systemd | systemd-tmpfiles'.

Just do:
apt dist-upgrade systemd-

That will let apt find the solution where it install systemd-tmpfiles but no
systemd itself.

The _correct_ way would be to write that dependency as
'systemd-tmpfiles | systemd' which is no-op on systemd installs but
avoids init switch elsewhere.

> I'm going to make another attempt to switch this machine to systemd. It's
> been at least two years since I last tried.

Don't. My primary desktop is in the same situation, and it appears I risk
physical damage(!) whenever I attempt to boot systemd.

> And, no, there's nothing unusual about this machine. It's an AMD FX 8150 on an
> Asus Sabertooth 990FX motherboard. I have another identical motherboard with
> an AMD Phenom II 1090T which runs systemd without a problem. And it's not the
> FX 8150 CPU - this machine used to have an identical 1090T CPU, and systemd
> wouldn't boot on it back then either.

AMD Threadripper+ 2990WX here.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ How to squander your resources: those silly Swedes have a sauce
⢿⡄⠘⠷⠚⠋⠀ named "hovmästarsås", the best thing ever to put on cheese, yet
⠈⠳⣄⠀⠀⠀⠀ they waste it solely on mere salmon.

[Mark Hindley]

Craig,

Thanks.

On Sat, Jul 16, 2022 at 11:07:47PM +1000, Craig Sanders wrote:

> A little more investigation reveals that it's udev.
>
> udev 2.51.3-1 (Wed, 13 Jul 2022 23:05:40 +0200) now depends on 'systemd | systemd-tmpfiles'.

Great. systemd-tmpfiles is a virtual package that is also provided by
systemd-standalone-tmpfiles. If you manually install that, I suspect you will find
everything is OK again.

Mark

[Lorenzo]

Hi Craig,

On Sat, 16 Jul 2022 23:07:47 +1000
Craig Sanders <c...@taz.net.au> wrote:

> A little more investigation reveals that it's udev.
>
> udev 2.51.3-1 (Wed, 13 Jul 2022 23:05:40 +0200) now depends on
> 'systemd | systemd-tmpfiles'.
>

Try to install the systemd-standalone-tmpfiles package first, then run
the upgrade as usual. It should work.

Lorenzo

[Mark Hindley]

Adam,

On Sat, Jul 16, 2022 at 03:32:55PM +0200, Adam Borowski wrote:
> The _correct_ way would be to write that dependency as
> 'systemd-tmpfiles | systemd' which is no-op on systemd installs but
> avoids init switch elsewhere.

Thanks. That is a good suggestion.

Michael,

I know this issue was raised a few days ago in #1014805 and you rejected any
change, but, as they stand, the udev dependencies are causing problems to users
and apt does not readily find the solution which avoids switching init system.

In your rejection of #1014805 you correctly asserted the first alternative in a
dependency should be a real package. So, perhaps

systemd-standalone-tmpfiles | systemd-tmpfiles

would satisfy the Policy requirements and not produce unexpected behaviour for
users? On systemd systems it would be noop as systemd provides systemd-tmpfiles
and it would avoid trying to install systemd on non-systemd systems which then
causes conflicts with elogind.

What do you think?

Thanks for your consideration.

Best wishes

Mark

[Craig Sanders]

Thanks, I have just tried that and it seems to work.

Perhaps elogind should Suggest or Recommend systemd-standalone-tmpfiles?



BTW, I had already installed systemd, but hadn't rebooted yet, before I
saw this, but (after examining /var/log/dpkg.log to find out exactly which
packages had been removed because of that), running the following reverted my
system back to the way it was before.

apt-get install systemd-standalone-tmpfiles sysvinit-core elogind

and, of course:

apt-mark hold sysvinit-core

To prevent systemd from being auto-installed in some future upgrade.


indra:/var/log# grep -E ' (remove|purge) ' dpkg.log
2022-07-16 17:05:39 startup packages remove
2022-07-16 17:05:39 remove libelogind0:amd64 246.9.1-1+debian1 <none>
2022-07-16 17:05:39 remove elogind:amd64 246.9.1-1+debian1 <none>
2022-07-16 17:05:41 startup packages remove
2022-07-16 17:05:41 remove sysvinit-core:amd64 3.03-1 <none>
2022-07-16 17:05:42 startup packages remove
2022-07-16 17:05:43 remove libpam-elogind:amd64 246.9.1-1+debian1 <none>
2022-07-16 17:05:44 startup packages remove
2022-07-16 17:05:44 remove libpam-elogind-compat:amd64 1.3 <none>

craig

[Thorsten Glaser]

On Sun, 17 Jul 2022, Craig Sanders wrote:

> and, of course:
>
> apt-mark hold sysvinit-core
>
> To prevent systemd from being auto-installed in some future upgrade.

You most likely want some pinning. Just held in dpkg or even marked
as XB-Important: yes often brings apt to tears in sid, i.e. refusing
to dist-upgrade at all.

Check the prevent-* packages in
http://www.mirbsd.org/~tg/Debs/dists/sid/wtf/Pkgs/mirabilos-support/
for inspiration. (I’ve moved from sid to bullseye though, so they
only get very mild testing in a chroot, and not with the latest
shenanigans yet.)

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

[Craig Sanders]

On Sun, Jul 17, 2022 at 04:01:38AM +0200, Thorsten Glaser wrote:
> On Sun, 17 Jul 2022, Craig Sanders wrote:
>
> > and, of course:
> >
> > apt-mark hold sysvinit-core
> >
> > To prevent systemd from being auto-installed in some future upgrade.
>
> You most likely want some pinning.

I've never found pinning to be of much use. When I did have an actual use for
it (many years ago, during the gnome 2 -> gnome 3 transition), it required
constant work and tweaking of the pinning rules to get it to do what I
wanted. Far more work than it was worth - I ended up just purging gnome and
switching to xfce instead.

Having `APT::Default-Release "unstable";` is enough for my needs. That allows
me to run sid and cherry pick a few things (mostly nvidia-kernel-dkms and
friends) from experimental. With that default release, apt will only install
from unstable unless I explicitly force it to with `-t experimental`. Works
for me.

Or `APT::Default-Release "stable";` allows a system to run stable and
cherry-pick from testing/sid/experimental plus backports as needed.

> Just held in dpkg or even marked as XB-Important: yes often brings apt to
> tears in sid, i.e. refusing to dist-upgrade at all.

Yeah, but I **want** apt to chuck a wobbly, it alerts me to the fact that
there are problems that need manual intervention and/or that I need to wait
a few days/weeks for updated packages. I don't run a dist-upgrade every day
anyway, so waiting is no big deal.

[Thorsten Glaser]

On Sun, 17 Jul 2022, Craig Sanders wrote:

> > You most likely want some pinning.
>
> I've never found pinning to be of much use. When I did have an actual use for

[…]

No, not that. You need it to get apt to not even consider systemd
installable.

> wanted. Far more work than it was worth - I ended up just purging gnome and
> switching to xfce instead.

That anyway.

> Having `APT::Default-Release "unstable";` is enough for my needs. That allows

[…]

> Or `APT::Default-Release "stable";` allows a system to run stable and
> cherry-pick from testing/sid/experimental plus backports as needed.

No, not that. See above and below.

> > Just held in dpkg or even marked as XB-Important: yes often brings apt to
> > tears in sid, i.e. refusing to dist-upgrade at all.
>
> Yeah, but I **want** apt to chuck a wobbly, it alerts me to the fact that
> there are problems that need manual intervention and/or that I need to wait

Nope. These are things apt could, in theory, solve by itself but cannot
because it can only consider one solution but that’s uninstallable. By
forcing it to not even consider systemd by pinning it down to -1 you get
apt to consider an alternative solution instead.

In pbuilder, I pin down dconf-gsettings-backend for example, so it gets
gconf-gsettings-backend instead, which works without systemd. (Not that
this is actually used during the building, but dependencies are gonna
depend.)

bye,
//mirabilos
--
<diogenese> Beware of ritual lest you forget the meaning behind it.
<igli> yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.