Bug 646837

Makes a lot of sense to me, but what happens if the user has to use a static IP, do we then show the networking setup screen? Or do we not care about that use case?

(In reply to comment #1)
> Makes a lot of sense to me, but what happens if the user has to use a static
> IP, do we then show the networking setup screen? Or do we not care about that
> use case?

Darnit, I was hoping you wouldn't ask! :)

I just tested preupgrading with "stage2=<remote URL> ksdevice=link ip=dhcp ipv6=auto" on a KVM guest where <dhcp> was removed from the virtual network configuration (aka ... dhcp is not running).  Since DHCP isn't available, the user is prompted with a dialog:

 There was a error configuring your network interface
 [Retry]

They are not able to go back and manually configure static networking.  I don't know if that's expected behavior for anaconda.  Either way, it seems that for a subset of users without DHCP, this proposed patch isn't a good fit.

I can probably fiddle around with a different patch that talks to NM to determine how their currently active network is configured?  I don't know how much code would be involved there, and I suspect it would just be *easier* to let the user tell us on boot.  

What do you think?

(In reply to comment #2)
> Darnit, I was hoping you wouldn't ask! :)

:-)

> I just tested preupgrading with "stage2=<remote URL> ksdevice=link ip=dhcp
> ipv6=auto" on a KVM guest where <dhcp> was removed from the virtual network
> configuration (aka ... dhcp is not running).  Since DHCP isn't available, the
> user is prompted with a dialog:
> 
>  There was a error configuring your network interface
>  [Retry]
> 
> They are not able to go back and manually configure static networking.  I don't
> know if that's expected behavior for anaconda.  Either way, it seems that for a
> subset of users without DHCP, this proposed patch isn't a good fit.

Surely we just fix anaconda to be able to "go back" to the network config screen, rather than just retry with wrong settings?

> I can probably fiddle around with a different patch that talks to NM to
> determine how their currently active network is configured?  I don't know how
> much code would be involved there, and I suspect it would just be *easier* to
> let the user tell us on boot.  

Nahh, 99.9% of people will be using dhcp, so you're patch idea is good. The problem is we need to be able to allow the other 0.1% of [angry and vocal] people to upgrade too :-)

Richard.

Progress update ... I've attempted to adjust anaconda loader so that in the event that "ksdevice=link ip=dhcp" fails, it will allow the user to manually specify network information.  I'll follow-up here with the outcome.

See https://www.redhat.com/archives/anaconda-devel-list/2010-November/msg00009.html

(In reply to comment #4)
> I'll follow-up here with the outcome.

I believe we are safe to proceed for preupgrade >= F-14 now that the rawhide (F-15) installer will allow users to select a different NIC and/or IP options if 'ksdevice=link ip=dhcp ipv6=dhcp" fails.

http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=9808b9974ad686d0e2a5d5ca57972753352ea4cf

The rub here will be that *only* preupgrade for F-14 can have this change since older versions of anaconda may not allow the user to fall-back without manually tweaking the boot arguments.  I'm not sure if you want to branch preupgrade for F-14 and newer to include this change, or to add logic to preupgrade to inspect the version in .treeinfo, or target_version used when creating the kickstart, before adding the boot arguments.

(In reply to comment #5)
> (In reply to comment #4)
> > I'll follow-up here with the outcome.
> 
> I believe we are safe to proceed for preupgrade >= F-14 now that the rawhide
> (F-15) installer will allow users to select a different NIC and/or IP options
> if 'ksdevice=link ip=dhcp ipv6=dhcp" fails.

Excellent, thanks for doing this. When the preupgrade backend code moves to PackageKit (which I'm in the process of doing) I'll add this option. Thanks.

Richard.

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