Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#77789 - [systemd] updating resets keyboard layout / udev reload

Attached to Project: Arch Linux
Opened by Dawid Potocki (dawidpotocki) - Thursday, 09 March 2023, 09:46 GMT
Last edited by Toolybird (Toolybird) - Saturday, 11 March 2023, 20:59 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Christian Hesse (eworm)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 27
Private No



I set my keyboard layout using `setxkbmap`, keyboard remaps using `xcape` and disable my trackpad using `xinput` in xinitrc; it all gets reset after a systemd update.

Got introduced by adding `/usr/bin/udevadm trigger` in this commit:

Steps to reproduce:

1. Update systemd
2. Cry while struggling to run the commands to fix your stuff
This task depends upon

Comment by Toolybird (Toolybird) - Thursday, 09 March 2023, 19:47 GMT
You don't reboot after updating systemd? There are some pkg updates where a reboot just seems naturally wise...kernel, glibc, systemd. The commit message doesn't explain the motivation for the change, but on face value it doesn't seem like much of a bug. Maybe you also need to "hook" your config changes somehow?
Comment by Christian Hesse (eworm) - Thursday, 09 March 2023, 20:20 GMT
Is there any reason you do not set the keyboard layout properly for the system, with `localectl`?
And the trackpad thing could be a udev rule...

Before the change we made udev reload the rules, but they were not applied. Now they are. That was important as udev from systemd 253 now creates device files that did not exist before, but are important for boot preparation and boot loader installation.
Comment by Dawid Potocki (dawidpotocki) - Thursday, 09 March 2023, 20:54 GMT
> Is there any reason you do not set the keyboard layout properly for the system, with `localectl`?
> And the trackpad thing could be a udev rule...

It allows me to dump it in my dotfiles without having to modify system files.

xcape still works
Comment by Michel Koss (MichelKoss1) - Saturday, 11 March 2023, 20:36 GMT
> You don't reboot after updating systemd? There are some pkg updates where a reboot just seems naturally wise...kernel, glibc, systemd

This hook runs not only when you update systemd but when anything that put files in /usr/lib/udev/rules.d/* updates.

There are dozens of such packages. See for another example.
Comment by Toolybird (Toolybird) - Saturday, 11 March 2023, 20:58 GMT
Dupe  FS#77815 
Comment by Tarqi Kazan (Tarqi) - Thursday, 23 March 2023, 20:46 GMT
Same here, all settings (keymap,key delay/rate, touchpad, autorandr, ...) are applied in .xinitrc which is used on multiple systems, so no explicit system settings are necessary and the config is portable. If there is another *portable* way, please let me know. Otherwise the whole xinit configuration using 'xset', 'setxkbmap', 'xinput set-prop ...' and so on would be broken and obsolete and the configuration much more complicated.
Comment by Gerry Kessler (renegat) - Tuesday, 04 April 2023, 14:57 GMT
I set the locale settings with localectl / xorg.d conf files and experience the same issue:
After everz rebuild of the initramfs the kezboard lazout is reset back to US

# localectl
System Locale: LANG=de_DE.UTF-8
VC Keymap: de
X11 Layout: de
X11 Model: pc105

# Written by systemd-localed(8), read by systemd-localed and Xorg. It's
# probably wise not to edit this file manually. Use localectl(1) to
# instruct systemd-localed to update it.
Section "InputClass"
Identifier "system-keyboard"
MatchIsKeyboard "on"
Option "XkbLayout" "de"
Option "XkbModel" "pc105"

Even 'loadkeys de-latin1' does not bring back german keyboard layout.
I|am not using .xinitrc to set locales!
Comment by Tarqi Kazan (Tarqi) - Tuesday, 04 April 2023, 15:19 GMT
@renegat: loadkeys is used for console only, try 'setxkbmap de'.
Comment by David Roth (V1del) - Wednesday, 05 April 2023, 11:30 GMT
There are quite a few weird behaviours possible from this in my case I always lose/reload audio devices for a split second and I've had a complete session crash once from kwin_wayland not being able to access the DRM device anymore/broken monitor setup from device names switching around.

@eworm do you have an example/commit ref where doing this is "necessary" for boot prep/bootloader config (... and by extension this will presumably only be relevant for systemd-boot?) It seems weird to me to trigger a logical reload of every single piece of HW just because something "might" have changed (... from presumably previously already working hardware). Leave that to - well - the actual boot or when the hardware actually changes due to being triggered/reconnected
Comment by Christian Hesse (eworm) - Wednesday, 05 April 2023, 12:02 GMT
IIRC this one required a rule reload (which we already did before), followed by a trigger:

The symlink was used and thus required in a userland tool shipped by systemd... Would have to look up the details myself.
Comment by Christian Hesse (eworm) - Wednesday, 05 April 2023, 12:27 GMT
I guess the complete session crash was caused by  FS#78097 ...
Comment by David Roth (V1del) - Wednesday, 05 April 2023, 13:13 GMT
That was a one time thing/potentially freak accident so I'd also not consider investigating too much there and I'm also hoping that got fixed by that (... though from looking at the logs there were definitely some issues with the DRM device/amdgpu), but just from a logic perspective it seems weird to me to retrigger everything (... FWIW another one I definitely had just yesterday is the following mkinitcpio initramfs rebuild not finding a certain device node -- which could lead to failure to boot from the non-fallback initramfs)

That last one might be some racyness that could be worked around with a bit of a sleep or so (or the --settle argument), though IMO the amount of potential side effects and breakage seems much higher than some userland tool crashing once for one specific systemd version/update/command.

Some more refs e.g. - this might be a plasma bug at the end of the day but could be avoided by not triggering udev reloads.
Comment by David Roth (V1del) - Thursday, 06 April 2023, 08:28 GMT
This definitely is also related to and this currently can actively break initramfs generation for people. If you want to keep the udevadm trigger, then please add --settle as an argument so that the devices are populated when mkinitcpio runs. There are a bunch of threads on the boards already where this actively breaks the boot for people.

Due to all of the potential side effects I'm personally still voting for not doing the explicit trigger unconditionally anyway, but is technically something that can be up to debate. Ensuring the devices are ready for mkinitcpio to work isn't.

Comment by Michel Koss (MichelKoss1) - Thursday, 06 April 2023, 16:21 GMT
Looks like the '--settle' option breaks something else:

I think the '/usr/bin/udevadm trigger' should be backed out. Requiring one time reboot after systemd 252 -> 253 update is minor issue in comparison with constant problem with updates and each day passed makes it even less relevant.
Comment by David Roth (V1del) - Wednesday, 03 May 2023, 17:25 GMT
Another case ... would we need to do a hard sleep due to udevadm settle being unreliable?
Comment by David Roth (V1del) - Wednesday, 10 May 2023, 16:02 GMT
For posterity's sake from the mkinitcpio gitlab:

I considered my personal go to for checking regarding this, but this really isn't just limited to session hangs or problems in mkinitcpio itself. While this has inadvertently uncovered that a bunch of people have old broken xorg evdev configs around that can get fixed by removing them, there are a bunch of other people where this leads to a variety of issues still. E.g.
to name a few.
Comment by Tom Englund (gulafaran) - Wednesday, 31 May 2023, 11:50 GMT
doesnt this technically break tlp/laptop mode tools aswell? you pull the cord on your laptop trigger an event and the scripts/tools changes the various device states and changes. while abroad you figure right i want neofetch. pacman -Syu neofetch , only this now brought in a package update that triggers the udev reload. and poof all your devices are now back in default state until another acpi event is triggered that you pulled the cord? . have not tested it myself but worth considering.
Comment by Alex (bidski) - Tuesday, 20 June 2023, 23:37 GMT
I also seem to be plagued by this issue. For me it manifests as a session logout (I get kicked out of my gnome session and returned to the gnome login screen). Depending on what packages are being installed this can leave me with no initramfs images and no vmlinuz-linux. I made a forum post here ( about my issues.
Comment by Pavel Kolesnikov (pkolesnikov) - Friday, 14 July 2023, 05:02 GMT
Any news on this? Symptoms gets quite annoying and the fix seems straightforward.
Comment by Toolybird (Toolybird) - Thursday, 27 July 2023, 20:08 GMT
Dupe  FS#79219 
Comment by Tarqi Kazan (Tarqi) - Saturday, 09 September 2023, 22:19 GMT
This gets more and more annoying, while it _might_ be ok for keyboard/mouse settings, there are cases where it is not, see previous comments. I also noticed that a pacman update that triggers the hook always wakes up the disks on my *headless* server, which should not happen. Please: Find a solution. Thanks.
Comment by Michel Koss (MichelKoss1) - Sunday, 17 September 2023, 12:53 GMT
The solution is known from the beginning: revert the change that causes this issue, linked in bug description. It was needed once on systemd 252->253 update and now it's perfectly safe to do drop it.
Comment by T.J. Townsend (blakkheim) - Sunday, 24 September 2023, 20:40 GMT
This resetting my mouse button settings and cursor speed has been driving me nuts forever.