You are not logged in.
I have tried using static IP setup with netcfg and using the example ethernet-static, but this is unreliable - see thread https://bbs.archlinux.org/viewtopic.php?pid=1217870
I now just tried this https://wiki.archlinux.org/index.php/Ne … IP_address but this doesnt work either, I think it cannot find the new interface name because during boot network.service fails, but if I run:
systemctl start network.service
after boot, it works 100%, is it somthing to do with the udev rule running too late?
*Edit
changed the title
Last edited by jrussell (2013-05-12 18:47:43)
bitcoin: 1G62YGRFkMDwhGr5T5YGovfsxLx44eZo7U
Offline
Are you sure you also enabled the network.service by doing:
systemctl enable network
And otherwise try to use journalctl to find out what the exact problem is, for example:
journalctl -u network.service
Either way, you need to give more details.
Offline
admin@russell-server ~ % sudo systemctl status network.service
network.service - Wired Static IP Connectivity
Loaded: loaded (/etc/systemd/system/network.service; disabled)
Active: inactive (dead)
Jan 22 11:52:05 russell-server ip[131]: Cannot find device "enp1s5"
Jan 22 11:55:48 russell-server systemd[1]: Starting Wired Static IP Connectivity...
Jan 22 11:55:48 russell-server systemd[1]: Started Wired Static IP Connectivity.
Jan 22 11:56:32 russell-server systemd[1]: Stopping Wired Static IP Connectivity...
Jan 22 11:56:32 russell-server systemd[1]: Stopped Wired Static IP Connectivity.
Jan 22 11:57:03 russell-server systemd[1]: network.service: main process exited, code=exited, status=1/FAILURE
Jan 22 11:57:03 russell-server systemd[1]: Failed to start Wired Static IP Connectivity.
Jan 22 11:57:03 russell-server systemd[1]: Unit network.service entered failed state
Im using "enp1s5" in my netcfg config which works, but netcfg also fails on some boots, not very often though but this is a headless server, and I reboot after updates every now and again.
admin@russell-server ~ % sudo journalctl -u network.service
-- Logs begin at Sun 2012-10-21 19:54:00 SAST, end at Tue 2013-01-22 13:05:27 SAST. --
Jan 22 11:52:05 russell-server ip[131]: Cannot find device "enp1s5"
-- Reboot --
Jan 22 11:57:03 russell-server ip[129]: Cannot find device "enp1s5"
Last edited by jrussell (2013-01-22 11:08:37)
bitcoin: 1G62YGRFkMDwhGr5T5YGovfsxLx44eZo7U
Offline
If you do "ip link" after boot does your ethernet interface get "enp1s5" as name? Could be that it changed due to the recent systemd changes. Check if the correct name is in the "/etc/conf.d/network" file.
Otherwise I think there is indeed some bug about ethernet interface naming, getting their final/correct name too late.
Offline
If you do "ip link" after boot does your ethernet interface get "enp1s5" as name? Could be that it changed due to the recent systemd changes. Check if the correct name is in the "/etc/conf.d/network" file.
Otherwise I think there is indeed some bug about ethernet interface naming, getting their final/correct name too late.
enp1s5 always shows up in ip-link, enp1s5 is in the config file, the problem with netcfg has been happening for a while now, before the recent systemd interface naming change
bitcoin: 1G62YGRFkMDwhGr5T5YGovfsxLx44eZo7U
Offline
There is apparantly a possible bug, but its from last october so maybe its solved and its not the real cause of your problem.
Our current systemd units have a fatal flaw: They may fail because they
are started before the needed devices show up. This patch series adds
new units that fix that. However, the change is not transparent for the
user and requires different configuration.
But anyway, I read on this forum about a similar problem, and it was solved by adding a delay before setting the ethernet card, you can maybe try that.
By adding in your network.service file right before it sets up everything:
ExecStart=/usr/bin/sleep 10
ExecStart=/sbin/ip link set dev ${interface} up
Offline
There is apparantly a possible bug, but its from last october so maybe its solved and its not the real cause of your problem.
Our current systemd units have a fatal flaw: They may fail because they
are started before the needed devices show up. This patch series adds
new units that fix that. However, the change is not transparent for the
user and requires different configuration.But anyway, I read on this forum about a similar problem, and it was solved by adding a delay before setting the ethernet card, you can maybe try that.
By adding in your network.service file right before it sets up everything:
ExecStart=/usr/bin/sleep 10
ExecStart=/sbin/ip link set dev ${interface} up
This works
bitcoin: 1G62YGRFkMDwhGr5T5YGovfsxLx44eZo7U
Offline
I can confirm the issue here is that the configuration commands (via the ip utility) are being issued before the network device is available. Although you can solve it by inserting a moderate sleep as shown, there's a better way.
After the system has fully booted, issue systemctl -t device and search the list for an item matching the relevant ethernet device. Mine, for instance, is called sys-subsystem-net-devices-enp0s10.device. This object is registered to systemd through udev and should happen with the default configuration automatically. (If it's not there, then the udev rules need to be fixed.)
Now open up /etc/systemd/system/network.service and add a new line to the the unit section that looks like this: After=sys-subsystem-net-devices-enp0s10.device . This will cause the configuration to occur only after the ethernet device is actually available. You should likewise remove any sleep command you put into the ExecStart set since that will now be unnecessary.
In my case, I also removed the Wants=network.target line. Wants indicates a soft dependency, and in this case apparently the idea is to cause any other network-associated services to start. In my opinion, this isn't the correct place to be specifying that (a higher level or more generic service ought to). Further, in some cases it might be desirable to activate the ethernet device without touching anything else.
{EDIT}: I forgot one important thing. In systemd, After does not imply Requires. So what exactly happens when After is used without Requires, or Requires without After, is not entirely clear to me. The initialization may be incorrect due to a race condition (or similar bug). To be safe, specify both an After= and a Requires= line with the same device.
Last edited by kagerato (2013-01-23 20:12:56)
Offline
Thanks it worked. I spen't 2 hours trying to figure out why it did not work.
Had to edit /etc/systemd/system/mutli-user.target.wants/netcfg@ethernet-static.service because i used "systemctl enable netcfg@ethernet-static"
Offline
Nice, the "After=" is the way to go. Sleep works, but is a dirty way. I just couldn't say what initializes the network devices, and thus what to wait for. So I learned something today.
Don't know if the not waiting for a ready device is a bug or if it is deliberately this open to configuration. If it is not a bug, then I guess it should be added in the example code on the wiki.
A Requires without After still causes both processes to start parallel and not wait till the one that is specified in After= is fully started. It is only when the process is stated in After= that it waits till the first process gives it OK that it has properly started that the 2nd process begins booting up.
The reverse I'm not sure (if after= is used without requires=). But my guess is the following when we do dhcpcd after your fix
process dhcpd:
After=sys-subsystem-net-devices-enp0s10.device
That dhcpcd is started anyway (eventually) even when sys-subsystem-net-devices-enp0s10.device is not. Because net-devices fails to start, or just is not in the systemd list.
Last edited by BKE (2013-01-25 11:16:49)
Offline