With this config in /etc/conf.d/net: config_eth1="2001:470:f211:6::c07/64 2001:470:f211:6::ca07/64 preferred 0 2001:470:f211:6::cb07/64 preferred 0 2001:470:f211:6::cc07/64 preferred 0 2001:470:f211:6::a:d03/64 preferred 0" In openrc-0.8.3-r1, /etc/init.d/net.eth1 start will bring the interface up, and properly add all addresses, with the preferred 0 attribute applied to the address as configured. In openrc-0.9.4 and openrc-0.9.8, the /etc/init.d/net.eth1 script will bring up the first address, but will cause runscript.sh to spin and consume 100% CPU while trying to bring up the second address. It will hang until interrupted with ^C. Reproducible: Always Steps to Reproduce: 1. Configure /etc/conf.d/net with "preferred 0" after IPv6 addresses as noted in the example of the bug description 2. Start the relevant interface such as through: /etc/init.d/net.eth1 start 3. Watch the init script hang and never return Actual Results: network init script does not complete setting up the configured addresses and instead hangs Expected Results: network init script adds all addresses with appropriate attributes, and returns control to the shell I'm not even sure if this is the correct way to deprecate an IPv6 address in openrc, or if there is another preferred way. Since this worked correctly in the past, I'd consider it a regression. I'm currently back on 0.8.3-r1 rather than trying to hack around it.
Just to clarify 0.8.3-r1: WORKS 0.9.4: BROKEN 0.9.8: BROKEN
workaround for now, spell out the option fully instead of compressing it. so preferred_lft instead of preferred.
fixed in commit e7649f1
Thanks for looking into it, but it's not quite fixed. Both the patched and unpatched versions (including your workaround) do not take into account that the string preferred_lft itself must be on the command line before its argument. With /etc/conf.d/net as: config_eth1="2001:470:f211:6::c07/64 2001:470:f211:6::ca07/64 preferred_lft 0 2001:470:f211:6::cb07/64 preferred_lft 0 2001:470:f211:6::cc07/64 preferred_lft 0 2001:470:f211:6::a:d03/64 preferred_lft 0" The output of /etc/init.d/net.eth1 start is thus: * Bringing up interface eth1 * 2001:470:f211:6::c07/64 ... [ ok ] * 2001:470:f211:6::ca07/64 ... Error: either "local" is duplicate, or "0" is a garbage. [ !! ] * 2001:470:f211:6::cb07/64 ... Error: either "local" is duplicate, or "0" is a garbage. [ !! ] * 2001:470:f211:6::cc07/64 ... Error: either "local" is duplicate, or "0" is a garbage. [ !! ] * 2001:470:f211:6::a:d03/64 ... Error: either "local" is duplicate, or "0" is a garbage. [ !! ] For all of the arguments anycast|label|scope|valid_lft|preferred_lft|a*|l*|s*|v*|pr*, it assigns the parameter to the appropriate variable. However, it assigns only the argument, but not the option name. I believe in your patched version, The line: eval "$x=$1" ; shift ;; Should read something like eval "$x=\"$x $1\"" ; shift ;;
As requested on IRC, "<robbat2> can you add the output of /etc/init.d/net.eth1 --verbose start" * Bringing up interface eth1 * Loaded modules: apipa arping bonding tuntap ccwgroup macchanger macnet wpa_supplicant ssidnet iproute2 system vlan dhcpcd ip6to4 * Configuring eth1 for MAC address 00:30:48:65:85:4D ... [ ok ] * 2001:470:f211:6::c07/64 ... * ip addr add 2001:470:f211:6::c07/64 dev eth1 [ ok ] * 2001:470:f211:6::ca07/64 ... * ip addr add 2001:470:f211:6::ca07/64 dev eth1 0 Error: either "local" is duplicate, or "0" is a garbage. [ !! ] * 2001:470:f211:6::cb07/64 ... * ip addr add 2001:470:f211:6::cb07/64 dev eth1 0 Error: either "local" is duplicate, or "0" is a garbage. [ !! ] * 2001:470:f211:6::cc07/64 ... * ip addr add 2001:470:f211:6::cc07/64 dev eth1 0 Error: either "local" is duplicate, or "0" is a garbage. [ !! ] * 2001:470:f211:6::a:d03/64 ... * ip addr add 2001:470:f211:6::a:d03/64 dev eth1 0 Error: either "local" is duplicate, or "0" is a garbage. [ !! ] * Adding routes * default via 2001:470:f211:6::1 ... [ ok ]
Troy's problem was a false negative. He had applied my patch from the commit on top of 0.9.4, and while it applied cleanly, it was dependant on other post-0.9.4 changes, so it didn't work for him.
