Bug 982329 - fedup 0.7.3-5.fc17.noarch fails to find update from Fedora 18 to Fedora 19
Summary: fedup 0.7.3-5.fc17.noarch fails to find update from Fedora 18 to Fedora 19
Alias: None
Product: Fedora
Classification: Fedora
Component: fedup
Version: 18
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Will Woods
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-07-08 17:18 UTC by Oskar Berggren
Modified: 2013-07-16 16:46 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-07-09 22:02:07 UTC
Type: Bug

Attachments (Terms of Use)

Description Oskar Berggren 2013-07-08 17:18:56 UTC
fedup complains about being unable to parse metalink.

Looking at https://mirrors.fedoraproject.org/metalink?repo=fedora-19&arch=x86_64 manually, reveals that for fedora-19, only s390 is available as an architecture. This is certainly contradictory to https://mirrors.fedoraproject.org/publiclist/Fedora/19/x86_64/.

$ sudo fedup --network 19
setting up repos...
fedora/19/x86_64/metalink                        |  25 kB  00:00:00     
Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-19&arch=x86_64 error was 
No repomd file
No upgrade available for the following repos: fedora
getting boot images...
setting up system for upgrade
Finished. Reboot to start upgrade.
WARNING: Some important repos could not be contacted: fedora
If you start the upgrade now, packages from these repos will not be installed.

Using fedup-0.7.3-5.fc17.noarch. System recently upgraded from f17 to f18. The fedup package from f17 is retained, since it has a higher version than the one in f18.

Comment 1 Will Woods 2013-07-09 22:02:07 UTC
Metalink contents are fine here:

[wwoods@metroid ~]$ curl -s 'https://mirrors.fedoraproject.org/metalink?repo=fedora-19&arch=x86_64' | grep s390 | wc -l

[wwoods@metroid ~]$ curl -s 'https://mirrors.fedoraproject.org/metalink?repo=fedora-19&arch=x86_64' | grep x86_64 | wc -l

I suspect you're getting a weird mirror from mirrormanager. Check the metalink contents to see what mirrors it's giving you.

If the mirrormanager is the problem, you should probably report that to the mirror maintainers.

In the meantime, you could use the '--addrepo/--instrepo' options to force the use of known-good mirrors. Or you could just run fedup again and see if you get more sensible data from mirrormanager.

But fedup doesn't control the contents of the mirrors (or the behavior of the mirror manager), so there's nothing here I can fix.

Comment 2 Oskar Berggren 2013-07-14 16:21:48 UTC
My point is that mirrormanager didn't give me any mirrors at all. The result from 
wasn't a list of mirrors - it looked like this:

<?xml version="1.0" encoding="utf-8"?>
<metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Sun, 14 Jul 2013 16:10:55 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager">
# repo = fedora-19 arch = x86_64 error: invalid repo or arch
# following repositories are available:
# repo=fedora-19&arch=s390
# repo=fedora-19&arch=s390x

(for other versions, more architectures were available)

I'm guessing here that this XML-file is generated from a master system, and not from some particular mirror?

If I try the link now, it does appear to correctly show the mirrors for x86_64.

I agree the mirrors problem isn't itself a bug in fedup, but I spent some time without being able to figure out where to should be reported.

Also, it seems weird that fedup, despite this error, proceeds to make "System Upgrade" the default in GRUB. It feels like there could be significant problems if it runs "half" of an upgrade. Is it impossible for fedup detect this as a critical error and avoid proceeding?

Comment 3 Oskar Berggren 2013-07-14 17:07:11 UTC
Just to remind, fedup left the System Upgrade option as default in grub, but since I have seen the warning regarding the fedora repository, I didn't execute it. Today I got a kernel upgrade, and this kernel upgrade now reused the "systemd.unit=system-upgrade.target" in the linux command line, causing a boot of the new kernel to automatically reboot towards the end of the boot process.

This really isn't working as nicely as one would wish for.

Comment 4 Will Woods 2013-07-16 16:46:19 UTC
That's a known problem. See bug 964303.

Note You need to log in before you can comment on or make changes to this bug.