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
2. 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
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
