Bug 1494178

Summary: dnf system-upgrade: dnf.exceptions.RepoError: Failed to synchronize cache for repo 'updates-testing'
Product: [Fedora] Fedora Reporter: Satish Balay <balay>
Component: dnf-plugins-extrasAssignee: rpm-software-management
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 26CC: ignatenko, rpm-software-management
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-09-21 18:01:56 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:
Attachments:
Description Flags
/var/log/dnf.log none

Description Satish Balay 2017-09-21 15:24:02 UTC 
Created attachment 1329049 [details]
/var/log/dnf.log

Description of problem:

Upgrading to F27 from F26 using 'dnf system upgrade' gives an error on rebooting with 'dnf system-upgrade reboot'

Version-Release number of selected component (if applicable):

DNF version: 2.6.3

How reproducible:

Once

Steps to Reproduce:
1. Start with F26
2. enable updates-testing repo
3. dnf system-upgrade download --enablerepo=updates-testing --releasever=27
4. dnf system-upgrade reboot

Actual results:

system upgrade to f27 fails - and then reboots back to F26

Expected results:

system upgrade to f27 should complete without error

Additional info:

librepo.LibrepoException: (8, "Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=updates-testing-f27&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org]", 'An Curl handle error')


It appears that 'dnf' is doing a network check for the repo data during this stage - and perhaps the network was not up by that time - so it aborted.

Shouldn't dnf do a 'yum localupdate' equivalent operation at this stage - and not rely on the network?

Also this metadata sync operation [if there is anything new to download] invalidates any of the checks 'dnf system-upgrade download' did - prior to 'dnf system-upgrade reboot'


Subsequent 'dnf system-upgrade reboot' got the upgrade to F27 going without this error
Comment 1 Satish Balay 2017-09-21 15:42:48 UTC 
(In reply to Satish Balay from comment #0)

> 3. dnf system-upgrade download --enablerepo=updates-testing --releasever=27

Sorry - should have said 'dnf system-upgrade download --releasever=27' 

the updates-testing repo was enabled manually due to #1490832

From dnf.log

2017-09-20T23:52:54Z DDEBUG Command: dnf --releasever=27 system-upgrade upgrade
Comment 2 Satish Balay 2017-09-21 18:01:56 UTC 

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