Red Hat Bugzilla – Bug 635239
Install gets stuck in repo config stage if you specify an non-functional network configuration
Last modified: 2012-08-16 16:29:53 EDT
With the switch to using networkmanager-connection-editor for network configuration in Anaconda 14, there's a problem when you specify a non-functional network config. I tested an install from netinst.iso, and specified a non-functional network configuration (I specified a static IP address which wasn't on the right subnet) when I hit the network config stage. nm-c-e accepted it and anaconda let me carry on to the repo configuration stage; then it tried to connect to the repositories, and failed. It offered to let me re-configure the repository, or retry, but it didn't allow me to go back or edit the network configuration; there was no way I could possibly fix the network config and continue the install. The only option was to reboot.
Since there's an obvious workaround to this (reboot and specify a valid network config) I'm proposing this for nice-to-have rather than blocker, but if anyone feels it should be a blocker, please promote.
Adding possibility to fix bad network config can be tricky and I don't see it doable for F14, especially in the repo fail case.
Once the network had been enabled with bad parameters, just editing in nm-c-e can't fix it as network must be restarted so the changes take effect (this is by NM design). Doing the network restart in anaconda would require some investigation - not sure how difficult and safe it would be. From the UI point of view - in desktop it can be done using NM applet, but what UI to choose in step-based anaconda UI?
For example for fixing installer network configuration with [Configure Network] button, we'd probably need to add post-nm-c-e dialog asking whether to apply the settings to installer. The button is originally aimed to configure network of target system which is in accord with the changes not taking effect immediately.
As for your repo case, first we'd need to add option to go back to some screen (repository editing UI) when base/install repository setup fails. I am working on patches reorganising repo UI that would make this possible.
Second, we'd need to add [Configure Network] button to that screen as we can't go back to hostname screen for the button because storage had already been written. I think that having the button also on repository editing screen makes sense.
Wasn't the problem with specifying non-functional network configuration present already before introduction of nm-c-e?
"Wasn't the problem with specifying non-functional network configuration present
already before introduction of nm-c-e?"
No, because it had a simpler fix for this that you've missed in the preceding discussion: as I recall, as soon as you configured the network it tested the connectivity and refused to let you continue if it failed.
Fedora Bugzappers volunteer triage team
well, by 'refused to let you continue', I mean it made you re-do the network configuration until it worked.
Fedora Bugzappers volunteer triage team
(In reply to comment #2)
> "Wasn't the problem with specifying non-functional network configuration
> already before introduction of nm-c-e?"
> No, because it had a simpler fix for this that you've missed in the preceding
> discussion: as I recall, as soon as you configured the network it tested the
> connectivity and refused to let you continue if it failed.
I don't remember having any testing of the connectivity. At least since we have started using NetworkManager - which is F12 for sure, but perhaps earlier - if NM reports a connection as active (no matter it has wrong static IP assigned, wrong nameserver or whatever), we consider it as being successfuly up. E.g. F12 behaves the same way as in your description. Maybe the change was transition to NetworkManager (not nm-c-e), but it would surprise me that even before we did any connectivity testing.
I'm dropping this as an NTH proposed bug pending further testing...
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: