On 11/8/19 9:05 PM, Ed Greshko wrote:
On 11/9/19 9:34 AM, Temlakos wrote:
On 11/8/19 8:08 PM, Ed Greshko wrote:
On 11/9/19 9:04 AM, Temlakos wrote:
The log at /var/log/dnf.log has a "CRITICAL ERROR" message--something about having conflicting commands and not being able to install the "best" version. They suggest passing the --skip-broken switch.
First, post the exact "errors".
Questions:
1. How do I remove the present downloads so I can start over?
dnf system-upgrade clean
- Should I pass the --best flag, when running dnf system-upgrade
download, or skip that?
3. Should I pass --allowerasing?
4. Should I pass --skip-broken?
And especially should I pass --allowerasing and --skip-broken both at once?
The last 3 questions are irrelevant until the error is understood.
I believe the relevant passage in dnf.log is as follows:
Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 122, in cli_run ret = resolving(cli, base) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 158, in resolving base.resolve(cli.demands.allow_erasing) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 766, in resolve raise exc dnf.exceptions.DepsolveError: Problem: cannot install the best candidate for the job - conflicting requests 2019-11-08T23:36:58Z CRITICAL Error: Problem: cannot install the best candidate for the job - conflicting requests 2019-11-08T23:36:58Z INFO (try to add '--skip-broken' to skip uninstallable packages) 2019-11-08T23:36:58Z DDEBUG Cleaning up.
Before that, I see the following somewhat unusual entries:
2019-11-08T23:36:41Z DDEBUG Base command: system-upgrade 2019-11-08T23:36:41Z DDEBUG Extra commands: ['system-upgrade', 'upgrade'] 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/bunkus-org.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/bunkus-org.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist 2019-11-08T23:36:41Z DEBUG Unknown configuration value: failovermethod=priority in /etc/yum.repos.d/fedora-updates-modular.repo; Configuration: OptionBinding with id "failovermethod" does not exist
Those messages are benign.
The repostory "bunkus-org.repo" has one package in it, called mkvtoolnix, that I updated just before running dnf system-upgrade download.
I have not seen fedora-updates-modular.repo before.
Every other repository seems to have good information.
I still don't see, from what you've supplied, what packages are causing the issue.
I would run...
dnf system-upgrade clean and then dnf system-upgrade download --releasever=31
followed by
dnf system-upgrade reboot
And check the logs again.
At this point I would certainly *not* add --allowerasing, --skip-broken, or --best. I find these options are "options of last resort" which should only be used *after* probelms have been fully identified and understood. I find adding them without question can confuse more than clarify.
Success!
First I re-ran dnf upgrade --refresh, to make sure I had a fully up-to-date system.
Then I followed your instructions almost to the letter, in that I passed --refresh to dnf system-upgrade download, per the "Quick system-upgrade doc" accessible through a link at getfedora.com. I did not pass --best, --allowerasing, or --skip-broken.
Two remarkable things:
1. A download process that before had taken about seven hours, took forty minutes this time.
2. The system did not instruct me to run the command again; it said to run dnf system-upgrade reboot forthwith.
This I did.
It went through three cycles of the progress bar moving from zero to 100 percent complete. The first took about a minute; the second maybe twenty minutes; the third about five minutes.
After that it booted into F31, which is what I am now running. I know this because it installed an F31 version of the current kernel.
You've given me good advice before; you did so again this time. Thank you.
Temlakos