Bug 705718 - Setting of default BOOTPROTO for minimal installation can override user's choice in [Configure Network]
Setting of default BOOTPROTO for minimal installation can override user's cho...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
15
i386 Linux
unspecified Severity high
: ---
: ---
Assigned To: Radek Vykydal
Fedora Extras Quality Assurance
:
Depends On: 692196
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-18 04:55 EDT by Radek Vykydal
Modified: 2012-08-07 16:22 EDT (History)
7 users (show)

See Also:
Fixed In Version: anaconda-16.21-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 692196
Environment:
Last Closed: 2012-08-07 16:22:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Radek Vykydal 2011-05-18 04:55:50 EDT
+++ 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@redhat.com 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@digifarma.nl 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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.
Comment 1 Radek Vykydal 2011-05-18 05:03:48 EDT
Comment #2 and comment #4 (the last paragraph) from the original bug are relevant for this clone. Quite a corner case. There is already an anaconda BZ that tried to deal with setting of default BOOTPROTO for minimal installation - I have to find it.
Comment 2 Radek Vykydal 2011-05-20 11:15:57 EDT
(In reply to comment #1)
> Comment #2 and comment #4 (the last paragraph) from the original bug are
> relevant for this clone. Quite a corner case. There is already an anaconda BZ
> that tried to deal with setting of default BOOTPROTO for minimal installation -
> I have to find it.

bug #636526
Comment 3 Radek Vykydal 2011-10-06 07:37:04 EDT
This should be fixed in scope of bug #741199 (in F16 post beta).
Comment 4 Fedora End Of Life 2012-08-07 16:22:25 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Note You need to log in before you can comment on or make changes to this bug.