Bug 982329 - fedup 0.7.3-5.fc17.noarch fails to find update from Fedora 18 to Fedora 19
fedup 0.7.3-5.fc17.noarch fails to find update from Fedora 18 to Fedora 19
Product: Fedora
Classification: Fedora
Component: fedup (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Will Woods
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-07-08 13:18 EDT by Oskar Berggren
Modified: 2013-07-16 12:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-09 18:02:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Oskar Berggren 2013-07-08 13:18:56 EDT
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 18:02:07 EDT
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 12:21:48 EDT
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 13:07:11 EDT
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 12:46:19 EDT
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.