Solved: Issue with systemd-235 package in Main-Testing repo

This occurred on 2 different computers (hardware not vbox). When I installed the packages in this list at some point my screen stated rapidly flashing and computer became unresponsive. I always enable Magic Sys/Require keys so I used that sequence to halt and reboot computer. After rebooting I then finish the package installation which did include more packages and rebooted which led to a black screen with mouse cursor. So I rebooted again and now on both computers all appears to be normal.

These are the first packages installed, all but zsh are from Main-testing repo.

$ rpm -qa --last | more
glibc-devel-2.26-9-omv2015.0.x86_64           Mon 23 Oct 2017 05:05:34 PM CDT
systemd-235-2-omv2015.0.x86_64                Mon 23 Oct 2017 05:05:13 PM CDT
zsh-5.3.1-1-omv2015.0.x86_64                  Mon 23 Oct 2017 05:05:12 PM CDT
libc6-2.26-9-omv2015.0.x86_64                 Mon 23 Oct 2017 05:05:11 PM CDT
lib64systemd0-235-2-omv2015.0.x86_64          Mon 23 Oct 2017 05:05:11 PM CDT
lib64nss_myhostname2-235-2-omv2015.0.x86_64   Mon 23 Oct 2017 05:05:11 PM CDT
systemd-bash-completion-235-2-omv2015.0.x86_64 Mon 23 Oct 2017 05:05:09 PM CDT
glibc-2.26-9-omv2015.0.x86_64                 Mon 23 Oct 2017 05:05:09 PM CDT
systemd-zsh-completion-235-2-omv2015.0.x86_64 Mon 23 Oct 2017 05:05:08 PM CDT

Mind that I’m not complaining If one chooses to test packages then one gets to deal with stuff like this occasionally. Just reporting as I would not like to see an update experience like this make it to public repositories.

So I tried splitting the packages and just installing the libc6/glibc packages, rebooting, that went OK then installing the systemd 235 packages and that crashed my system with the rapidly flashing screen and it would not reboot giving kernel panic error.

I’m not sure the systemd packages are OK to install but not sure why. So far I just know what is reported above.

To be fair the systemd packages do seem to work once they are installed. But installing them is scary and does seem like it could possibly break a system.

So far I’ve tried 3 times updating these and twice it worked as described in my first post and once it broke the system I was working on. Was able to fix it by going elsewhere and mounting/chrooting into system and downgrading systemd packages to 234 version.

Systemd was not tested by me, had no time for it.

As I understand it right, after updating systemd, your system crashed?

Can you provide logs?

Wasn’t expecting a problem so I wasn’t thinking log when I was working with the package.
So after the fact and in the wee hours of the morning I got some journalctl boot logs and I also got omv-bug-report.log.txt (547.2 KB)
<a class=“attachment” href="/uploads/default/original

journalctl-b-0.txt (326.8 KB)

journalctl-b-1.txt (201.9 KB)

journalctl-b-2.txt (281.2 KB)
<a class=“attachment” href="/uploads/default/original

/2X/2/276ea8db17ca44580d1ad6e816b9b166ef669b41.txt">journalctl-b-3.txt (819.5 KB)

I think journalctl -b -1 logs might be most interesting.

If there are different logs needed or a better way to do this I’ll try and do it. There are very many way to gather logs grasshopper.

Just thought about graphic logs like Xorg.0.log but I’ve got to get some sleep!

I do have a computer set up with the main-updates packages so can test this again if there are any suggestion on how to better collect information.

Wonder if I could get a screen-shot of the rapidly flashing screen. That would be wild!

Edit: Back to sleep for a bit.

Narrow down the install of about 7 packages some of which are involved in this problem to journalctl-b-3.txt (819.5 KB)

If you use line numbers in kwrite you’ll see the packages are installed (and system crashes) starting at line 5041 in here:journalctl-package-install.txt (17.5 KB)

Hope this helps something.If not it will help get to logs that can help though right!

This is very interesting:

Oct 23 17:05:16 openmandriva sddm[3991]: /usr/bin/xauth: (stdin):1:  bad "remove" command line
Oct 23 17:05:16 openmandriva sddm[3991]: /usr/bin/xauth: (stdin):2:  bad "add" command line
Oct 23 17:05:16 openmandriva sddm[3991]: QProcess: Destroyed while process ("/usr/libexec/sddm-helper") is still running.
Oct 23 17:05:16 openmandriva acpid[3838]: client 7257[0:0] has disconnected

Looks like updating systemd, does kill dbus session and that’s why some X stuff goes crazy.

I saw that and thought I should get that posted here as that happens mere seconds after the first ‘system’ packages are installed and at about exactly when system crashes.

Edit: And I should emphasize that after the above happens computer becomes completely unresponsive. Applications that were open might work for a while but nothing you close and no new applications will work at all.

Please try systemd-235-3 and dbus 1.10.24-4.

make sure you installed all the dbus packages first

On My most recent test today I did that, installed first new glibc/libc6, then dbus packages, then all in the systemd group I could except for systemd and 2 lib64 packages that won’t install separately. System crashes apparently after the packages including systemd are installed. When I reboot everything works OK. So I have 2 computers with the new systemd-235 package stack (and new glibc/libc6 and dbus) and they work fine after you get past the install crash. :roll_eyes:

Discovered that to reproduce the crash is very easy:

# urpmi --replacepkgs systemd

Works every time. Guess that means that I’ve narrowed it down to specifically systemd itself is causing the install crash. :thinking:

There’s new set of packages:

# rpm -qa | grep systemd

but does not fix install crash. Otherwise they seem to work OK.

Edit: FWIW: lib64udev1-235-3 and lib64nss_myhostname2-235-3 seem to go with this group of packages.

I have feeling this issue is related to *.busname files, which has been removed from 235 release.


I’ll ask upstream how to solve this.

Filled bug here

OpenSuse have the same issue

I’ve prepared systemd-235-4.
@ben79 Can you please try with above version. Thanks.

Yes it installed okl just a couple of non-consequential error messages. The update was started with urpmi --auto-update.
Once systemd was installed urpmi got more files and istalled them.
I am writing this just afterward on the same system without a reboot so all appears to be well.

Here I have same problem but also systemd itself didn’t finish installing so I have to go to another partition and mount and chroot into it to finish install. Is it possible this is related to intel graphics? Or is it possible this is because I removed microcode-intel?

Edit: Also lib64systemd0-234 was not removed before crash so I had lib64systemd0-234 and lib64systemd0-235 until I removed the former, older package.

It worked for me Ben how odd. Was the latest glibc update installed at the same time by any chance?

Latest glibc is already on ISO and is installed by default.