Bug 504983 - netinst.iso: dynamic->static net config fails
Summary: netinst.iso: dynamic->static net config fails
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 14
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Radek Vykydal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-10 10:06 UTC by Jan "Yenya" Kasprzak
Modified: 2012-08-16 20:29 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 20:29:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jan "Yenya" Kasprzak 2009-06-10 10:06:55 UTC
Description of problem:
I have accidentally chosen the "Dynamic IP configuration (DHCP)" in the anaconda menu (netinst.iso image) when being on a network without a DHCP server. The NetworkManager failed to get an IP address as expected, but when I later changed the configuration to static, NetworkManager also failed to bring the interface up. When I freshly boot the netinst image and select the static IP address from the beginning, it works as expected.

Version-Release number of selected component (if applicable): Fedora-11-x86_64-netinst.iso

How reproducible:
100%

Steps to Reproduce:
1. connect the computer to the network without a DHCP server.
2. boot the Fedora-11-<yourarch>-netinst.iso
3. choose "Dynamic IP configuration (DHCP)" when configuring network, and wait for the network config failure.
4. choose "Static IP configuration", and enter the IP address, prefix length, gateway, and DNS server manually.
  
Actual results:
The same NetworkManager error message as when trying to use a (non-existent) DHCP is displayed.

Expected results:
Static configuration should work even when the dynamic IP configuration has been tried first.

Additional info:
Using static IP configuration from the beginning works.

Comment 1 Dan Williams 2009-11-11 17:51:03 UTC
Does this still happen with Fedora 12 too?

In any case, can you jump around to different VTs (I think VT5 has the NetworkManager output on it) and see if there are any interesting messages about this from NetworkManager?

Comment 2 Jan "Yenya" Kasprzak 2009-11-18 12:29:36 UTC
Still present in F12. 
NetworkManager says the following (retyping from the text console)

(reason 5)

<29>Nov 18 12:20:36 NetworkManager: <info> Marking connection 'System eth0' invalid.

<29>Nov 18 12:20:36 NetworkManager: <info> Activation (eth0) failed.

<29>Nov 18 12:20:36 NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Timeout) complete.

<29>Nov 18 12:20:36 NetworkManager: <info> (eth0): device state change: 9 -> 3 (reason 0)

<29>Nov 18 12:20:36 NetworkManager: <info> (eth0): deactivating device (reason: 0).

<29>Nov 18 12:21:09 NetworkManager:   ifcfg-rh: removed /etc/sysconfig/network-scripts/ifcfg-eth0.
<29>Nov 18 12:21:09 NetworkManager:   ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ...
<29>Nov 18 12:21:09 NetworkManager:   ifcfg-rh:     read connection 'System eth0'
<29>Nov 18 12:21:09 NetworkManager:   ifcfg-rh: updating /etc/sysconfig/network-scripts/ifcfg-eth0

Comment 3 Dan Williams 2010-08-17 16:04:48 UTC
Ok, the issue here is that NM only changes the networking configuration when something tells it to if that interface is already activated.  So if the interface gets activated with DHCP, it won't get torn down and reactivated with static IP just because the ifcfg file changes.  That will only happen if something pokes NM to re-activate the interface with the new configuration.

It's not really desirable for NM to automatically reactivate the interface when the backing ifcfg file changes because that would mean every little change you make interrupts your network connection immediately.  Instead, the mechanism NM uses is a "change + confirm" mechanism much like the existing ifup/ifdown scripts where you make a change, then you have to explicitly confirm that change  by telling NM to reactivate the interface with the new configuration.

I think what should happen here is that when the user changes configuration in the installer, anaconda should delete the ifcfg file, wait a few seconds (at least 2) and then write out the new ifcfg file with the new configuration, and then wait for NetworkManager to reconfigure the interface.  When the backing ifcfg file gets deleted, NM will tear down the interface, and when the new file gets added back, NM should reactivate the interface with the new configuration.

Comment 4 Bug Zapper 2010-11-04 11:09:24 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 WONTFIX if it remains open with a Fedora 
'version' of '12'.

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 prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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

Comment 5 Fedora End Of Life 2012-08-16 20:29:42 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. 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 '14' 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 14 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.