Not sure if this is a bug or working as intended. Anyway, the bug reporting process was too complicated so I’m posting here even though this isn’t a question.
I had a frustrating experience booting my laptop. Booting suddenly took very long to get to the login screen. Luckily I had removed the “quiet splash” kernel parameters so I was able to see what was happening. The boot process was stuck waiting on networkmanager-wait-online.service . I saw messages about failing to connect to wifi. This makes sense because the network I’m connected to is flaky. What doesn’t make sense is that the boot process waits for wifi. I want to get to the login screen as quickly as possible. Wifi can keep connecting in the background. If I hadn’t had kernel messages visible, this would have been even more confusing and I would have thought that the system was broken.
I understand there are some use cases for waiting for the network. Maybe your login is tied to network resources somehow. It is fine if advanced users have the ability to configure their system that way. But the default should definitely not wait for the network.
This was on Fedora Workstation 43. Wifi set up through the NetworkManager gui. Pretty fresh install.
It’s fine if disabling this service meets your needs, but you’re confusing a custom workaround that could negatively affect others with a generic and scalable solution.
There’s a reason this service is enabled by default and normally it should just work, so your experience is quite abnormal and indicates some edge case problem that is best to investigate and report properly.
Luckily I had removed the “quiet splash” kernel parameters so I was able to see what was happening. The boot process was stuck waiting on networkmanager-wait-online.service .
As an aside, while that works without issue, you can also just hit the ‘esc’ key when the spinner appears on the screen. Doing so will toggle display of the boot text. That can be helpful if you don’t want to modify the kernel parameters.
What’s the argument in favor of enabling it by default? Which use case does it support? How does it negatively affect others?
.I can’t speak for anyone else, but the value isn’t in the NM-wait-online service except as other services often require access to the network (e.g., NFS services) and will fail if there’s no network.
If you don’t have any services that require network at startup, go ahead and disable the service:
Thanks for the explanation! The perspective I’m coming from is that I distinguish between technical users and non technical users.
A non technical user doesn’t know about systemd services and how to disable them and doesn’t have a boot dependency on the network like NFS.
A technical user might have this dependency and knows about those details. Although even for a technical user the probability of needing this is low. What percent of Fedora Desktop users do you think have a setup that requires this? I don’t have any statistics on this but my intuition is 5%.
Based on this I want Fedora Desktop to have the right defaults for a non technical users. Someone setting up an NFS home directory can read the docs and enable the wait service. But a non technical user can’t be expected to understand and fix this problem. The service shouldn’t be enabled by default. (Unless someone else posts another use case for this that I’m unaware of.) I want to emphasize again that this is Fedora Desktop and that the internet connection is wireless. This makes it very unlikely that the user wants to wait for it on boot.
I absolutely get your point. It bothers you and think it does/will bother other folks.
That may well be true, but it’s not my use case.
There are other use cases other than nfs (in that case, I was thinking /home or other user data on nfs shares). VPN in an adversarial environment (like pretty much any public network and many corporate ones too) is another use case for NM-wait-online.
All that said, i have no axe to grind either way.
I am also not someone who makes decisions for Fedora defaults. As such, I suggest submitting a change proposal to the Project Discussion section of this site. I’d expect that folks who do make such decisions would be more likely to respond there rather than here.
In the meantime, I recommend disabling NM-wait-online.