Bug 705718

+++ This bug was initially created as a clone of Bug #692196 +++

Description of problem:
While installing F15 static IPv6 address can not be configured.

Version-Release number of selected component (if applicable):
Anaconda 15.25 F15 Beta TC1

How reproducible:
Everytime

Steps to Reproduce:
1. Start a fresh installation of F15
2. Proceed to the Hostname UI screen
3. Click "Configure Network"
4. Select the correct ethernet interface and click edit
5. Select IPv4 settings tab and select Method "Disabled"
6. Select IPv6 settings and select method "Manual"
7. Click add and on the address field typ in the IPv6 address
8. Nect click on the prefix field.
  
Actual results:
After entering the IPv6 address see the address being shown in the address field. After clicking on the prefix field in order to enter the prefix watch the address field being blanked again. Same behaviour goes for the prefix field. As soon as the focus leaves the prefix field it is blanked again.


Expected results:
IPv6 addresssing scheme is accepted and configured in the interface.

Additional info:

--- Additional comment from dcbw on 2011-04-05 09:51:11 EDT ---

As a workaround, if you hit return after entering the IPv6 address does it then get accepted?  Also, what address are you entering?

--- Additional comment from aj.werkman on 2011-04-05 10:35:46 EDT ---

Yes, when I hit return after entering the address, the value is accepted.

I Use "2001:838:3ab:1::12/64" BTW.

But I see an odd behaviour. I enter the address in the hostname UI screen. When I swicth to VTTY2 and type "ifconfig" the address is not in the interface. When anaconda comes to the point where it want to get the repo info from the network I am again asked to configure the network device. When I look into this screen the IPv6 address is already entered in the correct field, but where I set IPv4 in the first screen to ignore, it is now back on "DHCP" again.

After switching off IPv4 again however the packages are collected from the network as expected.

The workaround I used is to enter the IPv6 address on the kernel commandline. I only found out, that I have to enter the address without prefix, where the kickstart file and anaconda UI want the prefix when entering an IPv6 address. I don't think this is consistent. Why does the ipv6 boot option not accept the ipv6 address in prefix notation.

--- Additional comment from jklimes on 2011-04-07 08:05:23 EDT ---

(In reply to comment #2)
> Yes, when I hit return after entering the address, the value is accepted.
> 
> I Use "2001:838:3ab:1::12/64" BTW.
> 
Hmm, that's probably due to new toolkit.
On Fedora 14, the address is accepted when one clicks on Prefix.
On Fedora 15, it is *not* and one has to press Enter.
In any case, the UI should be corrected to be more user-friendly - respect 'Tab' key, maybe arrows, etc. There are some bugs hanging around about this issue.

> But I see an odd behaviour. I enter the address in the hostname UI screen. When
> I swicth to VTTY2 and type "ifconfig" the address is not in the interface.
The connection is probably not activated yet.

> When anaconda comes to the point where it want to get the repo info from the network
> I am again asked to configure the network device. When I look into this screen
> the IPv6 address is already entered in the correct field, but where I set IPv4
> in the first screen to ignore, it is now back on "DHCP" again.
> 

This looks like a bug in anaconda to me, because anaconda writes BOOTPROTO=dhcp to ifcfg-eth0 for some reason, which enables IPv4 again.

excerpt from ifcfg.log:
10:39:35,664 DEBUG ifcfg: writeIfcfgFile eth0 to /etc/sysconfig/network-scripts/ifcfg-eth0 not needed
06:42:03,541 DEBUG ifcfg: NetworkDevice eth0 set: NM_CONTROLLED=yes
06:42:03,543 DEBUG ifcfg: NetworkDevice eth0 set: BOOTPROTO=dhcp
06:42:03,592 DEBUG ifcfg: /etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE="eth0"
ONBOOT="no"
NM_CONTROLLED="yes"
TYPE=Ethernet
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=yes
NAME="System eth0"
UUID=5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
IPV6_AUTOCONF=no
IPV6_DEFAULTGW=::
IPV6ADDR=1:2:3::4/24
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=yes
HWADDR=52:54:00:12:34:56

06:42:03,592 DEBUG ifcfg: NetworkDevice eth0:
PEERROUTES="yes"
IPV6_DEFAULTGW="::"
IPV6INIT="yes"
HWADDR="52:54:00:12:34:56"
UUID="5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03"
DEFROUTE="yes"
PEERDNS="yes"
IPV4_FAILURE_FATAL="yes"
IPV6_AUTOCONF="no"
NM_CONTROLLED="yes"
IPV6_DEFROUTE="yes"
DEVICE="eth0"
IPV6_FAILURE_FATAL="yes"
IPV6ADDR="1:2:3::4/24"
TYPE="Ethernet"
ONBOOT="no"
BOOTPROTO="dhcp"
NAME="System eth0"

06:42:03,592 DEBUG ifcfg: writeIfcfgFile eth0 to /etc/sysconfig/network-scripts/ifcfg-eth0
06:42:03,603 DEBUG ifcfg: Dump before nm-c-e (can race with ifcfg updating). /etc/sysconfig/network-scripts/ifcfg-eth0:
PEERROUTES="yes"
IPV6_DEFAULTGW="::"
IPV6INIT="yes"
HWADDR="52:54:00:12:34:56"
UUID="5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03"
DEFROUTE="yes"
PEERDNS="yes"
IPV4_FAILURE_FATAL="yes"
IPV6_AUTOCONF="no"
NM_CONTROLLED="yes"
IPV6_DEFROUTE="yes"
DEVICE="eth0"
IPV6_FAILURE_FATAL="yes"
IPV6ADDR="1:2:3::4/24"
TYPE="Ethernet"
ONBOOT="no"
BOOTPROTO="dhcp"
NAME="System eth0"

--- Additional comment from rvykydal on 2011-04-07 10:00:29 EDT ---

(In reply to comment #3)
> (In reply to comment #2)

> 
> > But I see an odd behaviour. I enter the address in the hostname UI screen. When
> > I swicth to VTTY2 and type "ifconfig" the address is not in the interface.
> The connection is probably not activated yet.
> 

Yes, here the network is only configured, not enabled (please see http://fedoraproject.org/wiki/Anaconda/Network#Network_enablement_and_network_configuration for details). To enable it at this point, you'd need to check "Connect Automatically".

> > When anaconda comes to the point where it want to get the repo info from the network
> > I am again asked to configure the network device.

You are asked to _enable_ the network (for the first time), on hostname screen you just configured it (I see and understand that network configuration vs network enablement might be confusing).

> > When I look into this screen
> > the IPv6 address is already entered in the correct field, but where I set IPv4
> > in the first screen to ignore, it is now back on "DHCP" again.
> > 
> 
> This looks like a bug in anaconda to me, because anaconda writes BOOTPROTO=dhcp
> to ifcfg-eth0 for some reason, which enables IPv4 again.
> 

The reason is that we need some default configuration of IPv4/BOOTPROTO value of device that should be enabled (which means also activated after install) for minimal installs without NetworkManager.

The default BOOTPROTO=dhcp is written by anaconda right before enablement of network (running the Connection Editor). The problem in this specific case is that we don't know that the value for ipv4 configuration had already been set in previous run of Connection Editor (on the hostname screen). We can't read and respect BOOTPROTO in this case because it is just missing for "Ignore" if I am not mistaken. 

Would it be possible for ifcfg-rh to write BOOOTPROTO=none in this case? Also, is it ok for anaconda write-out this value for ipv4 disabled? Or maybe we could check some other ifcfg setting to determine whether the device had already been configured (presence of UUID? NAME?) but it is a bit hacky. 

This issue deserves separate bug, I'll probably clone one for anaconda or create new one.

--- Additional comment from jklimes on 2011-04-14 13:20:30 EDT ---

> The reason is that we need some default configuration of IPv4/BOOTPROTO value
> of device that should be enabled (which means also activated after install) for
> minimal installs without NetworkManager.
> 
> The default BOOTPROTO=dhcp is written by anaconda right before enablement of
> network (running the Connection Editor). The problem in this specific case is
> that we don't know that the value for ipv4 configuration had already been set
> in previous run of Connection Editor (on the hostname screen). We can't read
> and respect BOOTPROTO in this case because it is just missing for "Ignore" if I
> am not mistaken. 
> 
> Would it be possible for ifcfg-rh to write BOOOTPROTO=none in this case? Also,
> is it ok for anaconda write-out this value for ipv4 disabled?

BOOOTPROTO=none can't be used because that would imply that IPv4 is enabled.
ifcfg-rh plugin regards IPv4 as disabled only in case that:
  - no BOOTPROTO, no IPADDR, no PREFIX, no NETMASK are present
  - and there is an IPv6 configuration
See http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifcfg-rh/reader.c#n1199

> Or maybe we could
> check some other ifcfg setting to determine whether the device had already been
> configured (presence of UUID? NAME?) but it is a bit hacky. 

Maybe, you don't have to write anything, because if the device is configured, all is ok. And in case it has not been configured the minimal configuration (which you probably have already?):
 DEVICE=eth0
 HWADDR=11:22:33:44:55:66
is regarded as DHCP (at least by NetworkManager)

--- Additional comment from rvykydal on 2011-04-15 04:02:59 EDT ---

(In reply to comment #5)
 
> BOOOTPROTO=none can't be used because that would imply that IPv4 is enabled.
> ifcfg-rh plugin regards IPv4 as disabled only in case that:
>   - no BOOTPROTO, no IPADDR, no PREFIX, no NETMASK are present
>   - and there is an IPv6 configuration
> See
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifcfg-rh/reader.c#n1199
> 

Thanks, that is what I was thinking.

> > Or maybe we could
> > check some other ifcfg setting to determine whether the device had already been
> > configured (presence of UUID? NAME?) but it is a bit hacky. 
> 
> Maybe, you don't have to write anything, because if the device is configured,
> all is ok. And in case it has not been configured the minimal configuration
> (which you probably have already?):
>  DEVICE=eth0
>  HWADDR=11:22:33:44:55:66
> is regarded as DHCP (at least by NetworkManager)

Yes, with NM it is ok, but I was talking about the case of minimal install without NetworkManager, e.g. ifup didn't regard missing BOOTPROTO as DHCP. I am not sure if we should take commitment of supporting default configuration in this case. I'll have to recheck how network service handles such a configuration.