Created attachment 478962 [details] anaconda-logs.tgz (/tmp/*) Description of problem: The installer prompts the user to enable networking at reposetup stage, during a DVD install. This wasn't expected, has this changed to be required? Version-Release number of selected component (if applicable): * anaconda-15.20-1 How reproducible: * seems like everytime so far Steps to Reproduce: 1. Boot the TC2 DVD ISO in a bare metal system, or a virtual guest 2. Proceed through the installer, selecting *all* defaults Actual results: At repoedit step, the installer prompts to enable networking. Expected results: When installing from a DVD, the user shouldn't be prompted for networking until they actively enable a network-based repo (at least I think this is the case) Additional info: See attached log files ... -rw-r--r-- root/root 33418 2011-02-15 14:51 tmp/X.log drwxr-xr-x root/root 0 2011-02-15 14:57 tmp/anaconda-screenshots/ -rw-r--r-- root/root 54022 2011-02-15 14:57 tmp/anaconda-screenshots/screenshot-0000.png -rw-r--r-- root/root 367 2011-02-15 14:51 tmp/anaconda-yum.conf -rw-r--r-- root/root 9382 2011-02-15 14:55 tmp/anaconda.log -rw-r--r-- root/root 510 2011-02-15 14:52 tmp/ifcfg.log -rw------- root/root 235 2011-02-15 14:51 tmp/libuser.eVL_s5 drwx------ root/root 0 2011-02-15 14:51 tmp/orbit-root/ -rw-r--r-- root/root 53520 2011-02-15 14:55 tmp/program.log -rw-r--r-- root/root 269333 2011-02-15 14:55 tmp/storage.log -rw-r--r-- root/root 36864 2011-02-15 14:55 tmp/storage.state -rw-r--r-- root/root 46976 2011-02-15 14:55 tmp/syslog drwxr-xr-x root/root 0 2011-02-15 14:51 tmp/updates/ -rw-r--r-- root/root 1315 2011-02-15 14:55 tmp/yum.log
I have seen the same issue that James describes and I've hit it on both the i386 and x86_64 DVD install each time I've done an install. In F14, the DVD installer would only prompt you for a network connection if you actually selected alternative repos to be used during install such as the updates-testing repo.
Anaconda is enabling network because it needs to download information (.treeinfo file) about add-on repos of (disabled) Fedora 15-Alpha and Fedora 15-Alpha Test-Updated. It came from rhel 6. Chris knows more. Perhaps we could turn it off in Fedora somehow.
(In reply to comment #2) > Anaconda is enabling network because it needs to download information > (.treeinfo file) about add-on repos of (disabled) Fedora 15-Alpha and Fedora > 15-Alpha Test-Updated. It came from rhel 6. Chris knows more. Perhaps we could > turn it off in Fedora somehow. I think we probably need to consider that. I don't think we can require network for offline DVD installs. Unless, of course, the user requests enabling network repositories. @John - in my testing, I was able to click 'cancel/ignore' when prompted for networking. Can you confirm that this workaround allows you to proceed without networking? Adding to Alpha NICE-TO-HAVE blocker (F15Alpha-accepted). If the workaround is reasonable, I don't think this would impact Alpha release criteria. But if a tested fix is available in time, it seems like a good idea to take it.
James - can you grab http://clumens.fedorapeople.org/677773.img and test it? It contains only the updated yuminstall.py so if there's other fixes you require, I may need to rework it. For my future reference, the patch is: http://fpaste.org/gX9z/
Bug 673824 triggers a similar (identical (?)) issue: Installing by means of the netinst image requires the user to configure a network interface even -before- the graphical installer is fired up which makes it impossible to access a WPA(2) encrypted access point, only a WEP encrypted one by adding options essid=<this_ap> and wepkey=<this_key> to the boot options. Once the graphical installer is available, the network configuration tool allows to set up a WPA(2) wireless connection.
(In reply to comment #4) > James - can you grab http://clumens.fedorapeople.org/677773.img and test it? > It contains only the updated yuminstall.py so if there's other fixes you > require, I may need to rework it. Using the provided updates.img seems to have worked. I rebuilt the updates.img as a compressed ext3 fs to avoid unintentionally starting the network. This also helped me test https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_local_media Yay!
@James Yes, I was able to just hit Cancel twice (it prompted me twice) and it gave up and let me through the install.
(In reply to comment #7) > @James Yes, I was able to just hit Cancel twice (it prompted me twice) and it > gave up and let me through the install. Thanks, adding CommonBugs keyword so we can document this workaround for the Alpha in case it's not fixed in time.
Per 2011-02-18 Alpha Blocker meeting: #agreed 678095 - RejectedBlocker, RejectedNTH, document Common_F15_Bugs and accept post-Alpha
*** Bug 683358 has been marked as a duplicate of this bug. ***
Hmm, I mistakenly added comments to the same effect to bug 689018 , which partially overlaps I think? In any case, this is still not fixed for me in the Beta install.iso.
(In reply to comment #11) > Hmm, I mistakenly added comments to the same effect to bug 689018 , which > partially overlaps I think? In any case, this is still not fixed for me in the > Beta install.iso. Thanks Stijn. This issue is confirmed fixed for the Beta, but fell off our radar for bug tracking. Let's continue monitoring your issue in the new bug#689018.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19