Description of problem: The boot splash screen usually showed a theme with three white dots which lighted up from left to right instead of the selected Spinner theme in a F38 KDE Plasma installation. I have the Spinner theme selected in the Plasma System Settings page Appearance > Boot Splash Screen. The Spinner theme was shown occasionally. I haven't found any journal errors related to plymouth when this happened. Version-Release number of selected component (if applicable): plymouth-22.02.122-4.fc38.x86_64 plasma-workspace-5.27.3-3.fc38.x86_64 kernel-6.2.9-300.fc38.x86_64 How reproducible: The three white dots were shown on most boots. Steps to Reproduce: 1. Boot a F38 KDE Plasma installation updated to 2023-3-31 with updates-testing enabled on bare metal with the Spinner theme selected in the System Settings page Appearance > Boot Splash Screen 2. If the theme with the three dots wasn't shown, keep rebooting until it does. 3. Actual results: The boot splash screen usually showed a theme with three white dots instead of the selected Spinner theme in a F38 KDE Plasma installation. Expected results: The boot splash screen would show the selected Spinner theme on all boots of a F38 KDE Plasma installation. Additional info: This issue didn't happen when booting F38 KDE Plasma live images such as Fedora-KDE-Live-x86_64-38-20230330.n.0.iso and earlier in GNOME Boxes QEMU/KVM VMs.
We will need some more logs to try and debug this. Can you please add "plymouth.debug=stream:/dev/null" to your kernel commandline? And then after booting with that do: 1. 'cat /proc/cmdline' and check it really is there 2. Run: dmesg > dmesg.txt 3. Collect the generated dmest.txt file as well as /var/log/plymouth-debug.log and attach both to this bug. Note I'm asking for these logs now so that they will hopefully be attached here when I have time to look at this bug. But my workload is so high that I cannot make any promises wrt when I will be able to make time to look into this, if ever.
Created attachment 1955111 [details] /var/log/plymouth-debug.log from a boot with the three dots on the boot splash screen Thanks. I booted 6.2.9 with plymouth.debug=stream:/dev/null added to the kernel command line. The theme with three dots in the top-left quadrant of the screen only showed up the fifth time I did so, while the three dots were shown about 80% of boots before that. I'm attaching /var/log/plymouth-debug.log from the boot with the three dots theme shown. The problem involved the error "Failed to open key file /usr/share/plymouth/themes/default.plymouth: No such file or directory." /usr/share/plymouth/themes/default.plymouth doesn't exist on my system. ll /usr/share/plymouth/themes/default.plymouth ls: cannot access '/usr/share/plymouth/themes/default.plymouth': No such file or directory The text theme was then loaded according to the error "Could not start default splash screen,showing text splash screen" 00:00:11.307 ply-boot-splash.c:486:ply_boot_splash_show : showing splash screen 00:00:11.307 plugin.c:1659:show_splash_screen : loading lock image 00:00:11.307 plugin.c:1664:show_splash_screen : loading box image 00:00:11.307 plugin.c:1673:show_splash_screen : loading corner image 00:00:11.307 plugin.c:1682:show_splash_screen : loading header image 00:00:11.307 plugin.c:1691:show_splash_screen : loading background tile image 00:00:11.307 plugin.c:1718:show_splash_screen : loading watermark image 00:00:11.307 plugin.c:1726:show_splash_screen : couldn't load views 00:00:11.307 ply-boot-splash.c:492:ply_boot_splash_show : can't show splash: No such file or directory 00:00:11.307 ply-boot-splash.c:390:ply_boot_splash_free : freeing splash 00:00:11.307 ply-event-loop.c:971:ply_event_loop_stop_watching_for_timeout : no matching timeout found for removal 00:00:11.307 ply-boot-splash.c:335:remove_pixel_displays : removing pixel displays 00:00:11.307 plugin.c:1260:destroy_plugin : destroying plugin 00:00:11.307 plugin.c:1231:free_views : freeing views 00:00:11.307 main.c:465:show_default_splash : Trying old scheme for default splash 00:00:11.307 main.c:1705:load_theme : Loading boot splash theme '/usr/share/plymouth/themes/default.plymouth' 00:00:11.307 ply-key-file.c:84:ply_key_file_open_file : Failed to open key file /usr/share/plymouth/themes/default.plymouth: No such file or directory 00:00:11.307 ply-boot-splash.c:390:ply_boot_splash_free : freeing splash 00:00:11.307 main.c:470:show_default_splash : Could not start default splash screen,showing text splash screen 00:00:11.307 main.c:1705:load_theme : Loading boot splash theme '/usr/share/plymouth/themes/text/text.plymouth' 00:00:11.307 ply-key-file.c:175:ply_key_file_load_group : trying to load group Plymouth Theme
Created attachment 1955112 [details] dmesg from a boot with the text theme with the three dots I'm attaching the dmesg output from the boot of 6.2.9 with plymouth.debug=stream:/dev/null added to the kernel command line in which the text theme with the three dots in the top-left quadrant of the screen was shown and I attached the /var/log/plymouth-debug.log for. Many denials of plymouthd reading cmdline or stat were shown in the dmesg output which I reported at https://bugzilla.redhat.com/show_bug.cgi?id=2183752 and they only happened on boots with plymouth.debug=stream:/dev/null added to the kernel command line. [ 14.639941] audit: type=1400 audit(1680375601.634:6): avc: denied { read } for pid=384 comm="plymouthd" name="cmdline" dev="proc" ino=1209 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=file permissive=0
Ok, so the problem seems to be that during boot for 6-7 seconds nothing happens: [ 4.067401] logitech-hidpp-device 0003:046D:4054.0004: input,hidraw3: USB HID v1.11 Mouse [Logitech Wireless Mouse] on usb-0000:00:10.0-3/input1:2 [ 10.998255] [drm] amdgpu kernel modesetting enabled. And then by the time the amdgpu driver does finally get loaded around 11 seconds after the kernel started, plymouth has lost its patience and hits: 00:00:11.305 ply-device-manager.c:1015:create_devices_from_udev : Timeout elapsed, looking for devices from udev 00:00:11.305 ply-device-manager.c:362:create_devices_for_subsystem : creating objects for drm devices 00:00:11.305 ply-device-manager.c:362:create_devices_for_subsystem : creating objects for frame buffer devices 00:00:11.306 ply-device-manager.c:382:create_devices_for_subsystem : found device /sys/devices/virtual/graphics/fbcon 00:00:11.306 ply-device-manager.c:405:create_devices_for_subsystem : it's not initialized 00:00:11.306 ply-device-manager.c:1023:create_devices_from_udev : Creating non-graphical devices, since there's no suitable graphics hardware What is happening here is that plymouth is racing with the (late) amdpgu init. amdgpu has already removed the simpledrm device so plymouth cannot use that and amdgpu itself has not yet initialized so plymouth sees no gfx output options and falls back to textmode. There are ways to fix this, e.g. make plymouth bind directly to simpledrm. But those are all workarounds. The real question is where this 7 second gap comes from: [ 4.067401] logitech-hidpp-device 0003:046D:4054.0004: input,hidraw3: USB HID v1.11 Mouse [Logitech Wireless Mouse] on usb-0000:00:10.0-3/input1:2 [ 10.998255] [drm] amdgpu kernel modesetting enabled.
The journal from when that 7 second gap happened showed rngd running. Apr 01 14:59:51 kernel: logitech-hidpp-device 0003:046D:4054.0004: input,hidraw3: USB HID v1.11 Mouse [Logitech Wireless Mouse] on usb-0000:00:10.0-3/input1:2 Apr 01 14:59:54 rngd[238]: [jitter]: Unable to obtain AES key, disabling JITTER source Apr 01 14:59:57 rngd[238]: [jitter]: Initialization Failed Apr 01 14:59:57 rngd[238]: [pkcs11]: Unable to load pkcs11 engine: (null) Apr 01 14:59:57 rngd[238]: [pkcs11]: Initialization Failed Apr 01 14:59:57 rngd[238]: [rtlsdr]: Initialization Failed Apr 01 14:59:57 kernel: [drm] amdgpu kernel modesetting enabled. I ran sudo systemctl disable rngd and rebooted. rngd was still run at that point. I ran sudo dnf remove rng-tools and rebooted. rngd was still being run at that point. sudo lsinitrd showed rngd was in the initramfs. I ran sudo dracut -f and rebooted. The several second gap was still shown even though rngd wasn't shown any more. The text theme with the three dots was still shown. I tried removing the Logitech Wireless Mouse USB reciever, but the gap was still there. I put debug on the kernel command line. There were many debug lines with systemd-udevd starting various devices when the Logitech Wireless mouse was started, but then a gap of several seconds before amdgpu started. I put drm.debug=14 log_buf_len=16M on the kernel command line. The drm debug messages didn't start until after amdgpu started. There was a problem with the integrated AMD Radeon R5 GPU and AMD IOMMU on the system from the 6.2 merge window to 6.2.2-301 which resulted in a black screen when amdgpu started during boot with the IOMMU enabled https://bugzilla.redhat.com/show_bug.cgi?id=2156691 I bisected the problem to a change which made an error because the AMD GPU didn't have the Access Control Services (ACS) capability of PCIe which led amdgpu to crash in an IOMMU function https://bugzilla.redhat.com/show_bug.cgi?id=2156691#c1 The problem was fixed by 4 patches correcting the AMD IOMMU error handling https://bugzilla.redhat.com/show_bug.cgi?id=2156691#c5 The error generated due to the bisected patch still happens though with later kernels. I don't know if that error might be delaying amdgpu from starting. I tried adding amd_iommu=off to the kernel command line to shut off the IOMMU which was a workaround for the black screen problem. The several second gap before amdgpu started still happened. The race condition between amdgpu and plymouth makes sense. Why would plymouth try to load the non-existent file shown in the error Failed to open key file /usr/share/plymouth/themes/default.plymouth: No such file or directory ? /usr/share/plymouth/themes/default.plymouth doesn't appear to be provided by any package based on sudo dnf repoquery --whatprovides /usr/share/plymouth/themes/default.plymouth What might be other troubleshooting methods I could use? Thanks.
> Why would plymouth try to load the non-existent file shown in the error Failed to open key file /usr/share/plymouth/themes/default.plymouth: No such file or directory ? This is a file which plymouth tries to load for backward compatibility reasons, it not being present is expected. As for where the 6-7 seconds delay is coming from I'm afraid I have no idea.
Ok, so I just (accidentally) reproduced this while repurposing an old AMD based embedded PC. This PC has an AMD G-T56N Processor, which has 2 Bobcat (aka Brazos) CPU cores which was AMD's small low-power core equivalent of Atom before Ryzen. So these 2 cores are not very fast. The integrated graphics on Brazos use the radeon driver but the modalias match in amdgpu is such that it also gets loaded and this was causing a similar large delay with nothing in the logs. Since amdgpu is not actually used on this machine I added: "modprobe.blacklist=amdgpu" to the kernel commandline. If I then time how long modprobing amdgpu takes (which I can safely do since the driver is not actually used): I see the following with 6.2 : [root@fedora ~]# time modprobe amdgpu real 0m12.477s user 0m0.745s sys 0m11.240s And the following with 6.1: [root@fedora ~]# time modprobe amdgpu real 0m8.749s user 0m0.687s sys 0m7.752s Neither is exactly great, but notice how the modprobe time has increased a lot with 6.2, which likely explains your problem. I will file a bug with the upstream amdgpu devs about this, but it would be good to also get your modprobe time numbers. Can you do the following: 1. Boot in such a way that the grub menu will show during boot, see: https://hansdegoede.dreamwidth.org/19180.html 2. Then in the grub menu select a 6.1 kernel and then press "e" to edit then go to the options line and at the end of the line add: "modprobe.blacklist=amdgpu 3" this will boot your system without the amdpgu driver and into a text console. 3. On the text console log in with your usual username + password and then do: "sudo time modprobe amdgpu > amdgpu-probe-6.1.log" After this you can do "cat amdgpu-probe-6.1.log" to see the results. 4. Then type "reboot" to reboot. 5 Enter the grub menu again select a 6.2 kernel press "e" to edit then go to the options line and at the end of the line add: "modprobe.blacklist=amdgpu 3" again. 6. "sudo time modprobe amdgpu > amdgpu-probe-6.2.log" 7. "reboot" into your normal system And then copy and paste the contents of amdgpu-probe-6.1.log and amdgpu-probe-6.2.log into a comment here.
Hmm, "sudo time modprobe amdgpu > amdgpu-probe-6.1.log" does not work please make that: "sudo time modprobe amdgpu 2> amdgpu-probe-6.1.log" and: "sudo time modprobe amdgpu 2> amdgpu-probe-6.2.log"
I followed your steps with 6.2.9 and the amdgpu start times were as follows. cat amdgpu-probe-6.2.log 0.31user 6.44system 0:07.63elapsed 88%CPU (0avgtext+0avgdata 51692maxresident)k 7704inputs+0outputs (0major+12277minor)pagefaults 0swaps I installed kernel-6.1.18-200.fc37 from koji. The amdgpu start times with 6.1.18 were about the same as with 6.2.9. cat amdgpu-probe-6.1.log 0.28user 6.46system 0:07.66elapsed 88%CPU (0avgtext+0avgdata 42160maxresident)k 7192inputs+0outputs (0major+9854minor)pagefaults 0swaps I've been seeing the text theme less frequently than the spinner theme in recent days. I'm not sure why. I prevented amdgpu from starting while the initramfs was in use with rd.driver.blacklist=amdgpu several days ago. The plymouth screen wasn't shown, and the screen was black when plymouth usually appeared until sddm appeared. There was a gap of several seconds before amdgpu started after the initramfs stage was finished. There were many denials of plymouthd mapping /dev/dri/card0 during that gap and after like the following. type=AVC msg=audit(1680892032.536:682): avc: denied { map } for pid=406 comm="plymouthd" path="/dev/dri/card0" dev="devtmpfs" ino=159 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:dri_device_t:s0 tclass=chr_file permissive=0 Those denials also happened repeatedly with your steps using modprobe.blacklist=amdgpu 3 That type of denial was reported at https://bugzilla.redhat.com/show_bug.cgi?id=2175351 https://bugzilla.redhat.com/show_bug.cgi?id=2182457 https://bugzilla.redhat.com/show_bug.cgi?id=2184900 Could you put a link here if you make an upstream amdgpu report or cc me? Thanks.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
The plymouth text mode was shown every time I booted the 6.9.2 kernel in a F40 KDE Plasma installation on the same system as before with plymouth-24.004.60-10.fc40 and plymouth-24.004.60-5.fc40, so I'm reopening this report. Since plymouth-24.004.60-10.fc40 was marked as fixing a text mode problem https://bugzilla.redhat.com/show_bug.cgi?id=2270030 the problem I'm seeing might be different. The plymouth text mode was shown infrequently (~10%) with 6.8 kernels. I'll attach the dmesg and /var/log/plymouth-debug.log from a boot with plymouth.debug=stream:/dev/null on the kernel command line. The journal showed that amdgpu usually started about 10 seconds after plymouth-start.service started, but this delay was 14 seconds with plymouth.debug=stream:/dev/null. amdgpu might be taking a bit longer to start with 6.9.2 compared to 6.8.x leading to the plymouth text mode being shown more often. There were also UBSAN array-index-out-of-bounds warnings in amdgpu as it was starting which started with 6.8.8 when UBSAN was enabled in Fedora 40. https://koji.fedoraproject.org/koji/buildinfo?buildID=2445219 Thanks.
Created attachment 2035722 [details] dmesg from boot of 6.9.2 kernel with plymouth text mode shown
Created attachment 2035723 [details] /var/log/plymouth-debug.log from a boot of the 6.9.2 kernel in which the plymouth text mode was shown
Could the delay of about 10 s between plymouth starting and amdgpu starting be when the initramfs was being decompressed and loaded? I think that amdgpu was loaded while the initramfs was in use on my system. There was a dracut-101-1.fc40 update https://bodhi.fedoraproject.org/updates/FEDORA-2024-6f919aaf6d 2 weeks ago.
Reading back the original report I think that the issue simply is that loading the quite big amdgpu modules takes quite a while (7 seconds) to load on your system. I believe that the best solution is to allow plymouth to use the simpledrm framebuffer to show the splash while it is waiting for this. To do this do the following: 1. Remove any workaround you may have like dracut.conf files to not put amdgpu in the initrd 2. Add "plymouth.use-simpledrm" to the kernel commandline
I booted with plymouth.use-simpledrm on the 6.9.3 kernel command line twice, and the plymouth text theme was still shown both times. simpledrm was started and then amdgpu started 10-12 seconds later in the journal. I didn't have any dracut workarounds. There might have been an amdgpu performance regression when starting with 6.9 that showed up like this. Thanks.
Ok, I think I know what is going wrong here. Plymouth normally waits for udev to be done initializing a device before probing it. So despite the "plymouth.use-simpledrm" on the kernel commandline plymouth skips probing the simpledrm /dev/dri/card0 node because udev is still busy initializing devices and because udev gets blocked on loading the amdgpu module which takes 7 seconds the simpledrm udev-device never gets to the initialized state before plymouth's timeout kicks in and then at the timeout plymouth switches to text mode: First plymouth registers a handler without udev to receive events for new devices and then it asks udev for devices which udev already knows about (but which it might still be initializing): 00:00:02.909 ../src/libply-splash-core/ply-device-manager.c:498:create_devi: found device /sys/devices/pci0000:00/0000:00:01.0/simple-framebuffer.0/drm/card0 00:00:02.910 ../src/libply-splash-core/ply-device-manager.c:513:create_devi: it's not initialized So it sees the simplefb dri card, but it does not use it because it is not initialized and then 8 seconds later when plymouth's 8 second timeout to wait for gfx cards to show up, it again scans already known devices: 00:00:10.917 ../src/libply-splash-core/ply-device-manager.c:1237:create_dev: Timeout elapsed, looking for devices from udev 00:00:10.918 ../src/libply-splash-core/ply-device-manager.c:498:create_devi: found device /sys/devices/pci0000:00/0000:00:01.0/simple-framebuffer.0/drm/card0 00:00:10.918 ../src/libply-splash-core/ply-device-manager.c:513:create_devi: it's not initialized but it is still not initialized (if it had been initialized in the mean time plymouth would have received an event for this). So udev being stuck on loading amdgpu causes the simpledrm udev-device to not move to the initialized state in a timely manner. But simpledrm is special and for the simpledrm case we really do not need to wait for udev to initialize it. So I have prepared a series of plymouth patches to handle simpledrm in a special manner and immediately try to use it at the 2.9s (since kernel boot) timestamp above. I have also done a test-build of the Fedora plymouth package with these patches added for you to test: https://koji.fedoraproject.org/koji/taskinfo?taskID=118650472 To test this please do the following: 1. If you have installed any updates since the last reboot please reboot to make sure that you are running the latest kernel 2. Run: "rpm -qa | grep plymouth | sort" and download the new version of all plymouth packages which rpm lists as installed from: https://koji.fedoraproject.org/koji/taskinfo?taskID=118650472 3. In a directory with all the just downloaded rpms run: "sudo rpm -Uvh plymouth-*.rpm" 4. After updating plymouth re-generate the initramfs for the kernel you are currently running by running: "sudo dracut -f" 5. Reboot into the same kernel with "plymouth.use-simpledrm" on the kernel commandline 6. Collect /var/log/plymouth-debug.log from the boot attempt with the new plymouth and attach it here 7. And let me know if the new plymouth combined with "plymouth.use-simpledrm" on the kernel commandline resolves the problem for you.
Created attachment 2036572 [details] plymouth-debug.log with plymouth-24.004.60-12.fc40 I followed your instructions. The spinner plymouth theme showed on 2 boots with plymouth-24.004.60-12.fc40. On the first boot I put plymouth.use-simpledrm on the kernel command line, on the second plymouth.use-simpledrm plymouth.debug=stream:/dev/null. I'm attaching the plymouth-debug.log for the second boot. According to the journal, simpledrm started and then amdgpu started 13 seconds later on both boots. Thanks.
Thank you for the quick test. I see that the spinner now shows 3 seconds after kernel boot, which is pretty good. I take it that you are happy with the boot experience with the patched plymouth + plymouth,use-simpledrm ? I'll go and submit the patches upstream and then depending on upstream review I'll try to also get these added to the official Fedora plymouth packages soon. I'm still undecided if plymouth,use-simpledrm should be made the default or not. So you will likely need to keep that on your kernel commandline.
It's fine with me to use the patched plymouth + plymouth.use-simpledrm. Your plan sounds good. Thanks.
FEDORA-2024-aed7767b59 (plymouth-24.004.60-12.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-aed7767b59
FEDORA-2024-7d7cf3d6f4 (plymouth-24.004.60-12.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-7d7cf3d6f4
The spinner plymouth theme showed with plymouth-24.004.60-12.fc40 without using plymouth.use-simpledrm when booting the 6.9.3 kernel (which I used for the tests I mentioned in comment 20). Making plymouth.use-simpledrm the default might not be needed to fix this problem.
FEDORA-2024-aed7767b59 (plymouth-24.004.60-12.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-7d7cf3d6f4 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-7d7cf3d6f4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-7d7cf3d6f4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Matt Fagnani from comment #25) > The spinner plymouth theme showed with plymouth-24.004.60-12.fc40 without > using plymouth.use-simpledrm when booting the 6.9.3 kernel (which I used for > the tests I mentioned in comment 20). Making plymouth.use-simpledrm the > default might not be needed to fix this problem. I'm afraid that not hitting the text-mode fallback is going to be a bit of hit and miss on your system without plymouth.use-simpledrm. Also with plymouth.use-simpledrm the splash will show about 3 seconds after the kernel boots, where as without that option it takes around 11s for it to show if it will show at all. So I still think that for systems like yours plymouth.use-simpledrm makes sense. But it can lead to a bit more flickery experience on other systems, so I'm not sure what to do wrt the default. Note there is an upstream discussion about the default here: https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/110 .
The spinner plymouth theme showed each of about 10 times about 5 seconds after I selected 6.9.3 in grub with plymouth-24.004.60-12.fc40 without using plymouth.use-simpledrm. The journal showed that simpledrm was automatically loaded about 1 second before plymouth-start.service started without plymouth.use-simpledrm. systemd-analyze showed the kernel took about 2 seconds to start, so the 3 second delay you mentioned might added up to the 5 s I saw. Your patches probed simpledrm immediately and simpledrm appeared to be loaded already so it might've just been used by plymouth right away. When I added plymouth.debug=stream:/dev/null without plymouth.use-simpledrm there was around a 11 second delay from when I selected 6.9.3 in grub and the spinner theme appeared, so it might've been plymouth.debug=stream:/dev/null that resulted in that delay in the log I attached. There might still be a race condition though. I saw the text theme 1-2 times with mainline 6.10-rc2 I built with patches for https://bugzilla.redhat.com/show_bug.cgi?id=2284351 using plymouth-24.004.60-12.fc40. Thanks.
> systemd-analyze showed the kernel took about 2 seconds to start, so the 3 second delay you mentioned might added up to the 5 s I saw. Right 5 seconds delay when using plymouth.use-simpledrm is expected. > When I added plymouth.debug=stream:/dev/null without plymouth.use-simpledrm there was around a 11 second delay Right this is expected too. Without plymouth.use-simpledrm plymouth waits for the amdgpu /dev/dri/card# device to be available and that take around that long. > I saw the text theme 1-2 times with mainline 6.10-rc2 I assume that that is without plymouth.use-simpledrm? As I tried to explain in my previous comments the time amdgpu takes to load + probe is pretty close to the 8 seconds timeout plymouth uses. So on your laptop things are going to be hit and miss without plymouth.use-simpledrm and my advice would be to simply always use plymouth.use-simpledrm on your laptop.
FEDORA-2024-7d7cf3d6f4 (plymouth-24.004.60-12.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-442827752b (plymouth-24.004.60-12.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-442827752b
FEDORA-2024-442827752b has been pushed to the Fedora 39 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-442827752b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-442827752b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-442827752b (plymouth-24.004.60-12.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.