omarchy
omarchy copied to clipboard
Use NetworkManager instead of systemd-networkd
It is has become basically the standard in the Linux Desktop space. it has by far the best support and a lot of apps (such as VPNs) need it to work.
I have really like Omarchy so far, but I think systemd-networkd is not a viable option for a complete desktop system. Have already bumped into a lot of issues were
- all of a sudden DNS does not resolve
- cannot use some WiFi standards
- struggling to configure Networks in the way too minimal Impala tui
NetworkManager 'just works'! All the big Linux distros use it (GNOME / KDE / Cinnamon). It is basically what is expected by most programmers who write software for Linux. Therefore, it has by far the best support for packages that do stuff with the network.
So, on behalf of all people that try to:
- set up a VPN through a GUI (like ProtonVPN, or EduVPN)
- connect to eduroam through the CLI
- connect to a modern WiFI standard like 'Enhanced Open'
Can we please just use NetworkManager, and bear with a slightly uglier Network TUI?
If using Omarchy means I cannot reliable connect to any WiFi network I encounter, it might not be a viable option for me...
edit: have been trying to connect to a new network in a flex work space for an hour and im almost capable of throwing my laptop through the space
edit: still no luck, i give up and go home. apparently systemd-networkd cannot handle the 'Enhanced Open' wifi standard. awful experience!
and if we do not switch
Could someone please explain me how I do the switch myself? I have been able to get a long way, and already had a way better time connection to new networks. But DNS resolving is not reliable, would be great if someone could help me with that.
I noticed similar issues while configuring Wireguard VPN. Configuring a custom DNS server doesn't seem to work.
I second the proposal. I also did the switch from systemd-networkd to NetworkManager manually, I've also had issues with DNS until I've explicitly set the DNS resolver to systemd-resolved. You could try if it works for you too
For vpn's generally I have found the likes of openconnect-sso to work well. Particularly to connect to an eduroam vpn, such as a university vpn. However, I've yet to try with a proton vpn or any custom DNS for that matter.
I second this proposal.
Yeah, having the option to connect to a wireguard vpn with NetworkManager would be pretty cool
This is mainly an issue of not being used to systemd-networkd. Setting up wireguard is manageable, even w/ wg-quick and proton provided config files if you set DNS via resolvectl in the PostUp hook.
Switching to NetworkManager also is possible and can even be done cleanly w/o any manual work during archinstall.
systemd-networkd not supporting wifi standards does not make any sense. iwd handles wifi authentication. impala is a frontend for iwd. iwd supports owe/wpa3.
Omakub comes with NetworkManager. Arch defaults to networkd but makes the switch easy. That's a philosophical choice. Arch favours simplicity.
The Arch Wiki covers all of this. Check it out.
This is mainly an issue of not being used to systemd-networkd. Setting up wireguard is manageable, even w/ wg-quick and proton provided config files if you set DNS via resolvectl in the PostUp hook.
Oh yeah it absolutely is, this is my first experience with Arch. I did set up Wireguard with some PostUp and PreDown hooks, and that works fine. It's just not really user friendly.
I'm not enough of an expert in NetworkManager vs systemd-networkd to make any bold claims, I just have the feeling that it would be great if Omarchy would be a little more accessible and compatible with respect to existing networking tools.
For those who could use it, these are the two simple lines to add to your Wireguard config to use a custom DNS server:
# Set up DNS servers 192.168.1.169 and 192.168.1.1 while connected to the VPN
PostUp = resolvectl dns %i 192.168.1.169 192.168.1.1; resolvectl domain %i ~.
PreDown = resolvectl revert %i
This is mainly an issue of not being used to systemd-networkd. Setting up wireguard is manageable, even w/ wg-quick and proton provided config files if you set DNS via resolvectl in the PostUp hook.
Ah, skill issue, thanks. Well, I never had any issues setting up WiFi with NetworkManager, on my own ArchLinux systems. Some things are just not compatible with networkd.
NM 'just works'. Isn't that simplicity? Do you have another argument against NetworkManager apart from 'get used to it'?
The main point is that the Linux Desktop 'ecosystem' is pretty much built around NetworkManager. Most VPN providers that build GUIs for instance, only work with NetworkManager. It's just plug and play.
NetworkManager is not bloat. It's the Swiss Army knife that has become the standard solution on the Linux Desktop.
Or, take it like this. My guess is that:
If NetworkManager is the default, less people will switch away to networkd, then the amount of people that are switching to NetworkManager now away from networkd.
So which one is the better default then?
In the end, it became clear that the best default is simply the one @dhh prefers.
The focus of Omarchy is not on GUI support, but on TUI support. nmtui doesn’t fit the Omarchy aesthetic the way Impala does. NetworkManager feels "desktop-first" not "terminal-first". Networkd + resolved + iwd get the job done — and they do it very well. Also there is an argument to be made for having the same networking stack on both desktop and server (where networkd dominates).
There is an easy, hassle free path to NetworkManager. That's the beauty of Omarchy I think. And there is Omakub.
Sure impala looks way prettier than nmtui, but I'd argue that even nmcli would be a better solution than either of them.
As the advantages of NetworkManager over networkd are already discussed above, I'll focus on the UX here:
Impala heavily sacrifices usability for the sake of appearance. Some of the bindings are quite easy to just figure out,
like [q],[j],[k],[Space],[d],[Tab],[Esc]. But [Ctrl+r]? [i],[a],[n]? Even help should at least be available under [h], in addition to [?]...
There are multiple ways this could be improved, but that just doesn't seem to be a priority of Impala.
And that's fair enough - I myself, for example, love the muscle memory I have for mplayer (the no gui version).
But if my objective is to get a new hire productive in 5 minutes, I wouldn't tell them to memorise that
[*] or [0] increase volume, and [v] enables subtitles. Sometimes the coolest solution and the most
practical one are not the same.
Regarding the preference of @dhh - yes, this is the deciding factor, as it should be. However, just as wofi
got replaced by walker, sometimes the first pick is not a forever rule. There's no shame in changing one's mind.
But if my objective is to get a new hire productive in 5 minutes, I wouldn't tell them to memorise that [*] or [0] increase volume, and [v] enables subtitles.
Very true, impala, like bluetui, lack in self-documentation. btop is way better in that regard.
In the end, it became clear that the best default is simply the one @dhh prefers.
This is a kind of dogma I can't really take seriously. As @krymzonn writes, there is no shame in changing ones mind.
For everyone who wants to (reliably) switch to NetworkManager, here is what you should do:
Switching from ND to NM (staying with IWD)
edit: please refer to https://github.com/basecamp/omarchy/issues/1414#issuecomment-3322815106 for an updated step-by-step
-
install networkmanager (+ optionally network-manager-applet / networkmanager-dmenu) from the Arch Repo:
pacman -S networkmanager -
create a new config file for NetworkManager at
/etc/NetworkManager/wifi_backend.confwith the following content:
[device]
wifi.backend=iwd
printf "[device]\nwifi.backend=iwd\n" | sudo tee /etc/NetworkManager/conf.d/wifi_backend.conf
-
mask wpa_supplicant such that it won't interupt IWD:
systemctl mask --now wpa_supplicant.service -
disable systemd-networkd
systemctl disable --now systemd-networkd -
enable NetworkManager
systemctl enable --now NetworkManager
These steps will get you a NetworkManager configuration that stays as close as possible to 'vanilla' Omarchy, because it uses IWD instead of wpa_supplicant.
Now I will look into how to make it integrate better with the waybar.
edit
made a typo in the wifi_backend set-up. the line should state wifi.backend=iwd (dot instead of underscore)
I second this.
@kromsam I just switched to netowrk manager, this item actually broke my ability to conenct to anything :)
systemctl mask --now wpa_supplicant.service
removing that fixed connectivity.
~~Tho I'm still experiencing a lot reconnects to WiFi. I still fight with OpenVPN setup.~~
----------- Edit ----------- Disconnects were with 2 running supplicants, for some reason network manager did not want to take iwd as backend. After installing networkmanager-iwd it seems to be fixed now. Reffering to wiki page https://wiki.archlinux.org/title/NetworkManager#Using_iwd_as_the_Wi-Fi_backend
I'm open to exploring this. But don't want nmtui. So we'll need to come up with a replacement for impala. Which really shouldn't be that big of a deal anyway. I did the wifi connector for the configurator here: https://github.com/omacom-io/omarchy-configurator/blob/master/configurator#L66-L101
If someone wants to explore a PR that does the switch, extracts and converts that wifi setup to a tui built on nm, then I'm happy to take a look.
There is network-manager-applet it works as interactive tray indicator, tho it's buggy and often does not show statuses correctly.
I've looked at that applet, and it's a complete non-starter. We cannot regress from what we have with impala. We should be improving upon it.
I agree, it's too buggy and most alternatives don't support vpns as well.
@kromsam I just switched to netowrk manager, this item actually broke my ability to conenct to anything :)
i made a typo, it should be:
[device]
wifi.backend=iwd
i prefer to not use the custom networkmanager-iwd package. networking is too vital to leave up to the AUR imho.
If someone wants to explore a PR that does the switch, extracts and converts that wifi setup to a tui built on nm, then I'm happy to take a look.
Not a PR yet, but I've found a small project that gets us halfway there, and I've forked it to better fit Omarchy's needs: https://github.com/krymzonn/tui-network
So far I've just had a couple of hours of fun with it, while learning uv and textual. Textual appears very easy to work with and has built-in theming support, that could potentially work across multiple applications. I'm happy to take this quite a bit further.
Because iwd is the wifi backend (using my method), you can still use Impala to manage networks under NetworkManager, so it doesn't really have to be replaced.
I'll see how many additional NM features I can get working, so far coding with textual has been very enjoyable. There's also the slight self-documentation issue with Impala.
Version 2.0: From systemd-networkd to NetworkManager
After some tweaking, I got the following configuration to work on a fresh Omarchy installation. These steps will get you a NetworkManager configuration that stays as close as possible to 'vanilla' Omarchy. It uses IWD as its backend and systemd-resolved for DNS resolution. Therefore Impala still works. Now it would be great if we can test these steps on other systems and see if this is a reliable way to move to NetworkManager.
1. Install NetworkManager
pacman -S networkmanager
(+ optionally network-manager-applet / networkmanager-dmenu)
2. Configure NetworkManager
Create two configuration files in /etc/NetworkManager/conf.d
2.1 wifi_backend.conf
[device]
wifi.backend=iwd
2.2 dns.conf
[main]
dns=systemd-resolved
printf "[device]\nwifi.backend=iwd\n" | sudo tee /etc/NetworkManager/conf.d/wifi_backend.conf
printf "[main]\ndns=systemd-resolved\n" | sudo tee /etc/NetworkManager/conf.d/dns.conf
3. Symlink resolv.conf
/run/systemd/resolve/stub-resolv.conf to /etc/resolv.conf
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
4. Mask wpa_supplicant
systemctl mask --now wpa_supplicant.service
5. Disable systemd-networkd
systemctl disable --now systemd-networkd.socket
systemctl disable --now systemd-networkd-varlink.socket
systemctl disable --now systemd-networkd
6. Restart systemd-resolved
systemctl restart systemd-resolved
7. Enable NetworkManager
systemctl enable --now NetworkManager
Troubleshooting
~The one issue I seem to have is that my DHCP set DNS-server (PiHole) does not resolve urls, but CloudFlare does. DHCP gives me the following error in systemctl status systemd-resolved: DNSSEC validation failed for question google.com IN A: no-signature. But this might be a local issue.~ > i had to enable DNSSEC on the pihole
Well. i remove iwd and put wpa_supplicant with NetworkManager. its the best choice to me. iwd cant handle captive portals for wifi connection. with http request or not.
iwd cant handle captive portals for wifi connection. with http request or not.
https://nunq.net/posts/2023/captive
does this help?
iwd cant handle captive portals for wifi connection. with http request or not.
https://nunq.net/posts/2023/captive
does this help?
no. im using the nm now. thx
I did this which works on both my computers and gives me an easy way to connect to a wifi with a cert required which i could not get to work with Impala or use ProtonVPN, Wireguard or any other VPN:
10. Move to NetworkManager
sudo pacman -S networkmanager network-manager-applet
sudo systemctl disable --now iwd.service
sudo systemctl mask iwd
sudo systemctl enable --now wpa_supplicant
sudo systemctl enable --now NetworkManager.service
sudo systemctl disable --now iwd systemd-networkd systemd-networkd-wait-online
Edit this file:
sudo nano /etc/NetworkManager/conf.d/wifi_backend.conf
And add this to it:
[device]
wifi.backend=wpa_supplicant
Edit this file:
sudo nano /etc/NetworkManager/NetworkManager.conf
And add this to it:
[main]
plugins=keyfile
[device]
wifi.backend=wpa_supplicant
sudo systemctl restart NetworkManager
Verify (Should only show wpa):
ps -e | grep -E "iwd|wpa"
nmcli networking on
nmcli radio wifi on
Verify:
nmcli general status
nmcli device status
sudo reboot
Connect to wifi:
nmcli device
nmcli connection show
nmcli device wifi list
nmcli device wifi connect "SSID"
I've unfortunately run into this too, the lack of network manager makes a lot of applications act dumb (one concession to windows, their passive connection test is just a TTL check on incoming packets)
Outside of other issues already presented, steam uses dbus to check for internet using network manager. It's absence makes it failover to trying anyway, but it makes it hang longer while booting and big picture mode permanently thinks there's no internet despite most networking features working (offline mode can't be toggled in that mode while internet isn't available, but can in desktop, odd application limitation).
Some searching and AI says it'd likely be possible to dummy out the DBus service and just make the system think it always has internet, and then there's also installing network manager and making it use iwd as a backend, as others have mentioned. I like impala and iwd and for the most part am perfectly happy with them on their own (unless I haven't thought of something, having network detected as always on might not be the worst solution, as there's 1 million cli programs you can use to check if it really isn't working) but having programs not behave as intended in edge cases probably isn't the best solution. There's also VPNs not working out of the box with iwd AFAIK, haven't gotten around to that yet.
Just presenting my thoughts anyway. Anybody more familiar with networking conventions on Linux have more to say on what might be best?
This is absolutely crucial IMO, I needed PEAP Enterprise WI-Fi at my office and had to set up NetworkManager using tethered Wifi to fix it. Thanks @Furyfree !
@Furyfree 's method also disables IWD, and I am not sure whether that is desireable. IWD is the direction Linux is heading, and I think it is a better option than wpa_supplicant.
So I hope people can also try my steps to use NM with IWD as backend. I think that woukd be the ideal middleground between using legacy-software for compatibility (NetworkManager) with a more modern backend.
See: https://github.com/basecamp/omarchy/issues/1414#issuecomment-3322815106