You are not logged in.
Hey friends, for some reason, for the past several weeks, every time I run 'yay' and do a full upgrade, my sound card is briefly disabled and then re-enabled, and my tap-to-click functionality on my laptop trackpad seems to go away completely forcing a reboot to regain functionality. I'm not sure what exactly is being upgraded here that breaks the functionality, but I run a rather standard Plasma. The options for tap-to-click in settings are grayed out until reboot as well.
Anyone have any idea what could be happening here? Is there some systemd unit I need to bounce or something? I love tap to click and hate rebooting every day, so in spite of this being mostly a minor annoyance, I'd really love to figure this out
Offline
Systemd updates contain a hardware database that gets reloaded and might reset some HW in a weird state, there have been a bunch of fixes for systemd based initcpios which is why the updates here have been a tad frequent.
Offline
Ah gotcha. Hm, to prove that this is the cause, what can I manually reload and see if it disables the tap to click? I'm happy to reboot as a workaround but I prefer to do that as infrequently as truly necessary
Offline
It's either the HWDB or the udev hook or both: /usr/share/libalpm/hooks/30-systemd-udev-reload.hook and usr/share/libalpm/hooks/30-systemd-hwdb.hook which call a helper script to trigger the relevant action which is under /usr/share/libalpm/scripts/systemd-hook which then triggers
/usr/bin/systemd-hwdb --usr update
or
/usr/bin/udevadm control --reload; /usr/bin/udevadm trigger
depending on which of the two called it, I'd look at/check in that direction.
Offline
I'm getting this too. My mouse acceleration in KDE Plasma gets reset after updates. I'm also frequently not able to switch TTYs without a black screen.
I tested all the hooks in order, and I indeed narrowed it down to
/usr/share/libalpm/hooks/30-systemd-udev-reload.hook
which calls
/usr/share/libalpm/scripts/systemd-hook udev-reload
then
/usr/bin/udevadm control --reload; /usr/bin/udevadm trigger
I can confirm that the second of these, i.e. /usr/bin/udevadm trigger is enough to bork my system.
Presumably this trigger is necessary after an update, but just in case, are there any possible workarounds? I wonder if skipping this trigger is worth it?
EDIT: I also found this bug, but looks like that was fixed in 5.17.5, and we're now running 5.27.3-1
EDIT2: It looks like running kcminit will fix the mouse issues, but switching TTYs still breaks the system.
EDIT3: I think this also breaks automatic suspend.
Last edited by Salkay (2023-04-14 13:15:46)
Offline
Interesting. I'm facing a similar issue since "some days" which logs out my KDE session immediately after 30-systemd-udev-reload.hook got called. This happens only on my machine, no other affected for now which are all well-kept clone of my machine.
Offline
@Ojaksch I also had this problem, but I tracked it down to a bad keyboard xorg.conf. In my case, it had
Driver "evdev"
despite me not having xf86-input-evdev any more. Once I removed this line, it was all fine.
FWIW I found this by looking in /var/log/Xorg.0.log, which contained
[ 167.626] (II) LoadModule: "evdev"
[ 167.626] (WW) Warning, couldn't open module evdev
[ 167.626] (EE) Failed to load module "evdev" (module does not exist, 0)
[ 167.626] (EE) No input driver matching `evdev'
[ 167.626] (II) Falling back to input driver `libinput'
[ 167.626] (II) Using input driver 'libinput' for 'Power Button'
Offline
@Ojaksch I also had this problem, but I tracked it down to a bad keyboard xorg.conf. In my case, it had
Driver "evdev"
despite me not having xf86-input-evdev any more. Once I removed this line, it was all fine.
Damn, that's it! Thanks a lot! I had these line(s) in /etc/X11/xorg.conf.d/10-xinput.conf which has been with me since 2010...legacy issues.
Offline
Damn, that's it! Thanks a lot! I had these line(s) in /etc/X11/xorg.conf.d/10-xinput.conf which has been with me since 2010...legacy issues.
No worries! I was the same.
Hopefully some of the other issues have a similar cause.
Offline
This bug is freezing my system every day or two. What would the ramifications of skipping /usr/bin/udevadm trigger after updates?
FWIW it looks like the code has slightly changed. It's still
/usr/share/libalpm/hooks/30-systemd-udev-reload.hook
calling
/usr/share/libalpm/scripts/systemd-hook udev-reload
but now this script calls trigger slightly differently
udevd_live
/usr/bin/udevadm control --reload
/usr/bin/udevadm trigger
/usr/bin/udevadm settle
What would happen if I patched this file to skip /usr/bin/udevadm trigger? Or should I just skip the whole block?
Offline
Remove the trigger and the settle, keep the reload, which is also what I'm currently doing and adfing the file to NoUpgrade in /etc/pacman.conf and then compare the pacnews occasionally.
Last edited by V1del (2023-05-07 17:13:06)
Offline
Remove the trigger and the settle, keep the reload, which is also what I'm currently doing and adfing the file to NoUpgrade in /etc/pacman.conf and then compare the pacnews occasionally.
Thanks V1del. Could you please explain what effects this would have exactly? From your earlier comments, it is something to do with not reloading the hardware database?
Offline
The trigger leads to actively retriggering every udev rule (the reload in contrast simply reloads the rules so that they will be applied once an actual event happens for any given device, e.g. you actively plug a piece of HW) and reevaluating every single device registered in udev, depending on how your userspace reacts to a device disappearing for a short time this can have a variety of effects.
FWIW session freezes could also be due to bogus xorg configs still referencing the obsolete evdev driver, make sure to remove configs that hardcode an evdev device, check with
grep -R evdev /{etc,usr/share}/X11/xorg.conf*
see https://bbs.archlinux.org/viewtopic.php?id=285369 and https://bugs.archlinux.org/task/77789 for some rationale in the relevant change
Offline
depending on how your userspace reacts to a device disappearing for a short time this can have a variety of effects.
Thanks V1del. That's pretty weird then! So essentially trigger is replicating quickly unplugging then plugging in hardware, but for some reason this stuffs my system.
FWIW session freezes could also be due to bogus xorg configs still referencing the obsolete evdev driver, make sure to remove configs that hardcode an evdev device
Thanks again. The only relevant file I could find was /usr/share/X11/xorg.conf.d/10-quirks.conf, but this is owned by xorg-server anyway. FWIW the evdev references are only to the following, none of which are relevant for me.
Identifier "Xen Virtual Pointer axis blacklist"
...
Identifier "Tag trackballs as XI_TRACKBALL"
...
Identifier "Tag Mionix Naos 5000 mouse XI_MOUSE"
Offline
Hi! I seem to have the same issue, my KDE touchpad and mouse settings break with every update that uses the systemd-udev-reload hook.
I traced it to the udevadm trigger line in systemd-hook file. I'm running kcminit after each update to restore the settings. If it matters, I have a fresh installation (installed ~week ago), and there is no evdev module or legacy xorg configs on my side
Offline
adfing the file to NoUpgrade in /etc/pacman.conf and then compare the pacnews occasionally.
I did this when you suggested it, but for some reason the systemd update today still overwrote the file. Have I done something wrong, or did you notice the same thing?
In /etc/pacman.conf:
[options]
...
NoUpgrade = /usr/share/libalpm/scripts/systemd-hook
But after pacman -Syu, /usr/share/libalpm/scripts/systemd-hook was reverted back to the trigger version.
Offline
These files refer to files in the package archive, so do not include the
leading slash (the RootDir) when specifying them.
Last edited by Lone_Wolf (2023-06-06 10:04:51)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Oops. Thanks @Lone_Wolf.
Offline
Hi! I seem to have the same issue, my KDE touchpad and mouse settings break with every update that uses the systemd-udev-reload hook.
I traced it to the udevadm trigger line in systemd-hook file. I'm running kcminit after each update to restore the settings. If it matters, I have a fresh installation (installed ~week ago), and there is no evdev module or legacy xorg configs on my side
I think I too have the same issue, but it's a little strange. For starters I'm pretty sure it only happens in my wife's user. We share the laptop, we both use KDE, and the touchpad only seems to break in her user (I don't often use the laptop any more, so I can't be sure). This started as soon as I created her user, so it can't be due to any strange extra configurations in her home directory.
Also, running kcminit usually doesn't fix the issue. I have to run it many times for it to possibly take effect. Running udevadm trigger does break it though.
I also don't have any references to evdev except for:
$ cat /usr/share/X11/xorg.conf.d/10-quirks.conf
# Collection of quirks and blacklist/whitelists for specific devices.
# Accelerometer device, posts data through ABS_X/ABS_Y, making X unusable
# http://bugs.freedesktop.org/show_bug.cgi?id=22442
Section "InputClass"
Identifier "ThinkPad HDAPS accelerometer blacklist"
MatchProduct "ThinkPad HDAPS accelerometer data"
Option "Ignore" "on"
EndSection
# https://bugzilla.redhat.com/show_bug.cgi?id=523914
# Mouse does not move in PV Xen guest
# Explicitly tell evdev to not ignore the absolute axes.
Section "InputClass"
Identifier "Xen Virtual Pointer axis blacklist"
MatchProduct "Xen Virtual Pointer"
Option "IgnoreAbsoluteAxes" "off"
Option "IgnoreRelativeAxes" "off"
EndSection
# https://bugs.freedesktop.org/show_bug.cgi?id=55867
# Bug 55867 - Doesn't know how to tag XI_TRACKBALL
Section "InputClass"
Identifier "Tag trackballs as XI_TRACKBALL"
MatchProduct "trackball"
MatchDriver "evdev"
Option "TypeName" "TRACKBALL"
EndSection
# https://bugs.freedesktop.org/show_bug.cgi?id=62831
# Bug 62831 - Mionix Naos 5000 mouse detected incorrectly
Section "InputClass"
Identifier "Tag Mionix Naos 5000 mouse XI_MOUSE"
MatchProduct "La-VIEW Technology Naos 5000 Mouse"
MatchDriver "evdev"
Option "TypeName" "MOUSE"
EndSection
Offline
systemd was recently updated to 254.5-1. This includes the commit "support to opt-out from reloading udev rules. It seems if you create the file /etc/systemd/do-not-udevadm-trigger-on-update, then the problematic trigger and settle will be skipped.
Offline