Red Hat Bugzilla – Full Text Bug Listing
|Summary:||When downloading install.img during installation, attempt to setup networking automatically as well.|
|Product:||[Fedora] Fedora||Reporter:||James Laska <jlaska>|
|Component:||preupgrade||Assignee:||Richard Hughes <rhughes>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-16 18:13:44 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description James Laska 2010-10-26 08:35:28 EDT
Created attachment 455753 [details] 0002-When-downloading-stage2.img-use-ksdevice-link-ip-dhc.patch Description of problem: When no disk space is available on /boot to save the install.img locally, preupgrade will offer to download the install.img during the installation process. When doing so, loader/anaconda prompts the user for networking information. In an effort to reduce prompts, and attempt to choose acceptable defaults, I wonder if we can add "ksdevice=link ip=dhcp ipv6=auto" to the kernel boot arguments when downloading the stage#2 install.img during installation. Version-Release number of selected component (if applicable): * Tested against preupgrade-1.1.8-1 How reproducible: * Steps to Reproduce: 1. Follow steps in https://fedoraproject.org/wiki/QA:Testcase_Preupgrade_low_/boot_disk_space_to_download Actual results: * Prompted during loader for networking information Expected results: * No prompts during preupgrade Additional info: * See proposed patch
Comment 1 Richard Hughes 2010-10-27 04:13:56 EDT
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?
Comment 2 James Laska 2010-10-27 11:41:48 EDT
(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?
Comment 3 Richard Hughes 2010-10-28 05:43:14 EDT
(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.
Comment 4 James Laska 2010-11-03 07:58:56 EDT
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
Comment 5 James Laska 2010-11-04 08:27:37 EDT
(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.
Comment 6 Richard Hughes 2010-11-05 06:10:18 EDT
(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.
Comment 7 Fedora End Of Life 2012-08-16 18:13:47 EDT
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