You are not logged in.
I currently have a very simple dhcp internet setup using dhcpcd. It should be very easy to set up but for some reason I can't get it working.
All I'm trying to do is get internet working using systemd-networkd with a single interface eno1.
I set it up using the wiki's instructions, when I attempt to use the browser it says my DNS is not working. In the simple setup of systemd-networkd shouldn't I not need to fiddle with DNS? It's working fine with dhcpcd, so I don't understand what the problem is.
This is my setup with dhcpcd:
systemctl enable dhcpcd@eno1.service
and with systemd-networkd:
[Match]
Name=eno1
[Network]
DHCP=ipv4
I enabled systemd-networkd with systemd-resolved and as instructed symlinked resolv.conf:
ln -s /usr/lib/systemd/resolv.conf /etc/resolv.conf
What am I doing wrong?
Last edited by STREBLO (2016-09-06 06:28:24)
Offline
Did you disable and stop dhcpcd@eno1.service?
Did the resolv.conf symlink create successfully? What does 'ls -l /etc/resolv.conf' say?
What is the content of /usr/lib/systemd/resolv.conf?
Please also post the output of:
$ ip addr
$ ip route
# systemctl status systemd-networkd systemd-resolved
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
If dhcpcd works for you, why use something else?
Offline
dhcpcd and systemd-networkd are probably conflicting.
Try:
# systemctl disable dhcpcd@eno1.service --now
and let systemd handle everything itself.
EDIT: Sorry WorMzy, I have echoed your first point, my apologies.
Last edited by Head_on_a_Stick (2016-09-05 18:47:57)
Jin, Jîyan, Azadî
Offline
This is what I did to setup.
systemctl stop dhcpcd@eno1.service
systemctl disable dhcpcd@eno1.service --now
systemctl start systemd-networkd.service systemd-resolved.service
systemctl enable systemd-networkd.service systemd-resolved.service
ln -s /usr/lib/systemd/resolv.conf /etc/resolv.conf
This is quite strange, it must be so related to DNS because I'm able to access some sites and not others.
When I go to a Google domain, or Arch domain I get the following
This site can’t be reached
news.google.ca’s server DNS address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN
ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 28 Sep 5 14:54 /etc/resolv.conf -> /usr/lib/systemd/resolv.conf
cat /usr/lib/systemd/resolv.conf
# This is a static resolv.conf file for connecting local clients to
# systemd-resolved via its DNS stub listener on 127.0.0.53.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 74:d0:2b:7d:2b:eb brd ff:ff:ff:ff:ff:ff
inet 192.168.0.2/24 brd 192.168.0.255 scope global dynamic eno1
valid_lft 604282sec preferred_lft 604282sec
inet6 fe80::76d0:2bff:fe7d:2beb/64 scope link
valid_lft forever preferred_lft forever
ip route
default via 192.168.0.1 dev eno1 proto dhcp src 192.168.0.2 metric 1024
192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.2
192.168.0.1 dev eno1 proto dhcp scope link src 192.168.0.2 metric 1024
Offline
So I tried with netctl and it works fine too.
With netctl and dhcpcd i'm specifying nameserver 192.168.0.1, I assume I dont need to set this with systemd because i'm symlinking resolv. Am I wrong? Is the nameserver the issue?
Here's what systemd is saying while it's running:
systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabl
Active: active (running) since Mon 2016-09-05 19:59:10 PDT; 45s ago
Docs: man:systemd-resolved.service(8)
http://www.freedesktop.org/wiki/Software/systemd/resolved
http://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
http://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 5999 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 4915)
CGroup: /system.slice/systemd-resolved.service
└─5999 /usr/lib/systemd/systemd-resolved
~ » systemctl status systemd-networkd.service
● systemd-networkd.service - Network Service
Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: enabl
Active: active (running) since Mon 2016-09-05 19:55:41 PDT; 4min 59s ago
Docs: man:systemd-networkd.service(8)
Main PID: 4902 (systemd-network)
Status: "Processing requests..."
Tasks: 1 (limit: 4915)
CGroup: /system.slice/systemd-networkd.service
└─4902 /usr/lib/systemd/systemd-networkd
~ » cat /usr/lib/systemd/resolv.conf
# This is a static resolv.conf file for connecting local clients to
# systemd-resolved via its DNS stub listener on 127.0.0.53.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
Offline
OK. I think I figured it out.
nectl and dhcpcd we're automatically configuring resolv.conf, and when I disabled them they would overwrite resolv.conf with an empty file. I was checking resolv.conf, and editing it and then disabling dhcpcd or netctl, and enabling systemd-networkd. In order to fix the problem all I needed to do was manually edit resolv.conf after disabling everything else, then start systemd-networkd.
Offline
Yes, network managers interfere with each other, often breaking each other. Systemd-networkd should not be activated if you have other network managers activated too. I learnt it when I was trying to use the NetworkManager applet in Plasma, after I had configured systemd-networkd. When I was running both a systemd-networkd and NetworkManager services at the same time, I could not make my adapter connect to the network. I thought that NetworkManager was only a desktop application, but it is actually working in console too. Bottom line, it is better to stick to one manager at a time.
Besides, systemd-networkd is not very mature in my opinion, works flimsily with wpa_supplicant and lacks desktop integration. But in the future, it might become much better.
Offline
Besides, systemd-networkd is not very mature in my opinion, works flimsily with wpa_supplicant and lacks desktop integration. But in the future, it might become much better.
Counterpoint. It is solid on my system. I am not sure what you mean about flimsy, but wpa_supplicant works fine with it. wpa_supplicant_gui works like a charm. Status are provided on my system by i3 bar or lemon bar depending on my WM, and Conky.
Based upon (frustrating) personal experience, and upon the deluge of forum posts, I am not sure I would agree with your assertions as to NetworkManager. Personally, I regard it as the plague.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Counterpoint. It is solid on my system. I am not sure what you mean about flimsy, but wpa_supplicant works fine with it. wpa_supplicant_gui works like a charm. Status are provided on my system by i3 bar or lemon bar depending on my WM, and Conky.
Based upon (frustrating) personal experience, and upon the deluge of forum posts, I am not sure I would agree with your assertions as to NetworkManager. Personally, I regard it as the plague.
Well as you say, it comes to personal experience. NM is well integrated in Plasma desktop (through the plasma-nm applet) and has been extremely useful to me. For instance, it allows me to easily activate VPNs. I am not sure how to do this with systemd-networkd status GUIs.
Don't get me wrong: systemd-networkd is fine, but there are some case scenarios where it is quite frustrating. I for instance often switch between two wireless USB adapters on my machine (yes this is peculiar, but this works fine with netctl or NM), one using the nl80211 driver, the other unsupported with nl80211 and using wext. Therefore I need two different service files, one using nl80211, the other forcing -Dwext on wpa_supplicant. It would be more elegant if the driver name could be passed to the wpa_supplicant@ service, instead of having two different service files. Furthermore, if the USB adapter is not plugged in, then systemd times out at boot, waiting for the missing interface to activate. This has been pointed out on the wpa_supplicant ML: http://lists.infradead.org/pipermail/ho … 35780.html. But I am sure improvement will be done in the future.
Offline
NM is well integrated in Plasma desktop (through the plasma-nm applet) and has been extremely useful to me. For instance, it allows me to easily activate VPNs. I am not sure how to do this with systemd-networkd status GUIs.
Point well taken. I don't often have a need for VPN on this machine. On the rare occasions I do, it is openVPN which I just launch from a command line after associating. You are correct about the GUI's not supporting that.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Yes, network managers interfere with each other, often breaking each other. Systemd-networkd should not be activated if you have other network managers activated too. I learnt it when I was trying to use the NetworkManager applet in Plasma, after I had configured systemd-networkd. When I was running both a systemd-networkd and NetworkManager services at the same time, I could not make my adapter connect to the network. I thought that NetworkManager was only a desktop application, but it is actually working in console too. Bottom line, it is better to stick to one manager at a time.
Besides, systemd-networkd is not very mature in my opinion, works flimsily with wpa_supplicant and lacks desktop integration. But in the future, it might become much better.
I wasn't actually running anything at the same time, I always run just one network manager.
What I was doing is while dhcpcd was running, I would set up systemd-networkd and then once it was all set up I would stop dhcpcd and start systemd-networkd. The problem was stopping dhcpcd would edit resolv, screwing up my config.
Offline
The problem was stopping dhcpcd would edit resolv, screwing up my config.
The default action of stopping dhcpcd is to just stop - it wont change any config files, routes or ip addresses unless you tell it to release the lease on stop.
Offline
-------------
removed
=======
Last edited by alive4ever (2016-09-09 15:34:58)
Offline