Description of problem: Failed to install using an NFS installation source Version-Release number of selected component (if applicable): How reproducible: anaconda14.15 F14-alpha-rc3 Steps to Reproduce: 1. Boot and initiate an install using any installation source (e.g. boot.iso, CD, DVD or pxeboot) 2. Proceed through the installer until the Software Selection step 3. At the software selection step, click Add additional software repositories and provide the information listed. If more than one package repository is listed, you may also click Modify repository for an existing unselected entry. Enter the following information, then select OK * Repository type - HTTP/FTP * Repository URL - ftp://download.englab.nay.redhat.com/pub/fedora/linux/development/14/i386/os * Uncheck URL is a mirror list Actual results: Unable to read package metadata from repository Detail info is in the attachment Expected results: 1. The package metadata from additional repository is read correctly 2. The expected packages or package groups provided by additional repository appear on the package detail screen 3. Anaconda completes and system reboots successfully 4. The checked packages provided by additional repository are installed in the system Additional info: Succeeded to install using an NFS resource by "askthod"
Version-Release: anaconda14.15 F14-alpha-rc3 How reproducible: 100%
:1,$/s/NFS/FTP/g sorry for the mistakes...
Note that ftp install only failed by running this test: https://fedoraproject.org/wiki/QA:Testcase_Additional_Ftp_Repository Repo=ftp:// and askmethod(using ftp source) work as expected.
Could it have been a transient mirror error? Did you try the test more than once? Seems like it's unlikely that the *installer* would cause a repo problem... I see "Detail info is in the attachment", but there isn't an attachment :) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The release criterion related to this bug is: "The installer must be able to use at least one of the HTTP or FTP remote package source options " We actually meant that to be about the *main installation source* - so doing an install from boot.iso using FTP or HTTP repositories, not adding FTP or HTTP repositories to a DVD install. Doing an install that way works. Also, adding an HTTP source to a DVD install works - it has a green tick from Liam in the table. So either way you can interpret the criterion, it's satisfied. Hence this bug does not block the Alpha. (Just adding this for clarification before go/no-go meeting). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 438322 [details] pic of err when installing using an FTP installation resource This is the pic of err when installing using an FTP installation resource
Hi, could you provide logs using Ctrl+Alt_F2 then /tmp/anaconda.log, ... Thanks, Jiri
Created attachment 438572 [details] anaconda.log for FTP error anaconda.log for FTP error
This would not happen when the repo version is the same as boot media, like all are rc4. But if boot media is rc3, but repo version is rc4, may cause this issue. But I think anaconda should read correctly, no matter what version of repo(like rc1, rc2, rc3, etc..).
Interestingly, if I add a nfs or http repo in advance at the repository selection step, then the same ftp repo can be retrieved successfully. So in my case, this issue happens when I firstly add a ftp repo.
HTTP links work fine. The issue is generated using FTP links. Unfortunately this issue has nothing to do with ftp package. Therefore I'm going to set needinfo flag and ask for some ideas from maintainers of curl/libcurl and yum.
Oops, one of intended addresses was not saved by BZ.
Right, anaconda uses libcurl as the FTP client. How can I repeat the issue with a public ftp server?
10.66.65.86 is not accessible from my network, so that I am getting the same result: $ curl -v ftp://10.66.65.86/pub/iso/repodata/repomd.xml * About to connect() to 10.66.65.86 port 21 (#0) * Trying 10.66.65.86... Connection timed out * couldn't connect to host * Closing connection #0 curl: (7) couldn't connect to host
Please also attach /tmp/syslog to this bug report. It looks to me like the network simply isn't active.
Created attachment 438885 [details] file "syslog" for the err when installing using a FTP resource
I am unable to reproduce this problem locally.