Since updating openrc/baselayout, net.eth0 doesn't start with error: * Bringing up interface eth0 * 192.168.1.2/24 ... RTNETLINK answers: File exists [ !! ] * ERROR: net.eth0 failed to start Starting net.eth0 manually doesn't work either. I tried modifying /etc/conf.d/net, but for a mysterious reason, it restores itself at it previous state when trying to start net.eth0. Note that modifying this file, make net.eth0 sometimes start, but only once. At next boot, it fails again. Reproducible: Always
Are you using ifconfig syntax and have iproute2 installed in your system? If so this is a duplicate of bug 366905.
Is that if config syntax? #Generated by NetworkManager ###### Global Configuration ###### ###### Connection Configuration ###### #---------------------------------- dns_servers_eth0="212.27.40.240 212.27.40.241" routes_eth0=( "default via 192.168.1.1" ) auto_eth0="true" config_eth0=( "192.168.1.2/24" ) enable_ipv6_eth0="false"
That is iproute2 syntax. I'm reassigning to maintainers.
(In reply to comment #0) > Starting net.eth0 manually doesn't work either. I tried modifying > /etc/conf.d/net, but for a mysterious reason, it restores itself at it previous > state when trying to start net.eth0. Looking at the config file, you are using networkmanager. That's what's "mysteriously" modifying the config file. @openrc: can this be a problem of compatibility from networkmanager?
(In reply to comment #2) > #Generated by NetworkManager Networkmanager is generating an incorrect /etc/conf.d/net. It is still using bash arrays, which are not supported by openrc. I'll point out what needs to change below: > ###### Global Configuration ###### > > ###### Connection Configuration ###### > #---------------------------------- > dns_servers_eth0="212.27.40.240 212.27.40.241" > routes_eth0=( "default via 192.168.1.1" ) Needs to change to: routes_eth0="default via 192.168.1.1" > auto_eth0="true" > config_eth0=( "192.168.1.2/24" ) Needs to change to: config_eth0="192.168.1.2/24" > enable_ipv6_eth0="false"
Reassigning bug to maintainers.
Hi, all I fixed this problem but I'd like to hear from you if my approach is OK. I added an option in /etc/NetworkManager/nm-system-settings.conf so a user can choose to use baselayout style or openrc style. For reading /etc/conf.d/net, both formats can be accepted by the plug-in. But writing to /etc/conf.d/net will require the user to correctly set the option. The benefit is the use won't have to manually edit /etc/conf.d/net if he migrates to a different init system. We can add a elog message to inform users to set the option.
But the user will have to edit /etc/NetworkManager/nm-system-settings.conf. What's the difference?
(In reply to comment #8) > But the user will have to edit /etc/NetworkManager/nm-system-settings.conf. > What's the difference? I'd like to avoid pushing the work to users if there's a reliable way to determine the right style at runtime.
After reconsidering the problem, I don't think we need this change for now. You shouldn't use both NM and openrc to manage the same interface. If you want to use openrc to manage the interface, please delete the connection in NM. Then there won't be a problem. If you want to use them together, please at least let them manage different interfaces.
And if I want to use NM and not openrc? KDE depends directly on NM for network management.
(In reply to comment #11) > And if I want to use NM and not openrc? KDE depends directly on NM for network > management. Then use rc-update to remove that connection. I use KDE too and there isn't a problem.
Ok, doesn't seem to show any problems. Maybe the 'How To' should be updated to warn NM users not to add net.eth0 to rc-update?!
(In reply to comment #10) > After reconsidering the problem, I don't think we need this change for now. > > You shouldn't use both NM and openrc to manage the same interface. If you want > to use openrc to manage the interface, please delete the connection in NM. Then > there won't be a problem. If you want to use them together, please at least let > them manage different interfaces. I believe the point of maintaining compatibility with baselayout/openrc is that people can switch between NM and baselayout-1/openrc without having to change anything in their network configuration file. Also, correct me if I'm wrong, but why do we need to use bash arrays at all? Doesn't baselayout-1 work with bash strings?
(In reply to comment #14) > (In reply to comment #10) > > After reconsidering the problem, I don't think we need this change for now. > > > > You shouldn't use both NM and openrc to manage the same interface. If you want > > to use openrc to manage the interface, please delete the connection in NM. Then > > there won't be a problem. If you want to use them together, please at least let > > them manage different interfaces. > > I believe the point of maintaining compatibility with baselayout/openrc is that > people can switch between NM and baselayout-1/openrc without having to change > anything in their network configuration file. > > Also, correct me if I'm wrong, but why do we need to use bash arrays at all? > Doesn't baselayout-1 work with bash strings? The point is people should never let init system and NM manage the same interface, no matter what init system you are using. So actually there isn't a compatibility problem. I'm not sure if baselayout-1 can understand the content of bash strings if they contain multiple IP addresses.
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #10) > > > After reconsidering the problem, I don't think we need this change for now. > > > > > > You shouldn't use both NM and openrc to manage the same interface. If you want > > > to use openrc to manage the interface, please delete the connection in NM. Then > > > there won't be a problem. If you want to use them together, please at least let > > > them manage different interfaces. > > > > I believe the point of maintaining compatibility with baselayout/openrc is that > > people can switch between NM and baselayout-1/openrc without having to change > > anything in their network configuration file. > > > > Also, correct me if I'm wrong, but why do we need to use bash arrays at all? > > Doesn't baselayout-1 work with bash strings? > > The point is people should never let init system and NM manage the same > interface, no matter what init system you are using. So actually there isn't a > compatibility problem. > Yes, there is a compatibility problem. /etc/conf.d/net is parsed each time the dependencies are recalculated and this means the following ugly output: * Caching service dependencies ... /lib64/rc/sh/gendepends.sh: 9: /etc/init.d/../conf.d/net: Syntax error: "(" unexpected /lib64/rc/sh/gendepends.sh: 9: /etc/init.d/../conf.d/net: Syntax error: "(" unexpected > I'm not sure if baselayout-1 can understand the content of bash strings if they > contain multiple IP addresses. baselayout-2 and openrc have been stable for months, baselayout-1 was removed from portage almost 3 months ago. We should stop worrying about baselayout-1 compatibility :)
OK, I'm working on it.
Fixed in networkmanager-0.9.2.0-r1.ebuild. I'll leave this bug open for a few days.
Pushed to upstream. Close it now.
*** Bug 402779 has been marked as a duplicate of this bug. ***
