The thirty-second boot that turns into three minutes
You press the power button. The Fedora logo appears. The screen goes black or shows a blinking cursor with the text A start job is running for Wait for Network to be Configured. You watch the timer count up to ninety seconds. The system finally gives up, drops you into the desktop, and you lose three minutes of your morning. That delay is not a bug. It is a deliberate systemd dependency chain. The system is waiting for a network connection that either takes too long to establish or never arrives in the way systemd expects.
What is actually holding up your boot
Fedora uses systemd to orchestrate every service at startup. Services do not start in random order. They declare dependencies using Requires=, Wants=, After=, and Before= directives. The NetworkManager-wait-online.service unit exists to block the multi-user.target until the network stack reports a valid connection. Several background daemons rely on this behavior. Database servers, remote desktop agents, and container runtimes often fail silently if they start before a network interface has an IP address or a default route.
The service polls NetworkManager for a working connection. If it does not detect one within ninety seconds, it times out and allows the boot process to continue. The ninety-second limit is hardcoded in the unit file. On modern desktops and laptops, this timeout triggers constantly. Wi-Fi requires user interaction to connect. Bluetooth adapters may not be paired. VPN clients often wait for the desktop environment to load before authenticating. The service sees none of these as a valid "online" state and holds the boot target hostage.
You can see the exact timeout value by inspecting the unit file. The file lives in /usr/lib/systemd/system/. Never edit files in /usr/lib/. Package managers overwrite them during updates. If you need to modify a unit, copy it to /etc/systemd/system/ and override the specific directive. The convention keeps your changes safe across dnf upgrade --refresh cycles.
How to disable the wait safely
Disabling the service removes it from the default boot target. The system will no longer block on network availability. Your desktop will appear as soon as the core services finish starting. NetworkManager itself continues to run. It just no longer holds up the boot sequence.
Run this command to check the current state of the service.
systemctl status NetworkManager-wait-online.service
# WHY: Shows whether the service is active, inactive, or failed.
# WHY: Displays recent log lines and the unit's dependency tree.
# WHY: Always check status before making changes to avoid masking symptoms.
If the output shows active (exited) or inactive (dead), the service is either finished or waiting. Disable it immediately so it does not run on the next boot.
sudo systemctl disable --now NetworkManager-wait-online.service
# WHY: --now combines disable and stop in a single transaction.
# WHY: Removes the symlink from multi-user.target.wants.
# WHY: Stops the current instance without requiring a reboot.
The command returns instantly. You do not need to reboot to apply the change. The service is already stopped and removed from the boot chain. If you prefer a more permanent lock that prevents package updates or system tools from re-enabling it, use mask instead of disable. Masking creates a symlink to /dev/null, making the unit impossible to start until you explicitly unmask it.
sudo systemctl mask NetworkManager-wait-online.service
# WHY: Creates a /dev/null symlink to block all start attempts.
# WHY: Protects against accidental re-enablement by third-party scripts.
# WHY: Use this only if you are certain you never need boot-time network blocking.
Verify the boot is fast again
Reboot the system and watch the boot sequence. The black screen timeout should disappear. You can measure the exact time saved using systemd's built-in analyzer.
systemd-analyze blame
# WHY: Lists every unit sorted by startup time in descending order.
# WHY: Shows exactly how long each service took to initialize.
# WHY: Helps you identify other bottlenecks beyond the network wait.
Look for NetworkManager-wait-online.service in the output. It should now show a time under one second, or it should not appear at all. If you want to see the dependency chain that actually controls your boot speed, run the critical chain command.
systemd-analyze critical-chain
# WHY: Displays the longest dependency path from boot to graphical.target.
# WHY: Shows which services are blocking the desktop from appearing.
# WHY: Use this to spot hidden delays in storage or display managers.
Check the journal for any network-related warnings during the next boot. The -xe flags add explanatory text and jump to the end of the log.
journalctl -xeu NetworkManager.service
# WHY: -x adds upstream explanations for common systemd errors.
# WHY: -e jumps to the end so you see the latest events first.
# WHY: -u filters output to only the NetworkManager unit.
If the journal shows clean initialization without timeout warnings, the fix is complete. Run journalctl first. Read the actual error before guessing.
Common pitfalls and what the error looks like
Disabling the wait service breaks services that strictly require a network at boot. If you run a headless server, a database, or a remote management agent, those services may fail to bind to the correct IP address. They will fall back to localhost or exit with a dependency error.
You will see this exact message in the journal if a dependent service fails:
Failed to start PostgreSQL database server.
Dependency failed for PostgreSQL database server.
Unit postgresql.service entered failed state.
The failure is not caused by PostgreSQL itself. It is caused by the missing network guarantee. Check which services depend on the wait unit before disabling it.
systemctl list-dependencies --reverse NetworkManager-wait-online.service
# WHY: Shows every unit that lists this service as a dependency.
# WHY: Helps you identify services that will break if you disable the wait.
# WHY: Run this before making changes to avoid silent failures.
If the list contains services you need, do not disable the wait service globally. Instead, adjust the dependency in the specific service unit. Create an override file in /etc/systemd/system/<service>.service.d/ and change Requires= to Wants=. This tells systemd to start the service anyway, even if the network is not ready. The service will retry internally or start in a degraded state.
Another common pitfall is confusing NetworkManager-wait-online.service with systemd-networkd-wait-online.service. They are different units for different network stacks. Fedora Workstation uses NetworkManager. Fedora Server and minimal installs often use systemd-networkd. Disabling the wrong one does nothing. Check which network manager is active before proceeding.
systemctl is-active NetworkManager
systemctl is-active systemd-networkd
# WHY: Returns active or inactive for each network daemon.
# WHY: Confirms which stack is actually managing your interfaces.
# WHY: Prevents you from disabling the wrong wait service.
If you see [FAILED] Failed to start NetworkManager-wait-online.service during boot, your network configuration probably references a missing interface name or a broken DHCP lease. Fix the underlying network config before disabling the wait. Trust the package manager. Manual file edits drift, snapshots stay.
When to disable this service and when to keep it
Keep the service when you run a headless server that must have a working network before starting SSH, databases, or remote management daemons. Disable the service when you use a desktop or laptop where network availability is optional at boot and you prefer immediate access to your workspace. Use systemd-networkd-wait-online.service when you rely on systemd-networkd instead of NetworkManager and need the same boot-time guarantee. Mask the service when you want to prevent any package update or third-party script from re-enabling it automatically. Stay on the default configuration if you only deviate from the defaults occasionally and want to avoid troubleshooting dependency chains later.