Reconsider udevadm trigger in systemd-hook, continouous kernel panics are happening
Description:
I'm opening this to reopen the discussion on the controversial udevadm trigger in the systemd-reload.hook -- as previously looked at in: https://bugs.archlinux.org/task/77789
We get almost daily reports of people's systems crashing and having to do various forms of system recovery (... see links below) in one way or another during an update with a strong inclination that the udevadm trigger is the cause and we just recommend them the implemented opt-out file, which I don't think is a very sustainable solution.
I also did some investigation and since Arch often follows Fedora's lead here, and it appears Fedora ran into similar issues and has also opted to not do the udevadm trigger contrary to the upstream suggestion (I might be lacking context on that investigation, so if anyone has anything to the contrary feel free to link it)
https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/triggers.systemd -- no mention of udevadm trigger
https://bugzilla.redhat.com/show_bug.cgi?id=1378974#c17 -- suggesting they ran into similar issues and have since reverted
I'll eat my forum moderator hat if the amount of troubles we get reported from not doing said trigger invocation will be in any way higher than the frequency of system crashes and recovery we are currently seeing.
Additional info:
- Links
https://bbs.archlinux.org/viewtopic.php?pid=2161783#p2161783
https://bbs.archlinux.org/viewtopic.php?id=294440
- package version(s): 255.4
Steps to reproduce:
- Run an update changing anything in /usr/lib/udev.d leading to triggering the udev rules retrigger hook e.g. systemd lvm many more
- Nothing in the best of cases, hang ups from the udev queue in the not so bad cases, kernel panics/session crashes in the bad cases