[arch-general] Network-Issues after last updates
Hi there, I got network-issues on my servers after the last upgrades (1-2 weeks). I found very few time to upgrade my servers more often the last days ... so I did systemd 208->210 and linux 3.12.9 to 3.13.x upgrade together. I still using netcfg to staticly configure my cards, the only hw-card was eth0 and now named ens3, which was the first problem on that upgrade ... changing eth0 to ens3 in configuration still wont fix the problem... I'm now upgrading to networkd or netctl, but since I'm not the only in IRC which got the problem you might consider to send out a warning for this might happen. Best regards Ruben
On Wednesday, March 05, 2014 12:26:06 Ruben Kelevra wrote:
Hi there,
I got network-issues on my servers after the last upgrades (1-2 weeks).
I found very few time to upgrade my servers more often the last days ... so I did systemd 208->210 and linux 3.12.9 to 3.13.x upgrade together.
I still using netcfg to staticly configure my cards, the only hw-card was eth0 and now named ens3, which was the first problem on that upgrade ... changing eth0 to ens3 in configuration still wont fix the problem...
Since the recent systemd (udev) version, interface name is changed by udev rule 80-net-setup-link.rules. You should see this message during the systemd upgrade: :: Network device naming is now controlled by udev's net_setup_link builtin. Refer to the NETWORK LINK CONFIGURATION section of the udev manpage for a full description. To keep the old way of naming ("eth0", ...), just touch to override the file: # touch /etc/udev/rules.d/80-net-setup-link.rules And after a restart, you'll get the old names back. The .install script in systemd package should have handled this, though. Regards, Felix Yan
Am 05.03.2014 12:26, schrieb Ruben Kelevra:
I still using netcfg to staticly configure my cards, the only hw-card was eth0 and now named ens3, which was the first problem on that upgrade ... changing eth0 to ens3 in configuration still wont fix the problem...
Old installations still had interface renaming disabled by default (on Arch). This got lost on the overhaul of the network interface handling in udev.
I'm now upgrading to networkd or netctl, but since I'm not the only in IRC which got the problem you might consider to send out a warning for this might happen.
netcfg can fail for various reasons when used with systemd - don't use it.
On Wed, Mar 5, 2014 at 12:36 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 05.03.2014 12:26, schrieb Ruben Kelevra:
I still using netcfg to statically configure my cards, the only hw-card was eth0 and now named ens3, which was the first problem on that upgrade ... changing eth0 to ens3 in configuration still wont fix the problem...
I suspect your problem comes more from the netctl/systemd-networkd side. I have been trying since many days now to setup a simple bridge for a visualised machine with netctl/systemd-networkd, and my container still cna't reach the network. I have tried all kinds of configurations, but all left me with a broken network on container. I suspect that in the near future, systemd will take care of the overall network setup (like more and more services on our machines). So the correct question is about the necessity to keep netctl along with networkd. I feel like at some point some conflicting configurations will arise.
Well I gonna try to move the three Server to networkd, but with this complex network-setup this is a hugh pain. :/ Best Regards, Ruben 2014-03-05 13:14 GMT+01:00 arnaud gaboury <arnaud.gaboury@gmail.com>:
On Wed, Mar 5, 2014 at 12:36 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 05.03.2014 12:26, schrieb Ruben Kelevra:
I still using netcfg to statically configure my cards, the only hw-card was eth0 and now named ens3, which was the first problem on that upgrade ... changing eth0 to ens3 in configuration still wont fix the problem...
I suspect your problem comes more from the netctl/systemd-networkd side. I have been trying since many days now to setup a simple bridge for a visualised machine with netctl/systemd-networkd, and my container still cna't reach the network. I have tried all kinds of configurations, but all left me with a broken network on container. I suspect that in the near future, systemd will take care of the overall network setup (like more and more services on our machines). So the correct question is about the necessity to keep netctl along with networkd. I feel like at some point some conflicting configurations will arise.
On Wed, Mar 5, 2014 at 1:17 PM, Ruben Kelevra <cyrond@gmail.com> wrote:
Well I gonna try to move the three Server to networkd, but with this complex network-setup this is a hugh pain. :/
I confirm. There is a clear lack of solid documentation and this service is quite new. I have set up many bridges in the past very easily, and it is the first time I found myself like a total n00b trying to set up a bridge ! Do not hesitate to post on systemd-devel mailing list. Only a few people here will answer (Lenart being the most active), but if you are lucky, you will find solutions.
The Problem is that I got ~25 Interfaces on any Server ... Bridges, Mesh, Tunnel Interfaces ... Best Regards Ruben 2014-03-05 13:22 GMT+01:00 arnaud gaboury <arnaud.gaboury@gmail.com>:
On Wed, Mar 5, 2014 at 1:17 PM, Ruben Kelevra <cyrond@gmail.com> wrote:
Well I gonna try to move the three Server to networkd, but with this complex network-setup this is a hugh pain. :/
I confirm. There is a clear lack of solid documentation and this service is quite new. I have set up many bridges in the past very easily, and it is the first time I found myself like a total n00b trying to set up a bridge ! Do not hesitate to post on systemd-devel mailing list. Only a few people here will answer (Lenart being the most active), but if you are lucky, you will find solutions.
On Wed, Mar 5, 2014 at 1:26 PM, Ruben Kelevra <cyrond@gmail.com> wrote:
The Problem is that I got ~25 Interfaces on any Server ... Bridges, Mesh, Tunnel Interfaces ...
oh la la, I am very sorry for you. I wish I could help. Another solution could be to give a try at Libvirt. It is usually a solid service. Good luck
participants (4)
-
arnaud gaboury
-
Felix Yan
-
Ruben Kelevra
-
Thomas Bächler