Summary: | sys-apps/openrc-9999 commit f583030e3cbf: bad assumptions break net | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Duncan <1i5t5.duncan> |
Component: | OpenRC | Assignee: | OpenRC Team <openrc> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | openrc:oldnet | ||
Package list: | Runtime testing required: | --- |
Description
Duncan
2012-01-06 12:03:44 UTC
This note is for the rest of the openrc team... I'm looking into this real quick. I confirmed this myself as well and reverted the commit you suggested in commit 84aa4ba. I am about to release openrc-0.9.8, so thanks for the catch. I do have another way I'm thinking about doing this, but, I'll look into it after the release. Thanks much for the report. William Unfortunately, while reverting the commit for release fixed the problem temporarily, it's baackkk! =:^( commit 61e05331d14a08fa909526fda15470a1ca4927dd reintroduces the problem... somehow! I'm on d02d3af02e4254b04949de546c5d53af82cc2fc2 now, with the problem worked around as below. I don't have time to dig further ATM, but the program line definitely has something to do with it, as the following in iproute2_depend (unindented are my changes, note that tabs are converted to spaced due to my select/paste method) works: iproute2_depend() { local x x=$(_which ip) # [ -z "$x" ] && return 1 program $x program /dev/null/does_not_exist provide interface after ifconfig } So simply returning 1 and not finishing the depend doesn't work, but deliberately setting program to an invalid location DOES work. Either the error return is being ignored and the module is loaded anyway, or something else is loading the module, somehow. Setting an invalid program line works, but not setting it at all doesn't. Without double-checking, I'd guess that there's nothing catching that "return 1" error (which I had to comment out to get the stuff below it to process, so it's definitely bailing out of the depend as the logic suggests it should), so the thing is still loaded... unless the program line is set invalid. Please retest 9999, I've got a new commit in. http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=commit;h=4255ba175bd7c3ccadc5bc894d00ccb844467067 If you have network issues with it, I want to see the output of: /etc/init.d/net.$IFACE --verbose start (In reply to comment #4) > Please retest 9999, I've got a new commit in. > > http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=commit;h=4255ba175bd7c3ccadc5bc894d00ccb844467067 > > If you have network issues with it, I want to see the output of: > /etc/init.d/net.$IFACE --verbose start Ahh! Someone that can think like openrc's net script does! Verified/fixed! =:^) FWIW I have a "portage git-helper" script that for git-based overlays or live-packages, makes it MUCH easier to pull and then check updates (git-whatchanged and if I see anything interesting, git-show) before I do the actual build. For openrc and a couple other live packages I follow upstream very closely on, I routinely use that script to check updates since the last pull, and paid special attention this time due to this bug. Reading your commit I saw that for the first time since the triggering commit, someone was actually following the net.lo script _load_modules logic and working with it, not trying to fight it. As such, I was quite confident of the fix (barring some trivial typo/thinko) even before I built and tried it. Sure enough, merged and rebooted, and networking (both net.lo and net.eth0 interfaces) came up exactly like it's supposed to do! =:^) So we have the old logic working again, but now with the additional flexibility of being able to find the path (and/or builtins) dynamically! And I can proudly point to that new flexibility as something I helped debug! =:^) Thanks! The new flexibility will be a tremendous help with the coming /usr dustup, etc. Plus even aside from that, a little extra flexibility is a good thing! |