Bug 1018471

Summary: DHCP-less manual network configuration not efectuated
Product: [Fedora] Fedora Reporter: A.J. Werkman <aj.werkman>
Component: anacondaAssignee: Radek Vykydal <rvykydal>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: amulhern, atorkhov, awilliam, dshea, g.kaviyarasu, hamzy, jonathan, mkolman, rvykydal, sbueno, vanmeeuwen+fedora
Target Milestone: ---Keywords: CommonBugs
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: https://fedoraproject.org/wiki/Common_F20_bugs#anaconda-nmce-network
Fixed In Version: anaconda-22.17 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-30 01:24:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Anaconda.log
none
ifcfg.log none

Description A.J. Werkman 2013-10-12 10:52:32 UTC
Description of problem:
Network does not come up when no DHCP-address is supplied and network addressses are configure manual.

Version-Release number of selected component (if applicable):
20-Beta-TC2

How reproducible:
Every time

Steps to Reproduce:
1. Start Fedora installation on a network without DHCP.
2. On the commandline give http repo source. Do not give NIC parameters.
3. When network configuration windows is presented, configure NIC with manual adresses for IPv4 and IPv6.
4. After advancing to the central pane Look at the Network configuration button

Actual results:
Status of the network shown at the Network configuration button remains 'Connecting...'. Installation source button gives 'Error setting up software source'

Expected results:
NIC-status changes to connected. Repo data is read and installation can continue.


Additional info:
When NIC status remains 'connecting', going into the Network configuration window, I have to manually switch the NIC off and on again with the on/off button to make the NIC change to 'connected'.
Switching to Software installation source afterwards, shows that the repo URL I have supplied on the commandline is not copied there.

Comment 1 A.J. Werkman 2013-10-12 11:00:10 UTC
Created attachment 811554 [details]
Anaconda.log

Comment 2 A.J. Werkman 2013-10-12 11:00:43 UTC
Created attachment 811555 [details]
ifcfg.log

Comment 3 Radek Vykydal 2013-10-17 08:32:03 UTC
Yes, when configuration is changed in Connection Editor (nm-c-e) invoked by  Configure button, the device has to be switched off and on to apply the configuration in installer. Ideally we'd need also [Apply] button additionally to [Save] which is pressent in the nm-c-e. In desktop of installed system Gnome (control-center) stopped to use Connection Editor and now has its own UI with Apply button since about F19. This seems to be the right thing to do in desktop, but in installer the case of just configuring the network for target system ([Save]) without actually applying it in installer might be a valid one.

Using Connection Editor (a separate process) in installer is good in re-using the UI code but this bug is an example of its limits because we have to use nm-c-e as a separate process. Thinking of possible solutions:

- [Apply] button doesn't seem to quite fit into Connection Editor, it is just a tool for editing persistent configuration.

- Auto-applying new configuration in anaconda is 1) not what user might want in all cases 2) quite difficult to do given nm-c-e has to be run a separate process, ie it would be rather tricky to learn if the configuration was actually changed (vs leaving nm-c-e with [Cancel]). It is doable though.

To address 1) perhaps we could expose another button in the network configruation screen: either [Configrue and Apply] that would apply the configuration after leaving nm-c-e automatically, or [Apply configuration]. The latter could be sensitive only in case we detect that the configuation has actually been changed (2) above)

- What we certainly can do to improve the usability a bit is to add a tooltip to [Configure] button saying that to apply the new configuration the device has to be switched off and on.

Comment 4 Radek Vykydal 2013-11-25 07:53:55 UTC
(In reply to Radek Vykydal from comment #3)
> Yes, when configuration is changed in Connection Editor (nm-c-e) invoked by 
> Configure button, the device has to be switched off and on to apply the
> configuration in installer. Ideally we'd need also [Apply] button
> additionally to [Save] which is pressent in the nm-c-e. In desktop of
> installed system Gnome (control-center) stopped to use Connection Editor and
> now has its own UI with Apply button since about F19. 

Moreover, the Apply button in current F20 behaves in the same way - to apply the configuration to the system the device has to be switched off and on (not sure if it is a bug or desired behaviour).

(In reply to Radek Vykydal from comment #3)
 
> To address 1) perhaps we could expose another button in the network
> configruation screen: either [Configrue and Apply] that would apply the
> configuration after leaving nm-c-e automatically, or [Apply configuration].
> The latter could be sensitive only in case we detect that the configuation
> has actually been changed (2) above)

Or we could add a checkbox (by default on) next to the configure button:

[x] Apply the configuration immediately         [Configure]

Comment 5 Alexey Torkhov 2013-12-09 23:10:58 UTC
Confirming the bug. Bridging it to attention.

Comment 6 Adam Williamson 2013-12-10 00:06:50 UTC
this seems more like f21 stuff at this point...

Comment 7 Radek Vykydal 2013-12-10 08:05:15 UTC
... I agree.

Comment 8 Alexey Torkhov 2013-12-10 09:19:13 UTC
Should be documented in CommonBugs at least, I think.

Comment 9 Radek Vykydal 2014-05-26 15:02:45 UTC
*** Bug 983238 has been marked as a duplicate of this bug. ***

Comment 10 Radek Vykydal 2015-01-30 14:17:24 UTC
The connection will be reactivated automatically after changing its configuration in GUI.

Comment 11 Radek Vykydal 2015-01-30 14:18:06 UTC
commit 40f75a20b1bca7ae66416a113629f05c750e7047

Comment 12 Fedora End Of Life 2015-05-29 09:33:47 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

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

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is 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  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.

Comment 13 Fedora End Of Life 2015-06-30 01:24:03 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.