Created attachment 1720096 [details] systemd-analyze plot with default settings Description of problem: Startup on fedora still feels slow. Masking NetworkManager-wait-online.service allows gdm to appear 5-6 seconds sooner. Version-Release number of selected component (if applicable): Fedora 33 How reproducible: Very Steps to Reproduce: 1. Install fedora 33 workstation beta 2. Use "systemd-analyze plot > boot.svg" and check startup speed. 3. Mask NetworkManager-wait-online.service "systemctl mask NetworkManager-wait-online.service" 4. Restart and run "systemd-analyze plot > boot2.svg" 5. Check the start up speed. It will be noticeably quicker. Actual results: Expected results: Additional info: This laptop normally had about a 10 sec startup, or it used to take about 10 secs to reach gdm. Since fedora 32 startup on all my systems have been noticeably slower. x1 carbon gen 5 i5-7300U. 16GB ram. NVME storage.
We have an unfortunate combination of dependencies: - nfs-client.target pulls rpc-statd-notify.service into the transaction - rpc-statd-notify.service orders itself before remote-fs.target and after network-online.target - libvirtd.service orders itself after remote-fs.target and before multi-user.target Thus the combination of rpc-statd-notify.service and libvirtd.service being in the transaction create an ordering of network-online.target before multi-user.target. This is rather unfortunate. It can only be solved by cutting some dependencies from the unit graph, and this can only be done by changing unit configuration in the respective packages. Do you have any nfs mounts or any remote filesystems at all? Based on the chart, it seems not. Does this help?: sudo systemctl disable nfs-client.target I'll reassign this to nfs-utils, because I think the best chance at solving this is with rpc-statd-notify.service. Could we make rpc-statd-notify.service not pull in network-online.target somehow? One idea: let the service wait for network connectivity on its own and not order it after network-online.target. Second idea: use a systemd generator to only pull in the unit into the transaction if there are any nfs mounts at all, so in the common case it does not need to delay anything. Third idea: combine both approaches ;)
I can confirm this: Boot is about 6s slower on f33 compared to f31 (the upgrade went very smooth otherwise, however :). Disabling nfs-client.target did not help. rpc-statd-notify.service is not enabled on my system. What helped was disabling remote-fs.target or masking NetworkManager-wait-online.service as described by OP. Best, Philip
Laptop: Dell XPS 13 (9380) System: Fedora 33 Workstation with Gnome My laptop boots 18 seconds faster (wall clock) into Gnome after disabling NetworkManager-wait-online.service ($ sudo systemctl disable NetworkManager-wait-online.service). Reducing boot time by 18 seconds is amazing! Disabling nfs-client.target ($ sudo systemctl disable nfs-client.target) as suggested in Comment 1 did not help.
I compared the output from `systemd-analyze plot > filename.svg` from Fedora 33 Live System and Ubuntu 20.10 Live System. The svgs are attached. For me, from the lay person perspective, I can see that - NetworkManager-wait-online.service in both cases takes ~15 seconds - Ubuntu starts 22 services between `network.target` and `network-online.target` - Fedora starts 5 services between both targets It seems as if Ubuntu uses the time between the two targets more efficiently. My Fedora installation on bare metal used to connect to WiFi before Gnome is running. After disabling NetworkManager-wait-online.service my system connects to WiFi while Gnome is running (i.e., after auto-login as configured in Gnome Settings). As written above that is appreciated because it safes - in my case - 18 seconds of boot time into Gnome. I do not know whether Ubuntu on bare metal (not the live system without WiFi credentials) would connect to WiFi before or after Gnome is running. Overall it would be great to achieve the boot speed boost. Not sure though whether my comment is helpful.
Created attachment 1733490 [details] systemd-analyze plot Ubuntu 20.10 Live
Created attachment 1733491 [details] systemd-analyze plot Fedora 33 Live