Created attachment 403253 [details] mirrorlist Description of problem: Add a mirror-list repository,anaconda fails to active network to read package metadata Version-Release number of selected component (if applicable): 13.37 How reproducible: always Steps to Reproduce: 1.https://fedoraproject.org/wiki/QA:Testcase_Additional_Mirrorlist_Repository 2. process default install,add mirror list, will fail to read metadata, cancel add, and modify an unselected repo to activate network, reinput the mirrorlist repository, anaconda can read metadata successfully. Expected results: After input mirror list repository, anaconda should activate network to read meta data.
Just adding a note that the fail concerns also modifying non-net-requiring repository to a net-requiring one (e.g. DVD -> http). This updates image (for anaconda 13.37): http://rvykydal.fedorapeople.org/updates.repoaddnetf13.img contains a patch: https://www.redhat.com/archives/anaconda-devel-list/2010-March/msg00450.html that should fix it.
(In reply to comment #1) > Just adding a note that the fail concerns also modifying non-net-requiring > repository to a net-requiring one (e.g. DVD -> http). > > This updates image (for anaconda 13.37): > http://rvykydal.fedorapeople.org/updates.repoaddnetf13.img > contains a patch: > https://www.redhat.com/archives/anaconda-devel-list/2010-March/msg00450.html > that should fix it. Verified the updates fixing it.
(In reply to comment #2) > (In reply to comment #1) > > Just adding a note that the fail concerns also modifying non-net-requiring > > repository to a net-requiring one (e.g. DVD -> http). > > > > This updates image (for anaconda 13.37): > > http://rvykydal.fedorapeople.org/updates.repoaddnetf13.img > > contains a patch: > > https://www.redhat.com/archives/anaconda-devel-list/2010-March/msg00450.html > > that should fix it. > > Verified the updates fixing it. Ah, I did the steps like this: 1. Input http://rvykydal.fedorapeople.org/updates.repoaddnetf13.img as kernel parameter on grub, so the network enabled at stage1. 2. On stage 2, I switched to tty2 and execute 'ifconfig eth0 down' to disable network. 3. At repo step, when I tried to add new http/ftp repo, the 'Enabling network interface' could pop up. (But clicking OK can't set up because of ??) Note: network doesn't try to enable when adding nfs repo.
(In reply to comment #3) Thanks for retesting > > Ah, I did the steps like this: > > 1. Input http://rvykydal.fedorapeople.org/updates.repoaddnetf13.img as kernel > parameter on grub, so the network enabled at stage1. > Oh, I forgot about this - I used made an iso image containing updates image and loaded it from cdrom in virtual machine so that network wasn't enabled at stage1 (only using "updates" boot parameter, then being asked for device in loader UI). > 2. On stage 2, I switched to tty2 and execute 'ifconfig eth0 down' to disable > network. > You should rather disable network on eth0 by copying this: DEVICE=eth0 HWADDR=<YOUR MAC ADDRESS OF DEVICE> ONBOOT=no NM_CONTROLLED=no in /etc/sysconfig/network-scripts/ifcfg-eth0 > 3. At repo step, when I tried to add new http/ftp repo, the 'Enabling network > interface' could pop up. (But clicking OK can't set up because of ??) > yes, it's because of 2. > Note: network doesn't try to enable when adding nfs repo. Good catch, I'll look at it.
Proposing this is as F13Blocker candidate.
Should be fixed in version 14.3-1 of anaconda.
I appear to be hitting this also on a netinst.iso install
(In reply to comment #7) > I appear to be hitting this also on a netinst.iso install False alarm. For some reason, this bug surfaces when booting the boot.iso, adding an iSCSI volume, and attempting to install to the pre-configured http repositories.
The fix did not push into anaconda 13.37.2 yet, still affect additional http/ftp/nfs/mirrorlist repository
Didn't hit the bug doing a local NFS install to an adjacent machine on the local net.
I still hit the bug on f13-beta-RC4
(In reply to comment #11) > I still hit the bug on f13-beta-RC4 Liam, I only proposed the bug as F13 blocker, but it hasn't been accepted (yet?), so the patch is not in F13 branch, only in master, at the moment (see Fixed in version). If I push it in f13-branch, I'll make a note in this BZ.
anaconda of f13-beta-RC4 is the same as f13-beta-RC3, both are 13.37.2, that's why we still hit this bug. I just make a notice here for testers. I saw the bug has been set to F13Blocker list, if did not accept, it will be removed from the blocker list.
Just to summarize a little for blocker review: The descritption in https://fedoraproject.org/wiki/Common_F13_bugs#add-repo-fail is right, I'd just note here that necessary condition for the bug is that up until failing add of network repo, the network has not been brought up (typically e.g. media install without ks). Workarounds are described in anaconda-devel-list post linked from CommonBugs.
*** Bug 587860 has been marked as a duplicate of this bug. ***
did this fix get pushed into the f13 anaconda branch yet? anaconda team we really need to get together and sort this process out for the future. if it has not been pushed yet please push ASAP so it gets into the next anaconda build for f13 (I'm assuming there'll be another before we go final). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I just tested this using a F-13-Final-TC1 netinst.iso I believe that captures the 'steps to reproduce', but I'd like to confirm that the fix is included in anaconda-13.39-1
"I believe that captures the 'steps to reproduce'" I don't believe it does. Note in the Common Bugs page: "attempting to add a new network package repository may result in a failure. Using or modifying existing package repositories (e.g. Fedora 13 Updates Testing) will not result in a failure." I think to hit this you have to add an entirely new network repo at the repo selection stage - say, you have a repo on your internal network you want to use instead of the pre-defined ones. I think just selecting one of the pre-defined repos won't do it. Not sure, but that's my read. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #18) > "I believe that captures the 'steps to reproduce'" > > I don't believe it does. Note in the Common Bugs page: > > "attempting to add a new network package repository may result in a failure. > Using or modifying existing package repositories (e.g. Fedora 13 Updates > Testing) will not result in a failure." > > I think to hit this you have to add an entirely new network repo at the repo > selection stage - say, you have a repo on your internal network you want to use > instead of the pre-defined ones. I think just selecting one of the pre-defined > repos won't do it. Not sure, but that's my read. Agreed. I tested by adding an entirely new repository, both http and http mirrorlist.
For those interested in the test details ... * http://fedoraproject.org/wiki/QA:Testcase_Additional_Http_Repository * http://fedoraproject.org/wiki/QA:Testcase_Additional_Mirrorlist_Repository (using rpmfusion.org mirrorlist)
I hit this on anaconda 13.39 too, hope the fix is pushed to next version
Should be fixed in anaconda-13.40-1
(In reply to comment #21) > I hit this on anaconda 13.39 too, hope the fix is pushed to next version Aha! Based on Liam's feedback, I tried to understand what might be different about my testing. Here's what I found. * PASS - When you boot the netinst.iso (boot.iso) > Add a new http repo url - http://rhe.fedorapeople.org/repotest > Add a new mirrorlist repo url - http://mirrors.fedoraproject.org/metalink?repo=fedora-11&arch=i386 * FAIL - When you boot the CD or DVD.iso > Add a new mirrorlist repo url - http://mirrors.fedoraproject.org/metalink?repo=fedora-11&arch=i386 > Add a new http repo url - http://rhe.fedorapeople.org/repotest = Additional Notes = * The netinst/boot.iso scenario works fine ... I could not find problems there * I am *not* prompted for networking details when attempting to *add* a new repo when booting the DVD. * I am prompted for networking details when attempting to *modify* an existing repo when booting the DVD. * Regardless of the network setup prompt, I am unable to modify or create any network repositories when booting the DVD. I believe this still matches the use case noted when originally filing this bug. I also learned that this fix was never committed to f13-branch. Radek has fixed that, and this should be fixed in anaconda-13.40-1.
so the fix should be available in the updates.img: http://people.fedoraproject.org/~jwrdegoede/f13-updates.img we should test it.
(In reply to comment #24) > so the fix should be available in the updates.img: > > http://people.fedoraproject.org/~jwrdegoede/f13-updates.img > > we should test it. Yes, but please note that booting with updates=http://... will work around the bug. You will need to test by loading the updates.img from a local device (such as a CDROM or Floppy. I can attempt testing tomorrow by booting the DVD.iso, loading the updates.img as a virt floppy device, and booting with "updates".
anaconda-13.40-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/anaconda-13.40-1.fc13
anaconda-13.40-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update anaconda'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/anaconda-13.40-1.fc13
(In reply to comment #23) > (In reply to comment #21) > > I hit this on anaconda 13.39 too, hope the fix is pushed to next version > > Aha! Based on Liam's feedback, I tried to understand what might be different > about my testing. Here's what I found. > > * PASS - When you boot the netinst.iso (boot.iso) > > Add a new http repo url - http://rhe.fedorapeople.org/repotest > > Add a new mirrorlist repo url - > http://mirrors.fedoraproject.org/metalink?repo=fedora-11&arch=i386 > * FAIL - When you boot the CD or DVD.iso > > Add a new mirrorlist repo url - > http://mirrors.fedoraproject.org/metalink?repo=fedora-11&arch=i386 > > Add a new http repo url - http://rhe.fedorapeople.org/repotest > > = Additional Notes = > * The netinst/boot.iso scenario works fine ... I could not find problems there > * I am *not* prompted for networking details when attempting to *add* a new > repo when booting the DVD. > * I am prompted for networking details when attempting to *modify* an existing > repo when booting the DVD. > * Regardless of the network setup prompt, I am unable to modify or create any > network repositories when booting the DVD. > > I believe this still matches the use case noted when originally filing this > bug. I also learned that this fix was never committed to f13-branch. Radek > has fixed that, and this should be fixed in anaconda-13.40-1. Thanks for James, your test is very specific.If we test with netinst.iso,we need to give an install tree(http/ftp/nfs) in grub command line or installer will find install tree from internet automatically, both cases will activate the network. If the network was activated, we will not encounter this issue. But if we boot from DVD or CD, the network would not be activated, in package selection step, we try to add a new install repo(http/ftp/nfs), at this time, if we switch to tty2(ctrl+Alt+F2),run ifconfig eth0, we find eth0 has no ip address. So when we add a new install repo at this time, the installer should activate the network to fine the install tree from added repo, but actually,it did not.
(In reply to comment #25) > (In reply to comment #24) > > so the fix should be available in the updates.img: > > > > http://people.fedoraproject.org/~jwrdegoede/f13-updates.img > > > > we should test it. > > Yes, but please note that booting with updates=http://... will work around the > bug. You will need to test by loading the updates.img from a local device > (such as a CDROM or Floppy. I can attempt testing tomorrow by booting the > DVD.iso, loading the updates.img as a virt floppy device, and booting with > "updates". If hard to load from floppy device, we can do like this: 1. booting with updates=http://server/to/updates.img, in this case, the network must be activated, it doesn't matter,we continue 2. in package selection step, switch to tty2(Ctrl+Alt+F2), ifconfig eth0, we can see eth0 has IP address. Stop network to make it have no IP address. 3. Switch to tty6(anaconda), add a repo, to see whether anaconda can activate the network to find install tree from added repo . If it can , the bug was fixed
Hurry helped test it last time, it did is fixed
Confirmed fix by loading updates.img via a virt floppy device. Network was *NOT* active when transitioning to reposetup step. I selected "Add additional software repositories", entered a mirrorlist URL (http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-13&arch=i386), selected OK. I was prompted for network access information. Anaconda enabled the network, and read the repodata from the requested mirrorlist URL. I was able to repeat to the procedure using a non-mirrorlist http repository (http://rhe.fedorapeople.org/repotest). Loading the updates.img from a floppy device (as to not activate the network), I'm able to add network repositories when booting and installing from a non-network media (DVD). I also tested using the procedure outlined by Liam in comment#29. 1) updates=http://jlaska.fedorapeople.org/updates.img 2) At reposetup step, manually deactivate network on tty2 3) Add a network-based package repository
(In reply to comment #31) > > I also tested using the procedure outlined by Liam in comment#29. > 1) updates=http://jlaska.fedorapeople.org/updates.img > 2) At reposetup step, manually deactivate network on tty2 > 3) Add a network-based package repository I posted prematurely, the alternative method for reproducing this failure does not work. I can confirm the original problem most likely to be hit by users is resolved with this fix. But manually deactivating the network mid-install, and having anaconda bring it back up does not work.
(In reply to comment #32) > (In reply to comment #31) > > > > I also tested using the procedure outlined by Liam in comment#29. > > 1) updates=http://jlaska.fedorapeople.org/updates.img > > 2) At reposetup step, manually deactivate network on tty2 > > 3) Add a network-based package repository > > I posted prematurely, the alternative method for reproducing this failure does > not work. > > I can confirm the original problem most likely to be hit by users is resolved > with this fix. But manually deactivating the network mid-install, and having > anaconda bring it back up does not work. Using Radek's suggested method for manually disabling eth0 (see comment#4) correctly reproduces the problem. I can confirm that the updates.img resolves the issue in both methods of reproducing the problem.
We should now be able to confirm that this bug is fixed using the images here: http://alt.fedoraproject.org/pub/alt/stage/13.0505/Fedora/i386/os/images/ if we have not yet confirmed the fix, can anyone able to reproduce this bug please test with one of those images and check that the bug is fixed? Thanks.
FYI ... a CD or DVD will be required to fully verify this issue is fully resolved. I'm reasonably comfortable with the confirmation in comment#31 and comment#33 . But let's leave this open until a DVD is available.
Tested with a locally composed DVD. Adding the mirror list indeed prompts the network bringup window, which brings up the network and gets repodata across the network.
let's close this, then. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
anaconda-13.40-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.