Hi, openrc-0.12 uses the loopback initscript to setup the loopback interface. In previous versions, net.lo did that work. With the release of openrc-0.12 net.lo moved to the netifrc package. When unmerging <openrc-0.12 we will remove net.lo, but like any other enabled initscripts, we won't remove it from the runlevel. The problem is, that because most systems upgrading to openrc-0.12 will also install netifrc, which will bring back net.lo, we will now start loopback *and* net.lo (because the net.lo initscript is back and wasn't removed from the runlevel). This will result in problems like described in bug 490512. Conclusion: We need to make sure that net.lo is removed from the runlevel. PS: This shows another problem, not sure if I should fill another bug for that: Is it a wanted behavior that we will keep references to removed initscripts? For example, if openrc would make sure that not existing initscripts are removed from the runlevels (for example when updating the deptree), we wouldn't have this problem.
this might also break shorewall setups http://forums.gentoo.org/viewtopic-t-978456.html 0.12.4 should not be marked stable.
I disagree with your comment wrt not stabilizing OpenRC-0.12.4. I'm not sure I feel comfortable having OpenRC run through all of your runlevels in /etc/runlevels and wiping the broken symlinks as part of the upgrade process.
Guys, there is a concern about loopback and net.lo both starting the loopback interface. I recommend that we tell people not to have net.lo itself added to any runlevels and let loopback handle the loopback interface. Thoughts? William
Let me clarify since the poster of this bug caught me in IRC. There should only be one script controling the loopback interface, and that should be /etc/init.d/loopback. I recommend that we have everyone remove net.lo from the boot runlevel. Thanks, William
And i recommend you post that as a news... ewarn just sucks to tell anyone anything of importance. Because we have no gentoo default elog viewer. People may just not save elog/ewarn... And it's something we may also not see on screen because of emerge hide output with job>1 Gentoo have a default news reader ; better use it. What's the point to change net.lo to loopback?
(In reply to Stéphane Pagnon from comment #5) > And i recommend you post that as a news... ewarn just sucks to tell anyone > anything of importance. Because we have no gentoo default elog viewer. > People may just not save elog/ewarn... And it's something we may also not > see on screen because of emerge hide output with job>1 > Gentoo have a default news reader ; better use it. > > What's the point to change net.lo to loopback? 'net.lo' is optional as it's only installed when netifrc is emerged. 'loopback' is generic and always available.
(In reply to William Hubbs from comment #4) > Let me clarify since the poster of this bug caught me in IRC. > > There should only be one script controling the loopback interface, and > that should be /etc/init.d/loopback. > > I recommend that we have everyone remove net.lo from the boot runlevel. > > Thanks, > > William Until people do remove net.lo from the boot runlevel, OR in case people choose not to (ie, just want to keep everything in netifrc), we should probably have a way to somehow make net.lo provide loopback, or have loopback be a no-op if net.lo is started already (or first; i expect it can be forced first via a simple 'use net.lo' in depend{} yes?)
As far s I know, there is not a valid reason for the net.lo script to configure the loopback interface. The only command that people need to run is rc-update del net.lo boot
I am moving this to netifrc, since this really isn't an openrc issue. To resolve it, we just need a newsitem for people who have netifrc installed telling them to run the command in my previous comment.
*** Bug 493516 has been marked as a duplicate of this bug. ***
Using net.lo to configure the loopback is a valid case for people who are doing DSR and want to have extra IP addresses configured on the lo interface (this is common in large server environments).
That's an old bug, but the issue is still there.