Description of problem: Boot time of fresh Fedora 31 installations are unusually high compared to other distributions with comparable configurations on several tested systems (AMD and Intel). Analysis: 'systemd-analyze plot' shows major gap between last activating service and release of plymouth-quit-wait.service. Version-Release number of selected component: plymouth-0.9.4 How reproducible: Fresh installation of F31 Steps to Reproduce: 1. systemd-analyze time 2. Repeat while booting with additional parameters: rd.plymouth=0 plymouth.enable=0 Actual results and expected results: (Tested systems using fresh F31 installations) With -> Without plymouth T495 (AMD): 47s -> 26s (-44%) Intel Desktop (+Nvidia): 52s -> 24s (-53%)
After further analysis and a manual test it became clear that systemd-analyze time is not reporting the correct boot/startup time. Results from a manual stopwatch test show "only" an decrease of 2..3 seconds by disabling plymouth: https://ask.fedoraproject.org/t/disabling-plymouth-reduces-boot-time-by-50-percent/5160/4
For anyone reading along here let me also copy and paste me reply to the https://ask.fedoraproject.org/t/disabling-plymouth-reduces-boot-time-by-50-percent/5160/4 thread here: Upstream plymouth maintainer / Mr flicker-free boot here. Chris Murphy pointed me to this thread, so as Chris already explained the systemd-analyze time is not really reliable because it includes the plymouth-quit-wait.service which does not reflect when the login screen is ready for login. With that said, there is some room for improvement after Chris filed this bug I started trying to reproduce this on my own system; and although I see no difference when I mask plymouth-quit-wait.service, I did notice 2 other interesting things: 1. On my system plymouth-switch-root.service takes 2 and a bit seconds, while this should be more like 20ms, the problem is that plymouth is synchronously (using the classic unix select/poll on a bunch of filedescriptors design) and just before the initrd finds my root filesystem the i915 driver loads and then plymouth takes about 2 seconds to deal with all the udev-events (which result in probing the monitor) and loading the initial theme. You may want to check your systemd-analyze plot output to see if you have something similar going on. I have a plan to fix this, but I’m not sure when I will get around to it. 2. If you’ve done your installation from a livecd then you may very well have the dmraid and device-mapper-multipath packages installed. These both come with a enabled by default service, which drags in the deprecated systemd-udev-settle.service and that takes a long time. You very likely do not need multipath (if you do you will know you do) and unless you are using a raid-set which is managed by your disk-controller or system firmware (rather then pure software mdraid) you also do not need dmraid. Even if you are using the RAID functionality from your motherboard, if that is Intel RAID / RST then you still do not need dmraid. So typically you can safely do: “sudo rpm -e dmraid dmraid-events device-mapper-multipath” and this will shave a number of seconds of your boot time. Note do not remove dmraid if you are using a firmware managed raidset or if you are not sure you do, removing it when it is necessary will result in a non booting system!