Michael Biebl writes:
So this is a change in behaviour in the kernel?
Yes, this commit fixed the kernel to report the error instead of
silently failing:
commit df44b479654f62b478c18ee4d8bc4e9f897a9844
Author: Peter Rajnoha <prajnoha@redhat.com>
Date: Wed Dec 5 12:27:44 2018 +0100
kobject: return error code if writing /sys/.../uevent fails
Propagate error code back to userspace if writing the /sys/.../uevent
file fails. Before, the write operation always returned with success,
even if we failed to recognize the input string or if we failed to
generate the uevent itself.
With the error codes properly propagated back to userspace, we are
able to react in userspace accordingly by not assuming and awaiting
a uevent that is not delivered.
Signed-off-by: Peter Rajnoha <prajnoha@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
What happens if you boot the installed system? Does udevadm trigger fail
there as well?
Yes, it does; that is how I was able to track down the problem.
I feel a bit uneasy changing the udev start script this late in the
release cycle (especially when it appears like covering up an issue
someplace else).
I'll let Marco make the judgement on this though, as he has the most
experience with those udev udeb start scripts as the original author.
So far I have been removing the -e from the shbang line in the
start-udev script and remastering the iso so I can get it to boot. It
would probably be a better idea to just add a || true to the udevadm
trigger call. I feel fairly certain that no matter what the cause of
the coldplug failure, the user is going to be better off ignoring it and
trying to proceed than a kernel panic.