I can't get the traceback because of another bug blocking the save dialog, but the last lines is: IOError: [Error 2] No such file or directory: '/mnt/sysimage/var/cache/yum/updates/repomd.xml' tty1 shows: Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-frawhide@arch-x86_64 error was File /mnt/sysimage/var/cache/yum/updates/metalink.xml.tmp is not XML So there is multiple problems. 1) the "frawhide" thing, we could probably work with that in mirrormanager. Release is rawhide so yeah. The second thing is we shouldn't traceback when this hits, we should fail gracefully.
*** Bug 500526 has been marked as a duplicate of this bug. ***
This should be fixed in the next build of anaconda, though I think Jeremy's planning on doing something in yum to prevent us from ever getting an IOError.
I still see this with -52 btw.
When will it say "Fedora 11 Updates" in the anaconda repo list? Anyway anaconda is still getting confusing with "Fedora development - Updates" with anaconda -56. No obvious backtrace but hangs. tty1 still says: Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-fdevelopment&arch=i386 error was File /mnt/sysimage/var/cache/yum/updates/metalink.xml.tmp is not XML Anyway I also opened https://fedorahosted.org/mirrormanager/ticket/12 in the hope the MM might handle this more gracefully too.
It'll say Fedora 11 Updates when it's composed as Fedora 11.
the updates*-fdevelopment metalinks now point to -f11.
Thanks Matt - that helps a lot. Dunno if we should open another bug for the non-xml case?
Jens, can you elaborate? On the mirrorlist=... non-metalink, the behavior will be exactly the same from MM's perspective. The redirect happens early, long before the output format is decided upon.
(In reply to comment #8) > Jens, can you elaborate? On the mirrorlist=... non-metalink, the behavior will > be exactly the same from MM's perspective. The redirect happens early, long > before the output format is decided upon. Matt, I guess the problem is that the error page was not valid XML, which confused anaconda - so I dunno if MM should output valid XML even if there is an error or anaconda should handle the text error output (non-XML) better - I suspect probably the latter? Otherwise probably hard to separate them?
MM returns an "empty" xml document and HTTP 404 in the event of a failed request. doc += '<?xml version="1.0" encoding="utf-8"?>\n' doc += '<!--\n' doc += '%s/%s not found or has no metalink\n' % (directory, file) doc += '-->\n' That's all I could think to do in MM.
How about: https://mirrors.fedoraproject.org/metalink?repo=updates-released-f11 or https://mirrors.fedoraproject.org/metalink?repo=updates-released-flinux&arch=i386 ?
that is a bug in MM then. I opened another bug to track that separately.
(In reply to comment #7) > Thanks Matt - that helps a lot. > > Dunno if we should open another bug for the non-xml case? Jens, does this imply you have tested the fix mdomsch provided in comment#6. Can we move this issue to CLOSED RAWHIDE?
Yes, install with "devel" updates seems fine now.