Everyone:
I just tried to upgrade to F31. And I couldn't get past a few seconds in the upgrade environment before it "failed out" and rebooted to F30, after touching nothing.
For the record: I started by running:
sudo dnf upgrade --refresh
When one of my packages (a third-party package named mkvtoolnix) didn't upgrade I reran the upgrade command with two additional flags, per the explicit suggestion:
sudo dnf upgrade --best --allowerasing
That did it, and I have a working version of mkvtoolnix, even with its GUI apparently baked in (so that the separate mkvtoolnix-gui package is obsolete and now removed).
Then I ran this command:
sudo dnf system-upgrade download --refresh --releasever=31 --best --allowerasing
It took many hours, but I got 2.8 gigabytes of downloads. I also imported three GPG keys. It did successful transaction check and test. Before anyone asks: I have never been able to do a successful CLI upgrade using the system-upgrade package without passing the --allowerasing switch to the download command. I passed the --best switch because it seemed to work on the upgrade command and I thought I was adding an extra measure of security.
Then I ran
sudo dnf system-upgrade reboot
And what happened? Well, first it rebooted into the upgrade environment. And I saw the progress screen.
And then, rather abruptly, the upgrade progress screen vanished. I saw a very brief message from a program called "watchdog" that went by too quickly to read.
Then it rebooted into my present F30 environment.
Result: I have a working system, but it's still in F30 and I don't know why it failed to start the upgrade process, or how to get it started.
At the moment I have a bunch of downloads of F31 packages, all dressed up and nowhere to go.
If anyone wants to see logs, I ask just one thing: tell me what are their names, and in what folder I will find them. Then I'll be happy to copy and paste them.
As far as I know, nothing like this issue has shown up in Bugzilla, unless I'm missing something.
Temlakos
On 11/8/19 7:40 PM, Temlakos wrote:
Everyone:
I just tried to upgrade to F31. And I couldn't get past a few seconds in the upgrade environment before it "failed out" and rebooted to F30, after touching nothing.
For the record: I started by running:
sudo dnf upgrade --refresh
When one of my packages (a third-party package named mkvtoolnix) didn't upgrade I reran the upgrade command with two additional flags, per the explicit suggestion:
sudo dnf upgrade --best --allowerasing
That did it, and I have a working version of mkvtoolnix, even with its GUI apparently baked in (so that the separate mkvtoolnix-gui package is obsolete and now removed).
Then I ran this command:
sudo dnf system-upgrade download --refresh --releasever=31 --best --allowerasing
It took many hours, but I got 2.8 gigabytes of downloads. I also imported three GPG keys. It did successful transaction check and test. Before anyone asks: I have never been able to do a successful CLI upgrade using the system-upgrade package without passing the --allowerasing switch to the download command. I passed the --best switch because it seemed to work on the upgrade command and I thought I was adding an extra measure of security.
Then I ran
sudo dnf system-upgrade reboot
And what happened? Well, first it rebooted into the upgrade environment. And I saw the progress screen.
And then, rather abruptly, the upgrade progress screen vanished. I saw a very brief message from a program called "watchdog" that went by too quickly to read.
Then it rebooted into my present F30 environment.
Result: I have a working system, but it's still in F30 and I don't know why it failed to start the upgrade process, or how to get it started.
At the moment I have a bunch of downloads of F31 packages, all dressed up and nowhere to go.
If anyone wants to see logs, I ask just one thing: tell me what are their names, and in what folder I will find them. Then I'll be happy to copy and paste them.
As far as I know, nothing like this issue has shown up in Bugzilla, unless I'm missing something.
Temlakos
Postscript:
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.
Questions:
1. How do I remove the present downloads so I can start over?
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?
Temlakos
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.
On 11/9/19 8:40 AM, Temlakos wrote:
If anyone wants to see logs, I ask just one thing: tell me what are their names, and in what folder I will find them. Then I'll be happy to copy and paste them.
First question. Do you have python3-dnf-plugin-system-upgrade-4.0.7-2.fc30 installed? It is the latest version which addresses some cases with symptoms you've described.
The logs you want to investigate are
dnf.librepo.log dnf.log dnf.log.1 dnf.rpm.log
located in /var/log
Hi,
Run this command: journalctl -r Then search 'Failed to start System Upgrade using DNF' or 'system-upgrade'.
Can you find any matching line?
If so, you may also see some errors related to this issue. Fix that error should let you upgrade to F31.
On Sat, Nov 9, 2019 at 8:41 AM Temlakos temlakos@gmail.com wrote:
Everyone:
I just tried to upgrade to F31. And I couldn't get past a few seconds in the upgrade environment before it "failed out" and rebooted to F30, after touching nothing.
For the record: I started by running:
sudo dnf upgrade --refresh
When one of my packages (a third-party package named mkvtoolnix) didn't upgrade I reran the upgrade command with two additional flags, per the explicit suggestion:
sudo dnf upgrade --best --allowerasing
That did it, and I have a working version of mkvtoolnix, even with its GUI apparently baked in (so that the separate mkvtoolnix-gui package is obsolete and now removed).
Then I ran this command:
sudo dnf system-upgrade download --refresh --releasever=31 --best --allowerasing
It took many hours, but I got 2.8 gigabytes of downloads. I also imported three GPG keys. It did successful transaction check and test. Before anyone asks: I have never been able to do a successful CLI upgrade using the system-upgrade package without passing the --allowerasing switch to the download command. I passed the --best switch because it seemed to work on the upgrade command and I thought I was adding an extra measure of security.
Then I ran
sudo dnf system-upgrade reboot
And what happened? Well, first it rebooted into the upgrade environment. And I saw the progress screen.
And then, rather abruptly, the upgrade progress screen vanished. I saw a very brief message from a program called "watchdog" that went by too quickly to read.
Then it rebooted into my present F30 environment.
Result: I have a working system, but it's still in F30 and I don't know why it failed to start the upgrade process, or how to get it started.
At the moment I have a bunch of downloads of F31 packages, all dressed up and nowhere to go.
If anyone wants to see logs, I ask just one thing: tell me what are their names, and in what folder I will find them. Then I'll be happy to copy and paste them.
As far as I know, nothing like this issue has shown up in Bugzilla, unless I'm missing something.
Temlakos _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
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
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.
Temlakos
On 11/8/19 8:10 PM, Ed Greshko wrote:
On 11/9/19 8:40 AM, Temlakos wrote:
If anyone wants to see logs, I ask just one thing: tell me what are their names, and in what folder I will find them. Then I'll be happy to copy and paste them.
First question. Do you have python3-dnf-plugin-system-upgrade-4.0.7-2.fc30 installed? It is the latest version which addresses some cases with symptoms you've described.
The logs you want to investigate are
dnf.librepo.log dnf.log dnf.log.1 dnf.rpm.log
located in /var/log
Yes, I have the python package you named, in the version you named.
I have just sent in some clippings from dnf.log.
Temlakos
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.
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
On 11/8/19 4:40 PM, Temlakos wrote:
Then I ran this command:
sudo dnf system-upgrade download --refresh --releasever=31 --best --allowerasing
It took many hours, but I got 2.8 gigabytes of downloads. I also imported three GPG keys. It did successful transaction check and test. Before anyone asks: I have never been able to do a successful CLI upgrade using the system-upgrade package without passing the --allowerasing switch to the download command. I passed the --best switch because it seemed to work on the upgrade command and I thought I was adding an extra measure of security.
I've often had to use --allowerasing and there was a bug recently fixed with that. Your problem was likely caused by adding the "--best" option. That should not be necessary for a system-upgrade.
-
Ed Greshko -
Samuel Sieb -
Simon -
Temlakos