Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=150090) [details]
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] [details]
> 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] [details]
> 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. ***