Bug 2127663

Created attachment 1912600 [details]
plymouth-debug

Thank you for the log that helps. I believe I know what is going on here, here is the commit message for a patch I'm writing for this:

"""
Plymouth has 2 hw discovery paths:
1. Enumerating devices already known by udev at plymouth startup
2. Devices which are hotplugged after startup

At boot we have udevd which is enumerating hw and plymouthd racing
with each other, which means that plymouthd may discover the new
SimpleDRM device through either 1. or 2.

Before this patch a check for SimpleDRM was missing from path 1, causing
it to be treated as a normal device instead of being ignored as intended:

plymouth-debug.log for the simpledrm being enumerated in path 1:

ply-device-manager.c:344: create_devices_for_subsystem:
 found device /sys/devices/platform/simple-framebuffer.0/drm/card0
ply-device-manager.c:351: create_devices_for_subsystem:
 device is initialized
ply-device-manager.c:360: create_devices_for_subsystem:
 found node /dev/dri/card0
ply-device-manager.c:283: create_devices_for_udev_device:
 found DRM device /dev/dri/card0
ply-device-manager.c:885: create_devices_for_terminal_and_rende:
 creating devices for /dev/dri/card0 (renderer type: 1)

plymouth-debug.log for the simpledrm *not* being enumerated in path 1:

ply-device-manager.c:344: create_devices_for_subsystem:
 found device /sys/devices/platform/simple-framebuffer.0/drm/card0
ply-device-manager.c:367: create_devices_for_subsystem:
 it's not initialized

followed by path 2 enumerating the device very shortly after this:

ply-device-manager.c:532: on_udev_event:
 got add event for device /dev/dri/card0
ply-device-manager.c:462: verify_add_or_change:
 ignoring since we only handle SimpleDRM devices after timeout

Note how path 2 does correctly ignore SimpleDRM devices, where as
path 1 does not. This commit fixes this by moving the verify_drm_device()
check in to create_devices_for_udev_device() which runs in both paths.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=2127663
"""

Your system is following path 1. here; where as with my system it seems to be a coin toss which path it follows (when it follows path 2 there is a 6 ms time-difference between the cold-plug and hot-plug enumerations).

I'm going to run some local tests with the patch and then I'll do a plymouth scratch build for you to test and confirm that the issue is resolved.

Here is a scratch-build, please install this and after the regenerate your initrd before rebooting :

https://koji.fedoraproject.org/koji/taskinfo?taskID=92399189

Also please provide a new plymouth-debug.log from a boot with this version so that I can check it is behaving as expected now, thanks.

Created attachment 1914902 [details]
New plymouth-debug log

I'm pretty confident your new build fixed it. Thanks!

FEDORA-2022-c66bb240b7 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c66bb240b7

FEDORA-2022-c66bb240b7 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2022-938267a276 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-938267a276

FEDORA-2022-938267a276 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-938267a276`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-938267a276

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-938267a276 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.