Recently, all Fedora Workstation Live images used the spinner theme for Plymouth, while Server images used the tribar theme. I believe the Plymouth theme is a crucial part of the Workstation brand and the correct Plymouth theme should be there. Reproducible: Always Steps to Reproduce: 1. Boot the Fedora Workstation 1.7 RC and see it. Actual Results: tribar theme used for Workstation Expected Results: spinner theme used for Workstation
Proposed as a Blocker for 40-beta by Fedora user lruzicka using the blocker tracking app because: I am proposing this for a Beta blocker discussion, as I tend to believe that this violates the expected boot behaviour criterion (https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_image_boot_behavior)
Are you talking about Live image or the installed system? Because I most definitely see a spinner when booting F40 Workstation Beta RC1.7, both in a VM and on bare metal.
(In reply to Kamil Páral from comment #2) > when booting F40 Workstation Beta RC1.7 The Live image, I wanted to add. I haven't yet tested the installed system, but it would be interesting if it changed after installation.
Discussed during the 2024-03-18 blocker review meeting: [1] The decision to classify this bug as a RejectedBlocker (Beta) and AcceptedFreezeException (Beta) was made: "We can't find any criterion it violates and it appears to be a merely cosmetic issue. It's accepted as an FE if it proves to be a reproducible bug with a clear and safe fix." [1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-03-18/f40-blocker-review.2024-03-18-16.01.log.html
I got the same result as kparal, saw the spinner booting on a VM in both BIOS and UEFI. One thing to be careful of: check if you're testing the experimental osbuild-built Workstation live. Especially as I just noticed it was incorrectly displayed high up on the wiki download table, *above* the 'official' live image. I've fixed that in wikitcms and re-generated the download table now, so it's hidden down at the bottom. The osbuild-built image has 'osb' in the filename. If this bug is specific to *that* image, it's interesting information but less immediately critical. I will check this after installing to disk in a VM, and also check it on my hardware test box in a minute.
On the installed system, I did see the three-box bootsplash on first boot after install, but I saw the spinner on shutdown, and on *second* boot after install, I saw the spinner. Some kind of race, maybe?
I think this bug can more accurately be described as "sometimes even with plymouth-theme-spinner installed, we get text mode plymouth for some reason". I can see this quite often in openQA tests. It's like it's some sort of race during startup - sometimes it happens, sometimes it doesn't, in the exact same situation. There doesn't seem to be any specific trigger.
Look at the last six runs of upgrade_desktop_encrypted_64bit on Fedora 40 updates, for instance: https://openqa.fedoraproject.org/tests/2590298 https://openqa.fedoraproject.org/tests/2589350 https://openqa.fedoraproject.org/tests/2589276 https://openqa.fedoraproject.org/tests/2588831 https://openqa.fedoraproject.org/tests/2588293 https://openqa.fedoraproject.org/tests/2588167 That's a test that starts from a disk image of an encrypted Fedora 39 Workstation install, upgrades it to Fedora 40, and verifies the upgraded system boots and works. In each test, look at the single thumbnail in the "disk_guided_encrypted_postinstall" test step. That is the passphrase entry prompt the system saw on the first boot after the upgrade completed. In two of those six tests, it's graphical. In four of them, it's text. This is the exact same test running the exact same way every time, the only difference is the specific packages in the update under test, but that's clearly not relevant - the result just seems to be random. Sometimes we get the text prompt, sometimes we get the graphical prompt.
I have been seeing this sometimes on my laptop too. So I have enabled plymouth debug logging and I just captured a debug log which explains what is going on. Let me attach it here, note I'm making it private out of an abundance of caution.
Here are the interesting bits from the log: 00:00:02.557 ../src/libply-splash-core/ply-device-manager.c:684:watch_for_u: watching for udev graphics device and input device add and remove events 00:00:02.557 ../src/libply-splash-core/ply-device-manager.c:473:create_devi: Not creating devices for subsystem input because there is no configure XKB layout 00:00:02.557 ../src/libply-splash-core/ply-device-manager.c:478:create_devi: creating objects for drm devices 00:00:02.558 ../src/libply-splash-core/ply-device-manager.c:498:create_devi: found device /sys/devices/pci0000:00/0000:00:02.0/simple-framebuffer.0/drm/card0 00:00:02.558 ../src/libply-splash-core/ply-device-manager.c:513:create_devi: it's not initialized 00:00:02.558 ../src/libply-splash-core/ply-device-manager.c:498:create_devi: found device /sys/devices/pci0000:00/0000:00:02.0/simple-framebuffer.0/drm/card0/card0-Unknown-1 00:00:02.558 ../src/libply-splash-core/ply-device-manager.c:513:create_devi: it's not initialized Note this is for the simpledrm, so even if were initialized it would be ignored anyways. But what is interesting is that there is a race here where plymouth sees this during cold-plug (already initialized) GPU scanning, but it is not ready uet and no udev "add" event has been emitted for it yet. And later we get that add event, but when plymouth gets around to it we also get the remove event at the same time: 00:00:05.948 ../src/libply-splash-core/ply-device-manager.c:643:on_udev_eve: got add event for device /dev/dri/card0 00:00:05.948 ../src/libply-splash-core/ply-device-manager.c:643:on_udev_eve: got add event for device /dev/dri/card1 00:00:05.949 ../src/libply-splash-core/ply-device-manager.c:643:on_udev_eve: got remove event for device /dev/dri/card0 00:00:05.949 ../src/libply-splash-core/ply-device-manager.c:396:create_devi: device subsystem is drm 00:00:05.949 ../src/libply-splash-core/ply-device-manager.c:403:create_devi: found DRM device /dev/dri/card0 00:00:05.949 ../src/libply-splash-core/ply-device-manager.c:1097:create_dev: creating devices for /dev/dri/card0 (renderer type: 1) (terminal: /dev/tty1) The remove event causes plymouth to flush the internal queue of udev events which it uses to coalescence udev events, so its start processing the queued add events first to keep things ordered. plymouth could be smarter here and see there is an "add" event pending for the just removed card and remove that add event from the queue before flushing. This is definitely a good optimization, but it would only shorten the race window. There is still a possible scenario where the simpledrm /dev/dri/card0 is unregistered while plymouth tries to probe it and plymouth has not yet seen the remove event. Hitting the race where the simpledrm /dev/dri/card0 is unregistered while plymouth tries to probe it results in: 00:00:05.949 ../src/libply-splash-core/ply-renderer.c:235:ply_renderer_open: trying to open renderer plugin /usr/lib64/plymouth/renderers/drm.so 00:00:05.949 ../src/plugins/renderers/drm/plugin.c:894:create_backend : creating renderer backend for device /dev/dri/card0 00:00:05.949 ../src/plugins/renderers/drm/plugin.c:977:load_driver : Opening '/dev/dri/card0' 00:00:05.949 ../src/plugins/renderers/drm/plugin.c:981:load_driver : open failed: No such file or directory 00:00:05.949 ../src/libply-splash-core/ply-renderer.c:241:ply_renderer_open: could not open rendering device for plugin /usr/lib64/plymouth/renderers/drm.so 00:00:05.949 ../src/libply-splash-core/ply-renderer.c:287:ply_renderer_open: could not find suitable rendering plugin 00:00:05.949 ../src/libply-splash-core/ply-device-manager.c:1106:create_dev: No renderer plugins installed, creating non-graphical devices The last line here is the issue, I have not yet looked at the code but it seems that the device-manager decides that the drm-plugin failing should result in immediately switching to text mode even though the wait for gfx devices timeout has not happened yet. Since normally on devices which for some reason have no kms support we wait for the timeout I think we should do so here too and that should resolve this bug. Ray? What do you think to change things to change this code path to use the wait for gfx devices timeout too? Note that I think we can also hit this on dual GPU laptops where the discrete GPU is an accelerator only and has no video outputs, if in that case we probe the /dev/dri/card# for that GPU first the drm plugin will fail there too (because there are no CRTCs on such a GPU), so it seems that we should simply not treat the drm-plugin failing as a reason to immediately switch to text mode ?
p.s. The log continues with successfully initializing the drm plugin for /dev/dri/card1, but then plymouth is already in text mode: 00:00:05.966 ../src/libply-splash-core/ply-device-manager.c:403:create_devi: found DRM device /dev/dri/card1 00:00:05.966 ../src/libply-splash-core/ply-device-manager.c:1097:create_dev: creating devices for /dev/dri/card1 (renderer type: 1) (terminal: none) 00:00:05.966 ../src/libply-splash-core/ply-renderer.c:235:ply_renderer_open: trying to open renderer plugin /usr/lib64/plymouth/renderers/drm.so ... 00:00:05.966 ../src/plugins/renderers/drm/plugin.c:634:ply_renderer_head_ne: Creating 3840x2400 renderer head 00:00:05.995 ../src/plugins/renderers/drm/plugin.c:1526:create_heads_for_ac: outputs changed 00:00:05.996 ../src/plugins/renderers/drm/plugin.c:253:ply_renderer_buffer_: returning 1x1 buffer with stride 64 00:00:05.996 ../src/libply-splash-core/ply-renderer.c:255:ply_renderer_open: opened renderer plugin /usr/lib64/plymouth/renderers/drm.so
Ok, so this is caused by this recent(ish) upstream commit: https://gitlab.freedesktop.org/plymouth/plymouth/-/commit/03842d5201e4486fe62635c7b470eb94696f985d Which also explains why we have not seen this before. Since I'm pretty sure that this is the root cause I've submitted a pull request to revert this upstream: https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/319 And I have started a rawhide plymouth build with the revert as downstream patch, which will hopefully fix the openqa checks: https://koji.fedoraproject.org/koji/taskinfo?taskID=117385140
This bug doesn't actually make openQA tests fail, we can just *see* it there. If you want a bug that causes openQA tests to fail, though, there's https://bugzilla.redhat.com/show_bug.cgi?id=2274770 , though that one actually seems to involve the kernel (as it doesn't seem to happen with kernel 6.8...)
FEDORA-2024-4c865b3461 (plymouth-24.004.60-10.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-4c865b3461
FEDORA-2024-4c865b3461 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-4c865b3461` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-4c865b3461 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-4c865b3461 (plymouth-24.004.60-10.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
I'm still seeing this on my system. Dell T7500, Fedora 40, latest updates including plymouth-24.004.60-12.fc40.x86_64 When I add a new external Seagate USB hard drive, I get the text bootup. When I remove the drive from the system, I see the spinner.
Also, it popped up today on Reddit: https://www.reddit.com/r/Fedora/comments/1ejzkg7/plymouth_theme_appears_on_boot_but_only_when_my/ The user there claims that the text theme is only displayed when booting the system without AC power, otherwise it's the graphical theme.