systemd upgrade makes the system unbootable (because of dbus ?)

[louispolaire]

Hi,

For one week approx, everytime I try to dist-upgrade systemd (or some related packages, see below) my system becomes unbootable and I have the following error in loop :

systemd[some number]: Job dbus.socket/start deleted to break ordering cycle starting with sockets.target/start
systemd[some number]: Job dbus.socket/start deleted to break ordering cycle starting with sockets.target/start
systemd[some number]: Job dbus.socket/start deleted to break ordering cycle starting with sockets.target/start
systemd[some number]: Job dbus.socket/start deleted to break ordering cycle starting with sockets.target/start
etc...

here are the packages I have to upgrade :

Code: [Select]

# apt-show-versions -u                             :(
libsystemd-daemon0:amd64/unstable 204-6 upgradeable to 204-10
libsystemd-journal0:amd64/unstable 204-6 upgradeable to 204-10
libsystemd-login0:amd64/unstable 204-6 upgradeable to 204-10
network-manager:amd64/unstable 0.9.8.0-5 upgradeable to 0.9.8.10-1
phonon-backend-vlc:amd64/unstable 0.6.2-2 upgradeable to 0.7.1-1
systemd:amd64/unstable 204-6 upgradeable to 204-10
systemd-sysv:amd64/unstable 204-6 upgradeable to 204-10
Thanks to having siduction installed on a btrfs subvolume it is quite simple to come back to a previous snapshot of my system.
But I would'nt have this safety this bug would be very serious... the system is not bootable (not even possible to shutdown properly)
But I begin to wonder if it is my fault or the systemd package that is faulty.

Do you have some ideas ?

[dibl]

The new systemd packages came in a d-u some days ago, and caused no problems here.

Code: [Select]

root@imerabox:/# apt-cache policy systemd
systemd:
  Installed: 204-10
  Candidate: 204-10
  Version table:
     208-1 0
          1 http://ftp.us.debian.org/debian/ experimental/main amd64 Packages
 *** 204-10 0
        500 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages
        100 /var/lib/dpkg/status
     204-5.2 0
        500 http://packages.siduction.org/fixes/ unstable/main amd64 Packages

This is 64-bit KDE system with a BTRFS filesystem for data.  OS is on ext4.



Once, during the transition from sysvinit to systemd, there was a hangup/d-u problem that I was only able to fix by removing systemd and reinstalling sysvinit. Then I ran the d-u, and then I reinstalled systemd.  Possibly that is something you could try.

[melmarker]

looks like a problem with systemd-sysv - try to update the involved packages manually like this:

Code: [Select]

apt update
apt install libsystemd-daemon0
apt install libsystemd-journal0
apt install libsystemd-login0
apt install systemd
apt install systemd-sysv
apt install network-manager
apt install phonon-backend-vlc

if a error occurs at one point please post the error with the comlete output here. Hopefully this should work, i think the break in ordering cycle is from systemd-sysv. But thats only a wild guess.

[terroreek]

I have no problems either on two installations of 64-bit Gnome.  Do you have a custom service or running SELinux?  A quick google showed that a couple of people had a similar issues, because of either. 

[UP2L8]

I'm not using systemd at the moment, but I've read of some issues with the package in the past few weeks and I believe Linus Torvalds recently ranted about it.  I wonder if the Debian folks have made the best/right decision in going with it for the next stable release.

[melmarker]

We switched to systemd  some month before the ctte descision:  The reason was Gnome in first place and that we like systemd as our main init system. By the way - the descision was: We stay with systemd no matter what debian decide to go with.

That means:
 * we don't really care for sysinit - but we don't break it without reason.
 * we don't support sysinit as we have no manpower to do so.
 * with the debian descision for systemd its likely that there will be more problems with sysinit in future package versions. If one are willing to stay with sysvinit debian/stable is the best choice for the time being. But this will change when debian/stable will become debian/oldstable - so be prepared and have a good plan can help.

[devil]

I'm not using systemd at the moment, but I've read of some issues with the package in the past few weeks and I believe Linus Torvalds recently ranted about it.  I wonder if the Debian folks have made the best/right decision in going with it for the next stable release.

Why would Linus' ranting mean anything to Debian or to us. If you follow him and his rants, you need to switch your desktop environment twice a year. Linus' continued work on the kernel is great, his ranting totaly irrelevant to us.


greetz
devil

[titan]

Linus' continued work on the kernel is great, his ranting totaly irrelevant to us.

That seems a strange reply, his rant was about bugs introduced into systemd by the maintainer who didn't seem too bothered about fixing them.

[dibl]

That seems a strange reply, his rant was about bugs introduced into systemd by the maintainer ...

I read enough of the bugzilla thread to see that this is an example of the classic "bug or feature" argument.  If you ever worked around a team of software developers working on a large project, you have heard it all before.

[louispolaire]

Thanks for your replies.

@melmarker : I tried to install each package individually but that does not work. when I install libsystemd-daemon0, the rest of the packages (incudind systemd-sysv) are called as dependencies.

@dibl : I tried deinstalling systemd reinstalling sysvinit, d-u, reinstalling systemd, and it's all the same, the system does not boot with the same error I posted. and worst : no error message during install or d-u...

My system is running on dist-upgrades since "Riders on the Storm" I am begin to wonder if a clean install would be necessary...

Or maybe you have some other ideas ?

[dibl]

@dibl : I tried deinstalling systemd reinstalling sysvinit, d-u, reinstalling systemd, and it's all the same, the system does not boot with the same error I posted. and worst : no error message during install or d-u...

Do you mean you did a successful d-u (while configured with sysvinit)?  Did you install systemd v. 204-10?

EDIT:  This 2-year old bug report looks a bit like your error output -- it appears to relate to LSB headers and /etc/rcS or rc.d links.

[der_bud]

...

systemd[some number]: Job dbus.socket/start deleted to break ordering cycle starting with sockets.target/start
etc...

...Thanks to having siduction installed on a btrfs subvolume it is quite simple to come back to a previous snapshot of my system....

So I assume you can go back to a snapshot before dist-upgrade, but already on systemd (the version before DU)? Perhaps it is possible to look how dbus is started there and some dependencies, and if there are issues. From such a snapshot, could you provide here as a first step:

 1.  systemctl status dbus.service
 2.  journalctl -b -p err
 3.  systemd-analyze blame

and pastebinit /var/log/dmesg to a paste service?

[louispolaire]

Sorry I did not have time to take care of this problem so far. Now I do.

The problem is still unsolved.

I uninstalled systemd-sysv linux and installed sysvinit-core and I am able to upgrade the system as said before.

But whenever I reinstall systemd-sysv it does not boot. Everything goes well until systemd start, then I have those messages streaming on the screen as I described in my first post.

Sometime it seems the messages are different but my biggest problem now is that it's going too fast : I can't read them ! And as the problem occurs at the start of systemd, there is no journaling, so if I chroot into the broken system there is nothing on the journal concerning the last boot ...

The only thing I can guess is that there is a cycle between "some services" that cannot be solved, but when it come to reading the names I need bionic eyes of the power to stop time.

Do you know a way to stop the streaming of messages during the start of systemd or to record it somehow ? I find it very difficult to debug a system without logs...

[absolut]

with systemd there comes a journaling infrastructure: journalctl

journalctl -b
gives you the logs from the last boot...

[der_bud]

systemd[some number]: Job dbus.socket/start deleted to break ordering cycle starting with sockets.target/start
systemd[some number]: Job dbus.socket/start deleted to break ordering cycle starting with sockets.target/start
systemd[some number]: Job dbus.socket/start deleted to break ordering cycle starting with sockets.target/start
systemd[some number]: Job dbus.socket/start deleted to break ordering cycle starting with sockets.target/start
etc...

...wants to tell you that there seems to be a cyclic dependency during boot with dbus.socket and socket.target, and systemd interrupts that somehow in order to try to get along, leading in your case to an unbootable system. (In other cases, such messages are only informative if the system boots up proper, because such a cycle then could be resolved later).

If you manage to boot that system in multiuser.target (init3) or emergency.target, please give the outputs from the following five commands (*)

Code: [Select]

systemctl status dbus.target
systemctl status dbus.socket
systemctl status sockets.target

systemctl show dbus.socket
systemctl show sockets.target

To see if something hangs or is waiting for any external device or outsourced partition, please give also your /etc/fstab

 (*) Hint: the commands might show their ouput in a pager (less/more). If you want them directly on screen (or >direct them in a textfile or | to a paste service) you can use the option '--no-pager' like for example 'systemctl show sockets.target --no-pager' (two dashes - -)