You upgraded Fedora and the boot hangs on the logo
You just finished a fresh install of Fedora Workstation. The desktop looks great, the tiling window manager is set up, and you are ready to code. You reboot to test a kernel module, and the screen hangs on the Fedora logo for forty-five seconds. You check your old Windows machine. It is at the login screen before the Fedora splash even fades. Something is holding up the boot process, and you need to know what it is before you start masking random services and breaking your network.
What's actually happening
Boot time is not a single event. It is a chain of dependencies managed by systemd. Each service declares what it needs before it starts. If Service A waits for Service B, and Service B waits for Service C, the total time adds up. The bottleneck is rarely the disk speed. It is usually a service waiting for a condition that takes too long to resolve, or a service that starts when it does not need to.
Think of the boot process like a kitchen crew preparing for service. The barista cannot pour coffee until the water boils. The water cannot boil until the kettle is plugged in. If the head chef insists that the coffee machine must be perfectly calibrated before the lights are turned on, the whole shop opens late. Systemd is the head chef managing the dependencies. Sometimes a dependency is too strict. A service might wait for the network to be fully online before allowing the graphical interface to load. On a desktop, you do not need the network before the GUI appears. You can relax that dependency.
The initramfs image also plays a role. This temporary filesystem loads early to mount your real root partition. It contains the kernel modules needed to access your storage. If it contains unnecessary drivers or modules, it inflates the size and slows down the early boot phase. Fedora rebuilds the initramfs automatically when you update the kernel, but manual changes to storage or drivers may require a manual rebuild.
Run systemd-analyze blame first. Masking services blindly breaks things.
Identify the bottleneck
Before you change anything, you need data. Guessing which service is slow leads to mistakes. Systemd provides tools to measure exactly where the time goes.
Here is how to identify which services are consuming the most time during boot.
systemd-analyze blame
# WHY: Lists all loaded units sorted by the time they took to activate.
# Look for services at the top of the list that take seconds, not milliseconds.
# Services taking less than 100ms are normal and should not be touched.
The output shows a list of services with their activation times. Scan for outliers. NetworkManager-wait-online.service often appears here with a delay of ten to thirty seconds. This service waits for the network connection to be fully established before signaling that the boot is complete. For a server, this might be necessary. For a desktop, it is usually unnecessary.
Here is how to visualize the dependency chain that determines the boot time.
systemd-analyze critical-chain
# WHY: Displays the dependency tree for the default target.
# The service with the longest activation time on the critical path is your bottleneck.
# Services in parentheses are not on the critical path and do not affect total boot time.
The critical chain shows the path of dependencies that systemd must wait for. If graphical.target waits for network-online.target, and network-online.target waits for NetworkManager-wait-online.service, then that service is on the critical path. Removing it from the chain reduces the total boot time.
Check the critical chain. The longest path determines the boot time.
Fix the common culprits
Once you have identified the slow service, you can take action. The most common fix is to mask NetworkManager-wait-online.service. Masking prevents the service from starting at all. This does not stop NetworkManager from managing your connections. It only removes the boot delay.
Here is how to disable the network wait service without breaking NetworkManager itself.
sudo systemctl mask NetworkManager-wait-online.service
# WHY: Creates a symlink to /dev/null, preventing the service from starting at all.
# This stops the boot sequence from pausing until the network connection is fully established.
# NetworkManager itself continues to run and manage connections in the background.
Masking is stronger than disabling. systemctl disable stops a service from starting automatically, but you can still start it manually. systemctl mask creates a symlink to /dev/null. The service cannot start even if another service tries to pull it in. Use masking for services you never want to run during boot.
If you do not use Bluetooth, masking bluetooth.service can save a few seconds. If you do not have a cellular modem, ModemManager.service might be polling hardware that is not present. Check the blame output. If ModemManager takes two seconds or more, mask it.
sudo systemctl mask ModemManager.service
# WHY: Prevents ModemManager from starting if you have no cellular hardware.
# This stops the service from polling for modems that do not exist.
# Only do this if you confirmed ModemManager is slow and you do not use mobile broadband.
Do not mask firewalld.service. The original advice to mask firewalld is incorrect. firewalld manages your firewall rules. Masking it leaves your system exposed to network attacks. If firewalld appears in the blame output, it is likely doing its job. Do not mask it. Investigate other services instead.
Masking is permanent until you unmask. Test in a VM if you are unsure.
Rebuild the initramfs
If you have installed new kernel modules, changed storage configuration, or suspect the initramfs is bloated, you can rebuild it. Dracut is the tool Fedora uses to build the initramfs. Running dracut --force regenerates the image for the running kernel.
Here is how to rebuild the initramfs to ensure it matches your current kernel and configuration.
sudo dracut --force
# WHY: Forces dracut to regenerate the initramfs image for the running kernel.
# This incorporates any new kernel modules or changes to dracut configuration.
# Use this after installing new drivers or changing storage configuration.
Configuration for dracut lives in /etc/dracut.conf.d/. You can add modules or exclude them in files here. Excluding modules you do not need can shrink the initramfs. For example, if you do not use RAID, you can exclude the raid module. This is advanced configuration. Stick to dracut --force for routine maintenance.
Edit /etc/. Never edit /usr/lib/. Files in /usr/lib/ ship with packages and will be overwritten on update. Your changes in /etc/ persist.
Verify the improvement
After making changes, you need to confirm they worked. Reboot the system and run the analysis again.
Here is how to measure the total boot time and compare it to your baseline.
systemd-analyze
# WHY: Prints the total time spent in firmware, loader, kernel, and initrd phases.
# Compare the "initrd" and "userspace" times before and after your changes.
# A reduction in userspace time indicates your service changes took effect.
The output shows the breakdown. Firmware is the BIOS or UEFI. Loader is GRUB. Kernel is the Linux kernel loading. Initrd is the initial ramdisk. Userspace is systemd starting services. On modern hardware, firmware and kernel are usually fast. The delay is almost always in userspace. If the userspace time dropped, your fix worked.
If you see a failure message like Failed to start Network Manager Wait Online after masking, do not panic. The failure is expected. The service is masked, so systemd cannot start it. The boot continues without waiting. This is the desired behavior.
Reboot before you debug. Half the time the symptom is gone.
Common pitfalls and error messages
Masking the wrong service can break your system. Here are the errors you might encounter and how to recover.
If you mask NetworkManager.service instead of NetworkManager-wait-online.service, you lose network connectivity. The error Error: Transaction test error: package NetworkManager conflicts with... may appear if you try to reinstall packages that depend on it. To recover, boot from a live USB or use the rescue target. Unmask the service:
sudo systemctl unmask NetworkManager.service
sudo systemctl start NetworkManager.service
# WHY: Restores the symlink and starts the service immediately.
# This brings back network management functionality.
If you mask firewalld.service, your firewall is disabled. You will not see an error, but your system is vulnerable. Unmask it immediately:
sudo systemctl unmask firewalld.service
sudo systemctl start firewalld.service
# WHY: Restores the firewall service.
# Always keep firewalld enabled on systems connected to networks.
If dracut --force fails, check the journal for errors. Dracut may fail if a required module is missing or if there is a syntax error in the configuration.
journalctl -xeu dracut.service
# WHY: Shows logs for the dracut service with explanatory text.
# Look for errors related to missing modules or configuration files.
# Fix the configuration and run dracut --force again.
journalctl -xe reads better than journalctl alone. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use masking versus disabling
Choosing the right method depends on your goal. Use the parallel structure below to decide.
Use systemd-analyze blame when you need to identify which services are slowing down the boot sequence. Use systemd-analyze critical-chain when you want to see the dependency tree and find the bottleneck on the critical path. Use systemctl mask when a service is safe to disable entirely and you want to prevent it from starting under any circumstances. Use systemctl disable when you want to stop a service from starting automatically but allow it to be started manually later. Use dracut --force when you have installed new kernel modules or changed storage configuration and need to update the initramfs. Stay on the default configuration when you are unsure about a service's role. A slow boot is annoying. A broken boot requires a rescue environment.