Fedora Takes a Long Time to Boot (Slow Boot): A Comprehensive Guide to Troubleshooting and Optimization

Is your Fedora workstation taking an agonizingly long time to boot? You’re not alone. Many users encounter slow boot times, which can significantly impact productivity and overall user experience. This comprehensive guide, brought to you by revWhiteShadow, aims to dissect the common causes of slow boot times in Fedora and provide actionable solutions to get your system up and running faster.

As revWhiteShadow’s personal blog, we specialize in providing detailed, practical solutions to Linux performance issues, and this guide is no exception. We will delve into systemd analysis, hardware considerations, and software tweaks to optimize your Fedora boot process.

Understanding the Boot Process and Systemd

Before diving into specific troubleshooting steps, it’s crucial to understand the boot process in Fedora and the role of systemd. Systemd is the init system used by Fedora to manage services and processes during startup. It’s responsible for starting services in parallel, which can significantly speed up boot times compared to older init systems like SysVinit. However, misconfigurations or problematic services can lead to delays.

Analyzing Boot Times with systemd-analyze

The systemd-analyze command is your best friend when diagnosing slow boot times. This utility provides detailed information about the boot process, including the time taken by each service and unit.

Command to Analyze Critical Chain:

The initial analysis using systemd-analyze critical-chain reveals the sequence of units that are on the critical path of the boot process.

systemd-analyze critical-chain

This command displays a tree-like structure showing the dependencies and the time each unit took to start. In the example provided, graphical.target is the final target, indicating the point where the graphical interface becomes available. The output highlights units like plymouth-quit-wait.service which can contribute significantly to delays.

Interpreting the critical-chain Output

  • graphical.target: This represents the point when your graphical environment (GNOME, KDE, etc.) is ready. A large time value here indicates issues with the graphical stack or display manager.
  • multi-user.target: This target is reached when the system is ready for multiple users to log in, often indicating the completion of most background services.
  • plymouth-quit-wait.service: This service waits for Plymouth (the graphical boot splash) to quit. A long wait time here might indicate issues with Plymouth or the graphics driver. 21 seconds is certainly excessive.
  • systemd-user-sessions.service: This service manages user sessions. While its execution time is short (23ms), it’s a dependency on the critical path.
  • remote-fs.target and nfs-client.target: These targets indicate the mounting of remote file systems, specifically NFS in this case. If you don’t use NFS or are not connected to a network share, these might be unnecessarily delaying the boot process.
  • gssproxy.service: Related to network authentication, this can also introduce delays if not configured correctly or if network connectivity is slow.
  • network.target: This target signifies that the network is up. Delays here might stem from network configuration issues, DHCP problems, or slow DNS resolution.
  • wpa_supplicant.service: If you’re using Wi-Fi, this service manages the wireless connection. Delays can occur if the Wi-Fi connection is slow to establish.
  • basic.target: A fundamental target representing the bare essentials for a functional system.
  • dbus-broker.service and dbus.socket: D-Bus is an inter-process communication system. Issues here could indicate problems with various desktop applications or system services relying on D-Bus.
  • sysinit.target: This target represents the initialization of the system.
  • tpm2.target: This is related to the Trusted Platform Module (TPM). If you don’t specifically need TPM, it might be a source of delay.

Command to Identify Time Consuming Units (Blame):

The systemd-analyze blame command provides a list of units sorted by the time they took to start, from longest to shortest. This is particularly useful for pinpointing the most problematic services.

systemd-analyze blame | head -n 15

The output lists services and devices that took the longest time to initialize. In the provided example, a series of device-related entries are taking approximately 46 seconds each. These are related to the storage devices.

Interpreting the blame Output

  • sys-module-fuse.device: This device is related to FUSE (Filesystem in Userspace). It’s unlikely to be the direct cause of the delay but may indicate issues with other mounted file systems.
  • /dev/disk/by-* entries: These entries all point to disk devices. The sheer number of these entries, and the time they take, indicates a major problem with how the system is identifying and initializing the storage devices.

Generating a Boot Plot:

The command systemd-analyze plot > boot.svg generates an SVG file that visually represents the boot process.

Open the boot.svg file in a web browser to see a graphical representation of the boot process. This can help you visualize the dependencies and identify bottlenecks.

Troubleshooting and Optimization Steps

Based on the systemd-analyze output, we can focus on the following areas for optimization:

1. Addressing Storage Device Initialization Delays

The systemd-analyze blame output clearly points to significant delays in initializing storage devices. This could be due to several factors:

  • Incorrect Device Configuration: Double-check your /etc/fstab file to ensure that all entries are correct and that devices are mounted correctly. Consider using noatime and nodiratime options for file systems on SSDs to reduce write operations.
  • Disk Errors: Run disk checks (fsck) on your storage devices to identify and repair any file system errors.
  • AHCI/NVMe Driver Issues: Ensure that your system is using the correct AHCI or NVMe drivers for your SSDs. Update the kernel and drivers if necessary.
  • Disable Unnecessary Device Detection: If you have devices listed in /etc/fstab that are no longer present or needed, remove those entries.
  • SSD Firmware: Check the firmware on your SSDs and update if necessary. Outdated firmware can sometimes cause performance issues.

Example: Modifying /etc/fstab

Open the /etc/fstab file with a text editor (e.g., nano /etc/fstab) and review the entries for your storage devices. Add noatime and nodiratime options for SSD partitions.

UUID=your_ssd_uuid / ext4 defaults,noatime,nodiratime 0 1

Replace your_ssd_uuid with the actual UUID of your SSD partition.

2. Optimizing Network Configuration

The critical-chain output shows delays related to network.target, wpa_supplicant.service, gssproxy.service, remote-fs.target, and nfs-client.target. If these are causing delays, consider the following:

  • Disable Unnecessary Network Services: If you are not using NFS, disable the nfs-client.target and related services.
  • Static IP Address: If you’re using a wired connection, consider assigning a static IP address to avoid DHCP negotiation delays.
  • DNS Resolution: Ensure that your DNS servers are configured correctly and that DNS resolution is fast. Use a reliable DNS server like Google’s (8.8.8.8, 8.8.4.4) or Cloudflare’s (1.1.1.1).
  • Wi-Fi Optimization: If using Wi-Fi, ensure that your Wi-Fi drivers are up to date and that the connection is stable.
  • gssproxy.service: If you’re not using GSSAPI for network authentication, disable gssproxy.service.

Example: Disabling NFS Client

sudo systemctl disable nfs-client.target
sudo systemctl mask nfs-client.target

3. Investigating Plymouth Delays

The plymouth-quit-wait.service taking 21 seconds is a significant bottleneck. This is likely related to the graphics driver or Plymouth configuration.

  • Graphics Driver Issues: Ensure that you’re using the correct and latest drivers for your NVIDIA GeForce GTX 1060. While the user mentioned signed drivers, it’s worth testing the open-source Nouveau drivers to see if they improve boot times.
  • Plymouth Theme: Try switching to a simpler Plymouth theme or disabling Plymouth altogether.
  • Kernel Parameters: Add nomodeset to the kernel parameters in /etc/default/grub and regenerate the GRUB configuration. This might help if the graphics driver is causing problems during early boot.
  • Disable Plymouth: If you don’t need the graphical boot splash, you can disable Plymouth entirely.

Example: Disabling Plymouth

sudo systemctl disable plymouth-quit-wait.service
sudo systemctl mask plymouth-quit-wait.service
sudo systemctl disable plymouth-start.service
sudo systemctl mask plymouth-start.service

4. Addressing Other Services

Check for other services that might be taking a long time to start and disable them if they are not essential. Use systemctl list-units --type=service to see a list of all active services.

Example: Disabling a Service

sudo systemctl disable problematic-service.service
sudo systemctl mask problematic-service.service

Replace problematic-service.service with the actual name of the service.

5. Secure Boot and NVIDIA Drivers

The user mentioned concerns about disabling Secure Boot and Windows 10 WHQL Support due to potentially breaking signed NVIDIA drivers.

  • Re-signing Drivers: If you disable Secure Boot, you might need to re-sign the NVIDIA drivers. Follow NVIDIA’s documentation for signing drivers.
  • Test without Secure Boot: It’s worth temporarily disabling Secure Boot to see if it improves boot times. If it does, you can then focus on properly signing the drivers.
  • Consider Nouveau Drivers: As mentioned earlier, the open-source Nouveau drivers might provide better performance and compatibility in some cases, without the need for signing.

6. Hardware Considerations

While the user has already tried disconnecting USB devices and additional monitors, it’s worth re-iterating the importance of hardware diagnostics:

  • BIOS/UEFI Settings: Ensure that your BIOS/UEFI settings are optimized for fast boot times. Disable any unnecessary features, such as network boot, if you are not using them.
  • RAM: Test your RAM with Memtest86+ to rule out memory issues.
  • Storage Devices: Check the S.M.A.R.T. status of your SSDs and HDDs to identify any potential hardware failures.
  • Overclocking: If you are overclocking your CPU or GPU, try running them at stock speeds to see if it improves boot times.

7. Kernel Parameters Tuning

Tweaking kernel parameters can sometimes improve boot times. Edit /etc/default/grub and add or modify the GRUB_CMDLINE_LINUX line.

Example: Adding Kernel Parameters

GRUB_CMDLINE_LINUX="quiet splash rd.udev.timeout=300 rd.lvm.timeout=300 systemd.show_status=false"
  • quiet splash: These parameters suppress verbose boot messages and show the graphical splash screen.
  • rd.udev.timeout=300 and rd.lvm.timeout=300: These parameters set timeouts for udev and LVM. Reducing these values might speed up boot times, but be careful not to set them too low, as it could cause problems with device initialization.
  • systemd.show_status=false: This parameter disables the display of systemd status messages during boot, which can speed up boot times slightly.

After modifying /etc/default/grub, regenerate the GRUB configuration:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Step-by-Step Troubleshooting Guide

Based on the initial analysis and the troubleshooting steps outlined above, here’s a step-by-step guide to follow:

  1. Review systemd-analyze critical-chain and systemd-analyze blame output. Identify the most time-consuming units.
  2. Address storage device initialization delays:
    • Check /etc/fstab for incorrect entries.
    • Run fsck on your storage devices.
    • Ensure correct AHCI/NVMe drivers are installed.
    • Update SSD firmware.
  3. Optimize network configuration:
    • Disable unnecessary network services (e.g., nfs-client.target).
    • Consider a static IP address.
    • Ensure correct DNS server configuration.
  4. Investigate Plymouth delays:
    • Try a simpler Plymouth theme or disable Plymouth.
    • Add nomodeset to kernel parameters.
  5. Check for other slow-starting services and disable if unnecessary.
  6. Temporarily disable Secure Boot to test for improvements. If it helps, re-sign NVIDIA drivers or consider Nouveau drivers.
  7. Review BIOS/UEFI settings for optimization.
  8. Test RAM with Memtest86+.
  9. Check S.M.A.R.T. status of storage devices.
  10. Tweak kernel parameters (e.g., rd.udev.timeout, rd.lvm.timeout, systemd.show_status).
  11. Reboot and re-analyze with systemd-analyze to see if boot times have improved.

Conclusion

Optimizing boot times in Fedora requires a systematic approach. By using systemd-analyze to identify bottlenecks and following the troubleshooting steps outlined in this guide, you can significantly reduce your Fedora boot time. Remember to test each change individually and re-analyze with systemd-analyze to track your progress.

This guide, brought to you by revWhiteShadow, aims to empower you with the knowledge and tools to take control of your Fedora boot process and enjoy a faster, more responsive system. Good luck!