Bug 1161464

Summary:	fedup --network 21 --product workstation: Could not parse metalink fedora-install-21
Product:	[Fedora] Fedora	Reporter:	Ralf Corsepius <rc040203>
Component:	fedup	Assignee:	Will Woods <wwoods>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	awilliam, tflink, wwoods
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-11-10 17:42:27 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ralf Corsepius 2014-11-07 08:00:01 UTC

Description of problem:

# fedup --network 21 --product workstation
...
Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-install-21&arch=x86_64 error was 
No repomd file
...


Version-Release number of selected component (if applicable):
fedup-0.9.0-2.fc20.noarch

How reproducible:
Always

Expected results:
Function.

Additional info:
I am not sure about what's supposed to happen in this situation.

From what I see inside of the metalink, my gut feeling tells me fedup likely wants to access
"repo=fedora-workstation-21&arch=x86_64"
instead of 
"repo=fedora-install-21&arch=x86_64"

Comment 1 Will Woods 2014-11-10 17:42:27 UTC

This is intentional, and it should be fixed before the final release.

See the Common Bugs page for more information:

  http://fedoraproject.org/wiki/Common_F21_bugs#no-fedup-beta

*** This bug has been marked as a duplicate of bug 1160931 ***

Comment 2 Ralf Corsepius 2014-11-10 18:02:41 UTC

(In reply to Will Woods from comment #1)
> This is intentional,
Well, I fail to understand why this should be intentional?

We're in the final testing phase of a release, which should imply all such issues must be fixed ASAP, IMO.

> and it should be fixed before the final release.
Interesting answer - Earlier today, I found this seems to have been fixed ?!?

Comment 3 Will Woods 2014-11-10 18:52:49 UTC

(In reply to Ralf Corsepius from comment #2)
> (In reply to Will Woods from comment #1)
> > This is intentional,
> Well, I fail to understand why this should be intentional?
> 
> We're in the final testing phase of a release, which should imply all such
> issues must be fixed ASAP, IMO.

This isn't something I can fix. It's a mirrormanager problem. You should read the Common Bugs page and bug 1160931 if you actually want to understand the problem.

> > and it should be fixed before the final release.
> Interesting answer - Earlier today, I found this seems to have been fixed ?!?

I don't know, maybe it has? I don't control the repos. Talk to rel-eng if you want to know more.

Comment 4 Adam Williamson 2014-11-11 03:46:21 UTC

It was fixed two days ago. This is certainly "before the final release".

There's a very dull story behind why it got changed when it got changed, that I don't really feel like telling right now, but there are bits of it around the place in https://bugzilla.redhat.com/show_bug.cgi?id=1160931 and anaconda-devel-list archives.