Upgrade using pacman -Syu made system unusable

warmos9 · 2023-08-20 22:52:07

I have upgraded the system like I always do. After reboot, there is a problem with dbus.service. It cannot start, timeouts. Some user applications relying on dbus does not work (pulseaudio) or work but with limitations like no configuration saving (thunar)

I will attach the pacman.log with jounralctl output from the same time. There are some Permission denied messages, but the permissions look fine on the filesystem (read for all) for files like /usr/share/dbus-1/system.conf or others specified in the log file

The system I am running was installed about 8 years ago, so far I had no problem. There is more than 40G for ROOT filesystem, other filesystems has even more available space. Inodes are not even reaching 10% of capacity.

The logs are from time I've performed system update. Journalctl got crazy after systemd has been reinstalled (see pacman.log vs journalctl.log at the same time).

Can you please help me solving this issue? I do believe this is a bug in the newer systemd. I've tried compiling the systemd version 254.1 (version before 254.1-1 see: https://gitlab.archlinux.org/archlinux/ … e9625dd00) but that did fail in check(), see compile.log

Also attaching installed file, containing output of pacman -Qs

The files are attached here https://paste.c-net.org/XanaxImpure

seth · 2023-08-21 06:44:24

There were multiple EPERMs

Aug 20 12:07:46 saturn polkitd[29064]: Error opening rules directory: Error opening directory “/usr/share/polkit-1/rules.d”: Permission denied (g-file-error-quark, 2)
…
Aug 20 12:07:46 saturn dbus-daemon[818]: [system] Unable to reload configuration: Failed to open "/usr/share/dbus-1/system.conf": Permission denied

Those errors are then gone - did you "fix" that by making stuff world accessible?

stat /usr/share/dbus-1/system.conf /usr/share/polkit-1/rules.d

What shredded the permissions itfp?

However, there're also multiple instance of dbus-daemon running, what gets us to

Aug 20 16:16:11 saturn sudo[113321]:   warmos : TTY=pts/0 ; PWD=/home/warmos ; USER=root ; COMMAND=/usr/bin/vim /etc/X11/xinit/xinitrc.d/30-dbus-launch

wtf is that?
Do you have any of those issues when only booting the multi-user.target?

warmos9 · 2023-08-21 07:53:00

Hello,

seth wrote:

Those errors are then gone - did you "fix" that by making stuff world accessible?

I did NOT touch the permissions both before and after update. Permissions for those two locations seems okay (at least now), see bellow:

[root@saturn ~] $ ll /usr/share/polkit-1/rules.d/
total 48K
drwxr-x--- 2 root polkitd 4.0K Aug 20 21:08 .
drwxr-xr-x 4 root root    4.0K Aug 20 12:07 ..
-rw-r--r-- 1 root root     326 Jul 29 04:47 50-default.rules
-rw-r--r-- 1 root root     281 Aug  1 13:36 50-libvirt.rules
-rw-r--r-- 1 root root    1.5K May  1 21:36 com.endlessm.ParentalControls.rules
-rw-r--r-- 1 root root     557 Jun 30 03:05 gnome-control-center.rules
-rw-r--r-- 1 root root     182 Aug  5 04:19 org.a11y.brlapi.rules
-rw-r--r-- 1 root root     369 Jan  5  2023 org.freedesktop.bolt.rules
-rw-r--r-- 1 root root     769 Mar 17 02:32 org.freedesktop.Flatpak.rules
-rw-r--r-- 1 root root     287 Jan 28  2023 org.freedesktop.GeoClue2.rules
-rw-r--r-- 1 root root     595 Aug  6 14:14 org.gtk.vfs.file-operations.rules
-rw-r--r-- 1 root root     527 Aug  9 16:07 systemd-networkd.rules
[root@saturn ~] $ ll /usr/share/dbus-1/system.conf
-rw-r--r-- 1 root root 5.7K Aug 20 21:32 /usr/share/dbus-1/system.conf

I'm having wtf moments too, because I never faced something like temporary EPERM. The ROOT filesystem is on a NVMe, /home on classic HDD, there are no network locations.

seth wrote:

However, there're also multiple instance of dbus-daemon running, what gets us to

This was me trying to fix the problem. Sorry that it confused you. Dbus is able to launch using the command specified but only for user, not the system one. The dbus.service times out without any information in the journalctl.log. Also launching the dbus like that makes some applications work, but for example, pulseaudio is still not working. Also it does not solve the problem with dbus.service

seth wrote:

Do you have any of those issues when only booting the multi-user.target?

Actually yes. Since the dbus.service is not running, the session for user does not start, see log from today (but this is present in the journalctl.log too):

Aug 21 09:23:20 saturn systemd-logind[857]: Failed to start user service 'user@1000.service', ignoring: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=10000ms)
Aug 21 09:23:30 saturn systemd-logind[857]: Failed to start session scope session-1.scope: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=10000ms)
Aug 21 09:23:30 saturn login[985]: pam_systemd(login:session): Failed to create session: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=10000ms)
Aug 21 09:23:30 saturn login[985]: LOGIN ON tty1 BY warmos

I have read on the internet, that these errors were a bug in old systemd, but this should be fixed for a while: https://askubuntu.com/questions/1241017 … -timed-out

Also I have tried this, but it didn't help: https://forums.opensuse.org/t/dbus-syst … t/165577/7

seth · 2023-08-21 13:24:54

No, I meant "wtf is /etc/X11/xinit/xinitrc.d/30-dbus-launch"? Anything including the token "dbus-launch" is highly suspicious.

1. boot some live distro, and check the integrity of the installed system. Ideally you're using some arch system as you can then use the local pacman to check the installed system w/o having to chroot:

sudo LC_ALL=C pacman --root=/mnt -Qkk | grep -v ', 0 altered files'

2. really only boot the multi-user.target, or rather the rescue.target (2nd link below) and check the condition there
3. log in as root and try to run

/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only

warmos9 · 2023-08-22 19:38:56

Thank you so much for trying to help. Unfortunately, since I needed my computer for work, I had to reinstall. It's shame that I had to even reinstall it, like some Windows. It worked flawlesly for 8 years Anyway after reinstall everything is fine

Before reinstall I've tried your suggestion

sudo LC_ALL=C pacman --root=/mnt -Qkk | grep -v ', 0 altered files'

And there were no suspicious things like UID a GID mismatches. Not even a permission difference.

Running the dbus-daemon resulted in exit code 1 without any explanation.

Thank you again, this can be marked as solved or unsolved, I really don't know, how to tag this topic...

seth · 2023-08-22 19:46:50

You could report if for the dustbin as there's little value in it now, https://bbs.archlinux.org/misc.php?report=2116808
If you can, you could explain the /etc/X11/xinit/xinitrc.d/30-dbus-launch (it probably should not have been there and likely is no longer?)

Arch Linux

#1 2023-08-20 22:52:07

Upgrade using pacman -Syu made system unusable

#2 2023-08-21 06:44:24

Re: Upgrade using pacman -Syu made system unusable

#3 2023-08-21 07:53:00

Re: Upgrade using pacman -Syu made system unusable

#4 2023-08-21 13:24:54

Re: Upgrade using pacman -Syu made system unusable

#5 2023-08-22 19:38:56

Re: Upgrade using pacman -Syu made system unusable

#6 2023-08-22 19:46:50

Re: Upgrade using pacman -Syu made system unusable

Board footer