Following the upgrade to baselayout-2.0/openrc, /etc/conf.d/net was replaced by a skeleton rather than being migrated. dispatch-conf did not show this change and it was not mentioned in the upgrade guide.
Same problem here on ~x86
It will affect all arches. We are currently discussing this as this looks like it's a potential Portage issue.
Same problem here. I fixed it by recreating the link to net.eth0 in /etc/init.d. Unfortunately, I am left without the ability to rename my network interfaces at boot time. This happened with both ~x86 and ~amd64. Color me unimpressed. Blessed be! Pappy
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/openrc/openrc-0.2.2.ebuild?r1=1.1&r2=1.2 so far..
Should have said that its not too hard to resolve, by recreating a symlink for the interface and modifying the now blank /etc/conf.d/net configuration filebut it doesn't seem to be read during initialisation ********** Start *********** $ ln -s /etc/init.d/net.lo /etc/init.d/net.eth0 $ more /etc/conf.d/net # This blank configuration will automatically use DHCP for any net.* # scripts in /etc/init.d. To create a more complete configuration, # please review /usr/share/doc/openrc/net.example and save your configuration # in /etc/conf.d/net (this file :]!). modules=( "ifconfig" ) modules_eth0=( "dhcpcd" ) # /etc/init.d/net.eth0 restart * Bringing down interface eth0 * Stopping dhcpcd on eth0 ... [ ok ] * Bringing up interface eth0 * No configuration specified; defaulting to DHCP * dhcp ... * Running dhcpcd ... [ ok ] * received address 192.168.1.100/24 [ ok ] * Waiting for IPv6 addresses ... [ ok # ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 metric 1 inet 192.168.1.100 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::20c:76ff:fe12:9d40 prefixlen 64 scopeid 0x20<link> ether 00:0c:76:12:9d:40 txqueuelen 1000 (Ethernet) RX packets 72235 bytes 53425799 (50.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 100046 bytes 94590003 (90.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 base 0xce00 *********** End *********** Has the configuration file moved to a different location?
(In reply to comment #5) > ********** Start *********** > $ ln -s /etc/init.d/net.lo /etc/init.d/net.eth0 > $ more /etc/conf.d/net > # This blank configuration will automatically use DHCP for any net.* > # scripts in /etc/init.d. To create a more complete configuration, > # please review /usr/share/doc/openrc/net.example and save your configuration > # in /etc/conf.d/net (this file :]!). > modules=( "ifconfig" ) > modules_eth0=( "dhcpcd" ) > Please review /usr/share/doc/openrc/net.example for how to set this file up. > > Has the configuration file moved to a different location? > No.
(In reply to comment #6) > (In reply to comment #5) > > > ********** Start *********** > > $ ln -s /etc/init.d/net.lo /etc/init.d/net.eth0 > > $ more /etc/conf.d/net > > # This blank configuration will automatically use DHCP for any net.* > > # scripts in /etc/init.d. To create a more complete configuration, > > # please review /usr/share/doc/openrc/net.example and save your configuration > > # in /etc/conf.d/net (this file :]!). > > modules=( "ifconfig" ) > > modules_eth0=( "dhcpcd" ) > > > > Please review /usr/share/doc/openrc/net.example for how to set this file up. > > > > > Has the configuration file moved to a different location? > > > > No. > Thanks for the pointer Doug, didn't even occur to look in there for the net.example file. Doesn't a copy normally reside in /etc/conf.d/net.example ?
(In reply to comment #7) > > Thanks for the pointer Doug, didn't even occur to look in there for the > net.example file. Doesn't a copy normally reside in /etc/conf.d/net.example ? > I've added a note to the migration guide to check this out. /etc/conf.d/net.example was deprecated since it clutters up /etc/conf.d. The file has since moved to /usr/share/doc/openrc/net.example
simply deleting the line still makes for etc-update hell you also dont want to go adding /etc/conf.d/net to the default CONTENTS as it may contain passwords which can make it into a binpkg http://sources.gentoo.org/sys-apps/openrc/openrc-0.2.1-r2.ebuild?r1=1.5&r2=1.6 http://sources.gentoo.org/sys-apps/openrc/openrc-0.2.2.ebuild?r1=1.3&r2=1.4 http://sources.gentoo.org/sys-apps/openrc/openrc-9999.ebuild?r1=1.30&r2=1.31
This bug isn't fixed because there appears to still be a bug in Portage wrt to deleting unmerged-orphans when it should not. This was confirmed by zmedico and is being researched.
*** Bug 217879 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > This bug isn't fixed because there appears to still be a bug in Portage wrt to > deleting unmerged-orphans when it should not. This was confirmed by zmedico and > is being researched. I've traced the issue back to the remap_dns_vars() function inside baselayout-1.12.12.ebuild. It copies your configs into ${D} so then portage sees all those configs as defaults when they actually contain whatever local modifications you've made to them. So unmerged-orphans is working by design. It's just the baselayout-1.12.12 ebuild is doing things to make your real configs appear to be the default ones.
I guess this is back over to us. Too much hackery in these ebuilds..
(In reply to comment #3) > Same problem here. I fixed it by recreating the link to net.eth0 in > /etc/init.d. Different problem: /etc/init.d/net.eth0 != /etc/conf.d/net
This is a very serious problem. On my laptop, I had fairly complex configurations in /etc/conf.d/net to configure either the ethernet or wireless for different environments, set up /etc/hosts based on location, launch ssh tunnels, and such. I lost all of that and had to recreate everything from scratch. Sure, for most users, it's not a big deal, but when using preup()/postup() and such, losing the file is a nightmare. Could openrc be masked until this is fixed?
Regarding comment #15: This is indeed an annoying bug, but masking would be rather counterproductive at this point. I would suggest, though, that the OpenRC migration guide may want to mention keeping a copy of /etc/conf.d backed up for reference purposes when migrating, especially until this bug is fixed...
(In reply to comment #15) > Could openrc be masked until this is fixed? Due to the effects of the remap_dns_vars() function, all users who currently have baselayout-1.12.12 installed are in danger of losing any config files in /etc/conf.d that haven't changed since it was installed. One possible solution is to add `touch "${ROOT}"/etc/conf.d/*` the pkg_preinst() function of the baselayout-2 ebuild. This will protect those files from being unmerged with the rest of the baselayout-1.12.12 contents, effectively undoing the damage that was initially done by the remap_dns_vars() function.
Created attachment 150090 [details, diff] make the baselayout-2.0.0 ebuild protect config fiels in /etc/conf.d
(In reply to comment #18) > Created an attachment (id=150090) [edit] > make the baselayout-2.0.0 ebuild protect config fiels in /etc/conf.d That's in cvs now, so users are protected. I'm not sure if you guys want to do anything about the remap_dns_vars() in the old ebuilds or just let it go since the workaround now in the baselayout-2.0.0 ebuild makes it relatively harmless.
(In reply to comment #18) > Created an attachment (id=150090) [edit] > make the baselayout-2.0.0 ebuild protect config fiels in /etc/conf.d I think this should go to openrc not baselayout, as openrc is now owner of the files there? And last time I checked, a different workaround for /etc/conf.d/net workaround was already there.
(In reply to comment #20) > I think this should go to openrc not baselayout, as openrc is now owner of the > files there? Is has to go in the baselayout-2.0.0 ebuild it is when upgrading to that ebuild (and then unmerging baselayout-1.x) that the user's configs get lost.
*** Bug 218725 has been marked as a duplicate of this bug. ***
