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?

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.

> 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.

Correction:
xcape still works

> 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.

https://github.com/archlinux/svntogit-packages/blob/packages/systemd/trunk/30-systemd-udev-reload.hook#L6

There are dozens of such packages. See https://bugs.archlinux.org/task/77815 for another example.

Dupe  FS#77815 

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.

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

00-keyboard.conf
# 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"
EndSection


Even 'loadkeys de-latin1' does not bring back german keyboard layout.
I|am not using .xinitrc to set locales!

@renegat: loadkeys is used for console only, try 'setxkbmap de'.

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

IIRC this one required a rule reload (which we already did before), followed by a trigger:
https://github.com/systemd/systemd/commit/583dc6d933d8eb84f338c28cbe2f4c86ee1ff069

The symlink was used and thus required in a userland tool shipped by systemd... Would have to look up the details myself.

I guess the complete session crash was caused by  FS#78097 ...

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. https://bbs.archlinux.org/viewtopic.php?id=284249 - this might be a plasma bug at the end of the day but could be avoided by not triggering udev reloads.

This definitely is also related to https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/issues/177 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.