Bug 633815 - Network installation fails when IPv4 DHCP fails/ IPv6 present
Summary: Network installation fails when IPv4 DHCP fails/ IPv6 present
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 14
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Radek Vykydal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-14 13:29 UTC by A.J. Werkman
Modified: 2012-06-10 09:36 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-10 09:36:35 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description A.J. Werkman 2010-09-14 13:29:28 UTC
Description of problem:
A network installation fails when IPv4 DHCP fails, although a valid IPv6 network connection is available.

Version-Release number of selected component (if applicable):
14-Beta-TC1

How reproducible:
Everytime

Test scenario:
A host on a network, that is IPv6 autoconfigured and does not get a IPv4 DHCP-lease. (This happens after 2011, when IPv4 addresses are no longer available ;-) )

Steps to Reproduce:
1. Start a URL installation. On the network UI select IPv4 DHCP and IPv6 autoconf.
2. See the installation stop on a network failure.
3. Watch tty4 and see that DHCP lease failed.
  
Actual results:
A network installation is not possible in this situation. Only when I explicitly turn off IPv4, the network installation succeeds.


Expected results:
I expect anaconda to be smart enough to detect a IPv6 network and as a result of that switch off IPv4 itself and continue installation on the IPv6 network.


Additional info:
You would probably say, that manually switching off IPv4 is a good strategie.
But
A: This is not user friendly.
B: When I kickstart in this same scenario with the kickstart file on the network, I do not get a network UI and anaconda fails the installation with "unable to download the kickstart file". I have not found a workaround to do the kickstart installation.

Comment 1 A.J. Werkman 2010-09-14 13:31:24 UTC
Anaconda is version 14.17.1

Comment 2 Radek Vykydal 2010-09-14 13:52:17 UTC
(In reply to comment #0)

To make anaconda behave the way you suggest, we would need to add IPV4_FAILURE_FATAL=no to our default ifcfg file. This change of policy should be discussed by anaconda team and others, it can have quite an impact. Perhaps it is something to consider for F15.

> B: When I kickstart in this same scenario with the kickstart file on the
> network, I do not get a network UI and anaconda fails the installation with
> "unable to download the kickstart file". I have not found a workaround to do
> the kickstart installation.

Doesn't noipv4 boot parameter meet your needs?

Comment 3 A.J. Werkman 2010-09-14 14:36:13 UTC
Hadn't thought of that.

Just did a test, but despite noipv4 anaconda fires up a DHCP client for IPv4.

Comment 4 Radek Vykydal 2010-09-14 14:40:13 UTC
(In reply to comment #3)
> Hadn't thought of that.
> 
> Just did a test, but despite noipv4 anaconda fires up a DHCP client for IPv4.

Thanks for doing the test, I'll look at it.

Comment 5 A.J. Werkman 2010-10-13 17:31:25 UTC
Anaconda 14.19:

The noipv4 boot option is still not accepted by anaconda.

With noipv4 anaconda still starts a DHCP and on failing to find IPv4 addresses fails to continue configuring the network interface.

Comment 6 Radek Vykydal 2011-01-17 15:28:02 UTC
(In reply to comment #5)
> Anaconda 14.19:
> 
> The noipv4 boot option is still not accepted by anaconda.
> 
> With noipv4 anaconda still starts a DHCP and on failing to find IPv4 addresses
> fails to continue configuring the network interface.

This should happen only in case when ipv6= boot option with static configuration is used. This option is not working (not supported in code actually) so anaconda doesn't pass the ipv6 configuration to NM which, as a consequence of getting neither ipv4 nor ipv6 configuration, tries ipv4 dhcp. I want to add ipv6=<static_ip> support in F15.

Does it accord with what you hit wrt noip4 option?

Comment 7 A.J. Werkman 2011-01-20 10:00:32 UTC
My testcase was not with ipv6=<static>

Testcase was: I am a user who has further knowledge of network topology as that networking is up and running. I start an installation over the network.

I start the installation and anaconda fails with a network error. I am supprised because I see that a Windows system on this network does make network contact. My conclusion: Fedora sucks.

Translated to a technology aware setting:
The user has no knowledge about this, but this is a network without IPv4 DHCP present, only IPv6 address space available.

In a basic installation setting as to say without the user specifying anything particular, anaconda can of course start a IPv4 DHCP, no problem. But it can and should be smart enough to conclude that IPv4 is not present when it sees that IPv4 DHCP fails. And as a result of this it should shutdown IPv4, but not stop the installation proces.  Because the user has not blocked IPv6 (user actually did not specify anything network related) it should try to obtain IPv6 addresses (as the user wants to do an installation over the network).

On finding IPv6 addressing anconda can continue the installation proces.

In this whole setting you can substitute the "not-knowing" user with a kickstart installation process. As in the basic kickstart setup anaconda has to findout networking by itself if the user only gave a url pointing to a kickstart-file.

Comment 8 Radek Vykydal 2011-01-20 15:02:54 UTC
(In reply to comment #7)
> My testcase was not with ipv6=<static>

My question in comment #6 was regarding specifically a side-issue of noipv4 option not working, I understand the original request of your bug, thanks for detailing on it nevertheless.

Comment 9 James Laska 2011-03-03 14:05:10 UTC
Is this an issue we need to target and resolve for Fedora 15?

Comment 10 Radek Vykydal 2011-03-03 14:43:13 UTC
(In reply to comment #9)
> Is this an issue we need to target and resolve for Fedora 15?

The issue here is that by default (IPV4_FAILURE_FATAL=yes) when enabling network ipv4 failure + ipv6 success is considered as failure overall. To success, ipv4 has to be explicitly disabled (with boot option, or in UI, or in ks). I don't think this should be changed in f15, but I stay open to discuss it or let myself persuaded in future.

Comment 11 Radek Vykydal 2011-03-03 14:48:43 UTC
(In reply to comment #7)

> 
> In a basic installation setting as to say without the user specifying anything
> particular, anaconda can of course start a IPv4 DHCP, no problem. But it can
> and should be smart enough to conclude that IPv4 is not present when it sees
> that IPv4 DHCP fails. And as a result of this it should shutdown IPv4, but not
> stop the installation proces.  Because the user has not blocked IPv6 (user
> actually did not specify anything network related) it should try to obtain IPv6
> addresses (as the user wants to do an installation over the network).
> 
> On finding IPv6 addressing anconda can continue the installation proces.
> 

What if user expected ipv4 to be configured but had misconfigured his dhcp server or there is some other issue? It seems that by "smart enough" you mean to do use your default scenario, but I think that anaconda should to ask in such a situation, and for your case you should tell anaconda to ignore ipv4.

Comment 12 Radek Vykydal 2011-03-03 14:50:41 UTC
(In reply to comment #11)
> (In reply to comment #7)

> to do use your default scenario, but I think that anaconda should to ask in
err, sorry for the typos, I mean:
"to use your default scenario, but I think that anaconda should ask in"

Comment 13 A.J. Werkman 2011-03-03 15:07:20 UTC
Is it a problem if someone expects to configure IPv4 and unnoticedly it is not? In the end there IS network connectivity.

If IPv6 succeeds network connectivity is established and the system can be installed and used. Later reconfiguration of DHCP-server or the setup can correct this situation easily.

But in the now present situation it could mean that a fatal installation can leave a (not so technical) user with a Fedora "that can not be installed". No good advertisment for Fedora!!

I think the second option is less desirable and more serious then the first.

Comment 14 Radek Vykydal 2011-03-03 17:46:02 UTC
(In reply to comment #13)
> Is it a problem if someone expects to configure IPv4 and unnoticedly it is not?
> In the end there IS network connectivity.
> 

What if she expects to connect (i.e. to download packages) over IPv4?
(As majority still does I think).

> If IPv6 succeeds network connectivity is established and the system can be
> installed and used. Later reconfiguration of DHCP-server or the setup can
> correct this situation easily.
 
Default IPv6 configuration, which is stateless auto-configuration, succeeds practically always - even if with only generating of link local address.

Please note that successful activation of a device doesn't mean having connectivity to desired target (e.g. routing, nameservers can be misconfigured or not configured at all as it is often with the default ipv6 stateless auto-configuration) 

> But in the now present situation it could mean that a fatal installation can
> leave a (not so technical) user with a Fedora "that can not be installed". No
> good advertisment for Fedora!!
> 

Why the installation should be fatal? Just retry and disable ipv4 in UI.

Comment 15 A.J. Werkman 2011-03-03 20:22:21 UTC
>What if she expects to connect (i.e. to download packages) over IPv4?
>(As majority still does I think).

IPv4 is the majority, but will not stay the majority as IPv4 address space has run out.
If the network is configured for IPv6 or even more is IPv6 only, the installation will proceed happily over IPv6.

> Default IPv6 configuration, which is stateless auto-configuration, succeeds
> practically always - even if with only generating of link local address.
>
> Please note that successful activation of a device doesn't mean having
> connectivity to desired target (e.g. routing, nameservers can be misconfigured
> or not configured at all as it is often with the default ipv6 stateless
> auto-configuration)

Here you may have a point. But shouldn't that problem be solved on the IPv6 side and not at the Anaconda side? I mean IPv6 is developped to replace IPv4, so this problem should be addressed now or in the future and applications should not avoid facing these problems, so they are addressed.

> Why the installation should be fatal? Just retry and disable ipv4 in UI.

That is no problem when you have technical knowledge, but I reffered to people that do not have that knowledge and/or do not know there network topology.

Comment 16 Radek Vykydal 2011-03-04 15:43:07 UTC
(In reply to comment #15)
> >What if she expects to connect (i.e. to download packages) over IPv4?
> >(As majority still does I think).
> 
> IPv4 is the majority, but will not stay the majority as IPv4 address space has
> run out.

Well, this is not the reason to ignore or disadvantage them, or to promote ipv6 over ipv4 aggressively right now. Especially when IPv4 dhcp is still anaconda's default. I'd still prefer offering an option to pushing with default.

> If the network is configured for IPv6 or even more is IPv6 only, the
> installation will proceed happily over IPv6.

Not necessarily - what if a target (e.g. a repository, a kickstart file URL) is not accessible via IPv6 (on the target side)? It can even be specified with IPv4 address. 

Also there still remains the problem how anaconda learns that the local network is configured for IPv6 in the way it would access all the targets - network can be used for various goals in anaconda, not only to get packages from mirrors, but also to get packages from additional or local repositories, to get kickstart, for vnc, or for storage over network, and any of them can depend exclusively on IPv4 or IPv6 connection.

Anaconda would need to try if all the targets are accessible before deciding whether the dhcp ipv4 fail can be ignored. In some cases anaconda even can't tell at that time - for example user can add targets of storage backed with network (iSCSI) - counting on ipv4 configuration he expects to be up - in stage 2 (Advanced Storage Setup).

Comment 17 James Laska 2011-03-04 15:57:42 UTC
My poor attempt to summarize the discussion ... so the debate here is determining what constitutes a valid active network for the installer? 

If IPv4 is enabled ...
 * you must have a valid IP address from DHCP or manually configured?

If IPv4 is disabled ...
 * a valid IPv6 address must be obtained from a DHCPv6 server, or manually configured.  Auto-generated IPv6 information is not sufficient.

Is that the current state of network enablement in loader+anaconda?

Comment 18 James Laska 2011-03-04 15:59:42 UTC
note, my comment#17 leaves out whether or not the configured network is correct.  DHCP could be improperly configured, and a static-ip configuration could be inaccurate.  All this would lead to network issues later in the installer I suspect ... but this seems out of scope for this bug, right?  That portion seems more related to recovering from incorrectly configured network.

Comment 19 Radek Vykydal 2011-03-04 16:24:12 UTC
(In reply to comment #17)
> My poor attempt to summarize the discussion ... so the debate here is
> determining what constitutes a valid active network for the installer? 
> 

Yes, in other words - in which case network enablement succeeded.

Successfully enabled device is that for which NM reports state NM_VPN_CONNECTION_STATE_ACTIVATED.

> If IPv4 is enabled ...
>  * you must have a valid IP address from DHCP or manually configured?
> 

For static configuration, it basically means that NM has got valid ip addresses. For dhcp it means it has got any configuration from DHCP. 

> If IPv4 is disabled ...
>  * a valid IPv6 address must be obtained from a DHCPv6 server, or manually
> configured.  Auto-generated IPv6 information is not sufficient.

Auto-generated IPv6 is sufficient, it is default option for IPv6 enabled.

Comment 20 A.J. Werkman 2012-06-10 09:36:35 UTC
I can not reproduce in F17 anymore, so I close this bug.


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