writing 'add' to /sys/devices/vio/uevent fails with ENODEV

[Dan Streetman]

[impact]

The systemd-udev-trigger service calls 'udevadm trigger --type=devices --action=add', which writes 'add' to all /sys/devices/ uevent nodes, to re-generate their uevents sent to udev. Until systemd commit 97afc0351a96e0daa83964df33937967c75c644f, any errors during this process were simply logged to debug and ignored, but now udevadm will log errors and return failure.

On ppc64el, the /sys/devices/vio device returns ENODEV when writing 'add' to its uevent, which causes the udevadm command to return failure, which causes the systemd-udev-trigger system service to fail.

The kernel vio driver should be fixed to not return ENODEV.

[test case]

On a ppc64el system, with any systemd containing commit 97afc0351a96e0daa83964df33937967c75c644f, check the status of the systemd-udev-trigger service, to see that it's failed.

Alternately, again on a ppc64el system, run as root:

# echo add > /sys/devices/vio/uevent
-bash: echo: write error: No such device

[regression potential]

the potential should be low, as this appears to have always behaved this way, at least for a while now.

[other info]

the systemd commit that changes udevadm to start failing for this error isn't included in any Ubuntu release yet, this is found from systemd upstream testing.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1845319

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Dan Streetman (ddstreet)]

This bug was uncovered after a behavior change in upstream systemd (udevadm):
https://github.com/systemd/systemd/issues/13652#issuecomment-535129791

[Dan Streetman (ddstreet)]

As this is a trivial issue that nobody will care about, as long as udevadm ignores the error code, I'm marking wontfix for the kernel. I'll still try to get it fixed in the upstream kernel, but I think there's no need to SRU it, and systemd is going to fix udevadm to ignore ENODEV during triggering.
https://github.com/systemd/systemd/pull/13656

[Dan Streetman (ddstreet)]

Just keeping this open in systemd for my tracking until it's added upstream

[Dan Streetman (ddstreet)]

systemd upstream PR 13656 merged

[Dan Streetman (ddstreet)]

removing myself as bug owner, as I tried to send a simple patch upstream to fix this, but was told to instead make more complex changes. As the bug isn't really that important, and systemd has been patched to ignore the kernel bug, I'm just letting it go.