I've stumbled across difficulties when upgrading to the new shiny openrc system... it seems that network card aliases are not configured properly. For purpose of this bug report Ive used dummy interface. /etc/conf.d/net reads: config_dummy0="192.168.0.1/24 192.168.0.2/24" (as per example) /etc/init.d/net.dummy0 restart yields: * Caching service dependencies ... Service `crypto-loop' needs non existant service `checkroot' [ ok ] * Bringing down interface dummy0 * Removing addresses * Bringing up interface dummy0 * 192.168.0.1/24 ... [ ok ] * 192.168.0.2/24 ... [ ok ] so everything seems to be fine but it isnt. ifconfig shows: dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP> mtu 1500 metric 1 inet 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255 ether 1a:38:69:ff:0b:c8 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1 bytes 98 (98.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 So it seems that some sort of alias has been configured but not the 'real' IP. Am I doing something wrong or is it a bug that needs fixing? I guess emerge info is not relevant in this situation... Cheers
This is most likely due to the old nature of ifconfig and using iproute2 to configure your network. Check ip addr and that should report both addresses. This is a dup of another bug but I can't remember it off the top of my head or find it this instant. Kicking it to bug-wranglers cause they might remember. btw.. you probably want to re-emerge util-linux to get rid of the depend issue.
unfortunately cant agree on that. communication with 192.168.0.2 works ok whereas it does not with 192.168.0.1 so I dont think it is just down to ifconfig reporting things. On top of that - I have manually configured eth0 alias that I had and it is reported correctly: eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 metric 1 inet xx.xx.139.51 netmask 255.255.255.240 broadcast xx.xx.139.63 ether 00:04:76:71:ac:1d txqueuelen 1000 (Ethernet) RX packets 128145 bytes 64968970 (61.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 149873 bytes 109654748 (104.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 11 base 0x6000 eth0:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 metric 1 inet xx.xx.139.52 netmask 255.255.255.240 broadcast xx.xx.139.63 ether 00:04:76:71:ac:1d txqueuelen 1000 (Ethernet) device interrupt 11 base 0x6000 btw thanks for the hint with util-linux. it affects all the gentoo systems that I have :)
(In reply to comment #1) > Kicking it to bug-wranglers cause they might remember. Er, jakub is MIA.
barthek: do you get the same behavior with modules="ifconfig" ?
yep, the results are the same (only the latest 'alias' is processed) dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP> mtu 1500 metric 1 inet 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255 ether 1a:38:69:ff:0b:c8 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2 bytes 196 (196.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 i think i found another bug as well. according to /usr/share/doc/openrc/net.example i could use something like this: # Or you can use sequence expressions #config_eth0="192.168.0.{2..4}/24" when i applied this config: config_dummy0="192.168.0.{1..2}/24" to my dummy interface i got this error instead: * 192.168.0.{1..2}/24 ... 192.168.0.{1..2}: Unknown server error ifconfig: `--help' gives usage information. [ !! ] * ERROR: net.dummy0 failed to start so it seems something is seriously not right with the script...
Seems there is some sort of openrc bug here.
This is an openrc bug or rather openrc incompatibility with sys-apps/net-tools-1.60_p20071202044231. This is because ifconfigs output has changed from net-tools-1.60-r13. So if you downgrade to net-tools-1.60-r13 you will be ok until an openrc update comes along.
if thats the case then why the heck this versions are still in the portage tree as current ones... and why havent they been given proper testing before release. :\
(In reply to comment #8) > if thats the case then why the heck this versions are still in the portage tree > as current ones... and why havent they been given proper testing before > release. :\ > You are aware that openrc is beta software, which is why it's ~arch, right?
barthek: like Jon said, if you want stable software, use stable. complaining that ~arch isnt stable is ridiculous. *** This bug has been marked as a duplicate of bug 217775 ***
I understand that I can not expect stability from ~arch but shouldnt obvious bugs like this one prevent package from being put in portage/unmasked in first place ?
you're making invalid assumptions. at the time of addition, openrc worked fine. some other package updated that broke openrc. along those lines, it isnt feasible to test every package that may explicitly or implicitly depend on another package when updating it in the tree. that is the purpose of ~arch.
thank you for thorough explanation. i'm glad i could help. g'nite :)
I'm still getting a similar output. My /etc/conf.d/net file is simple enough: config_eth0="dhcpcd" I'm loading net.eth0 at the command line and it looks like * Caching service dependencies ... Service `crypto-loop' needs non existant service `checkroot' [ ok ] * Bringing up interface eth0 * dhcpcd ... * Running dhcpcd ... eth0: dhcpcd 4.0.2 starting Then with some other information about the IP address I am assigned and so on. The internet is working fine afterwards. However, I should note that since this bug was filed some time ago, both net-tools AND openRC have been upgraded, but the problem remains! I'm using net-tools-1.60_p20071202044231-r1 & openrc-0.3.0-r1 As a side note, so I can at least claim my post is useful at all, "existant" is French, and "existent" is English. So as long as the rest of the output is in English, I suppose we should fix the spelling, oui? ~daid
