This is the first time I've had issues with an upgrade.
Laptop is a fully updated F30 system running only KDE desktop. It is an older Acer Aspire 5920.
The package are downloaded and upon "system-upgrade reboot" the system does reboot and a screen saying "updates being installed, don't turn off". After a few minutes the system reboots again but into a normal F30 state.
dnf system-upgrade log --number=-1
Oct 17 07:34:57 acer.greshko.com systemd[1]: dnf-system-upgrade.service: Failed with result 'exit-code'. Oct 17 07:34:57 acer.greshko.com systemd[1]: Failed to start System Upgrade using DNF.
Where to find more detailed info?
On Thu, 2019-10-17 at 07:52 +0800, Ed Greshko wrote:
This is the first time I've had issues with an upgrade.
Laptop is a fully updated F30 system running only KDE desktop. It is an older Acer Aspire 5920.
The package are downloaded and upon "system-upgrade reboot" the system does reboot and a screen saying "updates being installed, don't turn off". After a few minutes the system reboots again but into a normal F30 state.
dnf system-upgrade log --number=-1
Oct 17 07:34:57 acer.greshko.com systemd[1]: dnf-system-upgrade.service: Failed with result 'exit-code'. Oct 17 07:34:57 acer.greshko.com systemd[1]: Failed to start System Upgrade using DNF.
Where to find more detailed info?
journalctl -b-1 and /var/log/dnf.log are a couple of places to start.
On 10/17/19 2:13 PM, Adam Williamson wrote:
On Thu, 2019-10-17 at 07:52 +0800, Ed Greshko wrote:
This is the first time I've had issues with an upgrade.
Laptop is a fully updated F30 system running only KDE desktop. It is an older Acer Aspire 5920.
The package are downloaded and upon "system-upgrade reboot" the system does reboot and a screen saying "updates being installed, don't turn off". After a few minutes the system reboots again but into a normal F30 state.
dnf system-upgrade log --number=-1
Oct 17 07:34:57 acer.greshko.com systemd[1]: dnf-system-upgrade.service: Failed with result 'exit-code'. Oct 17 07:34:57 acer.greshko.com systemd[1]: Failed to start System Upgrade using DNF.
Where to find more detailed info?
journalctl -b-1 and /var/log/dnf.log are a couple of places to start.
Thanks.... Thrown a bit since dnf.log times are Z tagged.
The issue seems to be related to....
2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-desktop-5.16.5-1.fc31.x86_64.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-desktop-5.16.5-1.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-integration-5.16.5-2.fc31.x86_64.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-integration-5.16.5-2.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-lookandfeel-fedora-5.16.5-1.fc31.noarch.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-lookandfeel-fedora-5.16.5-1.fc31.noarch" from repository "fedora" has incorrect checksum 2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-workspace-5.16.5-1.fc31.x86_64.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-workspace-5.16.5-1.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-workspace-wayland-5.16.5-1.fc31.x86_64.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-workspace-wayland-5.16.5-1.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-16T23:34:53Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/sddm-breeze-5.16.5-1.fc31.noarch.rpm 2019-10-16T23:34:53Z CRITICAL Package "sddm-breeze-5.16.5-1.fc31.noarch" from repository "fedora" has incorrect checksum
Will try clean-up and try again
On 10/17/19 5:15 PM, Ed Greshko wrote:
Thanks.... Thrown a bit since dnf.log times are Z tagged.
The issue seems to be related to....
2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-desktop-5.16.5-1.fc31.x86_64.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-desktop-5.16.5-1.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-integration-5.16.5-2.fc31.x86_64.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-integration-5.16.5-2.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-lookandfeel-fedora-5.16.5-1.fc31.noarch.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-lookandfeel-fedora-5.16.5-1.fc31.noarch" from repository "fedora" has incorrect checksum 2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-workspace-5.16.5-1.fc31.x86_64.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-workspace-5.16.5-1.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-workspace-wayland-5.16.5-1.fc31.x86_64.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-workspace-wayland-5.16.5-1.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-16T23:34:53Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/sddm-breeze-5.16.5-1.fc31.noarch.rpm 2019-10-16T23:34:53Z CRITICAL Package "sddm-breeze-5.16.5-1.fc31.noarch" from repository "fedora" has incorrect checksum
Will try clean-up and try again
No, same issue.
FWIW, I'm using
dnf --skip-broken --allowerasing system-upgrade download --releasever=31
I suppose it is possible I'm hitting a bad mirror?
On 10/17/19 5:58 PM, Ed Greshko wrote:
On 10/17/19 5:15 PM, Ed Greshko wrote:
Thanks.... Thrown a bit since dnf.log times are Z tagged.
The issue seems to be related to....
2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-desktop-5.16.5-1.fc31.x86_64.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-desktop-5.16.5-1.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-integration-5.16.5-2.fc31.x86_64.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-integration-5.16.5-2.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-lookandfeel-fedora-5.16.5-1.fc31.noarch.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-lookandfeel-fedora-5.16.5-1.fc31.noarch" from repository "fedora" has incorrect checksum 2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-workspace-5.16.5-1.fc31.x86_64.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-workspace-5.16.5-1.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-workspace-wayland-5.16.5-1.fc31.x86_64.rpm 2019-10-16T23:34:50Z CRITICAL Package "plasma-workspace-wayland-5.16.5-1.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-16T23:34:53Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/sddm-breeze-5.16.5-1.fc31.noarch.rpm 2019-10-16T23:34:53Z CRITICAL Package "sddm-breeze-5.16.5-1.fc31.noarch" from repository "fedora" has incorrect checksum
Will try clean-up and try again
No, same issue.
FWIW, I'm using
dnf --skip-broken --allowerasing system-upgrade download --releasever=31
I suppose it is possible I'm hitting a bad mirror?
Well, it seems, adding --allowerasing is a bad idea since none of the packages referenced above are actually getting downloaded.
dnf --skip-broken system-upgrade download --releasever=31
isn't any better as it results in
Error: Problem 1: package dnf-yum-4.2.11-2.fc30.noarch requires dnf = 4.2.11-2.fc30, but none of the providers can be installed - dnf-4.2.11-2.fc30.noarch does not belong to a distupgrade repository - problem with installed package dnf-yum-4.2.11-2.fc30.noarch Problem 2: problem with installed package kf5-ktexteditor-5.59.0-1.fc30.x86_64 - package kf5-ktexteditor-5.61.0-1.fc31.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed - kf5-ktexteditor-5.59.0-1.fc30.x86_64 does not belong to a distupgrade repository - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded - package libgit2-0.28.3-1.fc31.x86_64 is excluded
I suppose waiting may be in order
Ed Greshko composed on 2019-10-17 17:58 (UTC+0800):
FWIW, I'm using
dnf --skip-broken --allowerasing system-upgrade download --releasever=31
I suppose it is possible I'm hitting a bad mirror?
This may be the same problem my last few tries to upgrade. I removed kde*, kf5* and plasm*, upgraded, then reinstalled KDE after the upgrade.
On 10/17/19 2:15 AM, Ed Greshko wrote:
The issue seems to be related to....
2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-desktop-5.16.5-1.fc31.x86_64.rpm
There was a recent discussion about this issue and a bug filed, but I don't have the number off-hand. The problem is that when --allow-erasing is used, there is a possibility for dnf to build a slightly different transaction after reboot than it did before. This means that it can't find the rpms that it thinks it should install.
On Thu, 2019-10-17 at 10:17 -0700, Samuel Sieb wrote:
On 10/17/19 2:15 AM, Ed Greshko wrote:
The issue seems to be related to....
2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-desktop-5.16.5-1.fc31.x86_64.rpm
There was a recent discussion about this issue and a bug filed, but I don't have the number off-hand. The problem is that when --allow-erasing is used, there is a possibility for dnf to build a slightly different transaction after reboot than it did before. This means that it can't find the rpms that it thinks it should install.
Yeah, it is a bug I investigated and fixed last week:
https://bugzilla.redhat.com/show_bug.cgi?id=1758588
if you use the updated upgrade plugin from updates-testing the problem would be fixed. ****HOWEVER****, using --allowerasing may not actually be what you want to do. The problem may ultimately be caused by the libgit2 module mess:
https://bugzilla.redhat.com/show_bug.cgi?id=1747408
in which case what you should do (AIUI) is run 'dnf module reset libgit2' and then try the system-upgrade download step again, without --allowerasing: it should hopefully work, and not remove any of your packages.
On 10/18/19 4:41 AM, Adam Williamson wrote:
On Thu, 2019-10-17 at 10:17 -0700, Samuel Sieb wrote:
On 10/17/19 2:15 AM, Ed Greshko wrote:
The issue seems to be related to....
2019-10-16T23:34:50Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-desktop-5.16.5-1.fc31.x86_64.rpm
There was a recent discussion about this issue and a bug filed, but I don't have the number off-hand. The problem is that when --allow-erasing is used, there is a possibility for dnf to build a slightly different transaction after reboot than it did before. This means that it can't find the rpms that it thinks it should install.
Yeah, it is a bug I investigated and fixed last week:
https://bugzilla.redhat.com/show_bug.cgi?id=1758588
if you use the updated upgrade plugin from updates-testing the problem would be fixed. ****HOWEVER****, using --allowerasing may not actually be what you want to do. The problem may ultimately be caused by the libgit2 module mess:
https://bugzilla.redhat.com/show_bug.cgi?id=1747408
in which case what you should do (AIUI) is run 'dnf module reset libgit2' and then try the system-upgrade download step again, without --allowerasing: it should hopefully work, and not remove any of your packages.
Almost there.... But the problem may not be a "fedora" problem?
2019-10-17T23:09:44Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/rpmfusion-free-058b175644bc1430/packages/rpmfusion-free-appstream-data-30-1.20181021.fc30.noarch.rpm 2019-10-17T23:09:44Z CRITICAL Package "rpmfusion-free-appstream-data-30-1.20181021.fc30.noarch" from repository "rpmfusion-free" has incorrect checksum 2019-10-17T23:09:44Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/rpmfusion-nonfree-c253272f7b309f17/packages/rpmfusion-nonfree-appstream-data-30-1.20181021.fc30.noarch.rpm 2019-10-17T23:09:44Z CRITICAL Package "rpmfusion-nonfree-appstream-data-30-1.20181021.fc30.noarch" from repository "rpmfusion-nonfree" has incorrect checksum 2019-10-17T23:10:11Z DDEBUG Cleaning up.
Those referenced files do not exist.
On 10/17/19 4:16 PM, Ed Greshko wrote:
Almost there.... But the problem may not be a "fedora" problem?
2019-10-17T23:09:44Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/rpmfusion-free-058b175644bc1430/packages/rpmfusion-free-appstream-data-30-1.20181021.fc30.noarch.rpm
2019-10-17T23:09:44Z CRITICAL Package "rpmfusion-free-appstream-data-30-1.20181021.fc30.noarch" from repository "rpmfusion-free" has incorrect checksum 2019-10-17T23:09:44Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/rpmfusion-nonfree-c253272f7b309f17/packages/rpmfusion-nonfree-appstream-data-30-1.20181021.fc30.noarch.rpm
2019-10-17T23:09:44Z CRITICAL Package "rpmfusion-nonfree-appstream-data-30-1.20181021.fc30.noarch" from repository "rpmfusion-nonfree" has incorrect checksum 2019-10-17T23:10:11Z DDEBUG Cleaning up.
Those referenced files do not exist.
That is the symptom of the problem. Did you get the updated plugin? One thing I wondered is what would happen if you manually added the "missing" rpms to the cache directory after the regular download process was complete. It should work.
One very odd thing here though is that it's looking for fc30 packages. Maybe there is an rpmfusion problem as well since there is no appstream data past 30 yet.
On 10/18/19 7:49 AM, Samuel Sieb wrote:
On 10/17/19 4:16 PM, Ed Greshko wrote:
Almost there.... But the problem may not be a "fedora" problem?
2019-10-17T23:09:44Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/rpmfusion-free-058b175644bc1430/packages/rpmfusion-free-appstream-data-30-1.20181021.fc30.noarch.rpm 2019-10-17T23:09:44Z CRITICAL Package "rpmfusion-free-appstream-data-30-1.20181021.fc30.noarch" from repository "rpmfusion-free" has incorrect checksum 2019-10-17T23:09:44Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/rpmfusion-nonfree-c253272f7b309f17/packages/rpmfusion-nonfree-appstream-data-30-1.20181021.fc30.noarch.rpm 2019-10-17T23:09:44Z CRITICAL Package "rpmfusion-nonfree-appstream-data-30-1.20181021.fc30.noarch" from repository "rpmfusion-nonfree" has incorrect checksum 2019-10-17T23:10:11Z DDEBUG Cleaning up.
Those referenced files do not exist.
That is the symptom of the problem. Did you get the updated plugin? One thing I wondered is what would happen if you manually added the "missing" rpms to the cache directory after the regular download process was complete. It should work.
Yes. Got that and did the module reset.
python3-dnf-plugin-system-upgrade-4.0.7-1.fc30.noarch
One very odd thing here though is that it's looking for fc30 packages. Maybe there is an rpmfusion problem as well since there is no appstream data past 30 yet.
Yes, that oddity has me questioning where the problem lies.
On 10/17/19 5:08 PM, Ed Greshko wrote:
On 10/18/19 7:49 AM, Samuel Sieb wrote:
That is the symptom of the problem. Did you get the updated plugin? One thing I wondered is what would happen if you manually added the "missing" rpms to the cache directory after the regular download process was complete. It should work.
Yes. Got that and did the module reset.
python3-dnf-plugin-system-upgrade-4.0.7-1.fc30.noarch
Adam, is that the right version? It is the latest build. If so, it wasn't a complete fix. If there's a problem, it should be detected during the download process. Somehow it's still coming up with a different transaction after reboot.
On Thu, 2019-10-17 at 18:12 -0700, Samuel Sieb wrote:
On 10/17/19 5:08 PM, Ed Greshko wrote:
On 10/18/19 7:49 AM, Samuel Sieb wrote:
That is the symptom of the problem. Did you get the updated plugin? One thing I wondered is what would happen if you manually added the "missing" rpms to the cache directory after the regular download process was complete. It should work.
Yes. Got that and did the module reset.
python3-dnf-plugin-system-upgrade-4.0.7-1.fc30.noarch
Adam, is that the right version? It is the latest build. If so, it wasn't a complete fix. If there's a problem, it should be detected during the download process. Somehow it's still coming up with a different transaction after reboot.
I might need more logs from your case to be sure of what's going on - if you could put the dnf logs and system journals up somewhere it'd help. Also, did you re-run the download phase after updating the system-upgrade plugin? You do need to do that...
The change I put in last week fixes the case I diagnosed, but I mean it's still possible there's some other case where the transactions come up different for sure. Will need data to figure it out though.
On 10/18/19 2:05 PM, Adam Williamson wrote:
I might need more logs from your case to be sure of what's going on - if you could put the dnf logs and system journals up somewhere it'd help. Also, did you re-run the download phase after updating the system-upgrade plugin? You do need to do that...
Yes, I ran "dnf system-upgrade clean" as well as "dnf clean packages" for good measure.
The change I put in last week fixes the case I diagnosed, but I mean it's still possible there's some other case where the transactions come up different for sure. Will need data to figure it out though.
OK....
journal is at https://drive.google.com/open?id=1qCUyZcC5-QjE83uh9p5wC10tIai1PCO2 dnf log is at https://drive.google.com/file/d/1K17NzRLf8e945kQ1gHKdlFqi2v87IpQb/view?usp=s...
On 10/18/19 2:31 PM, Ed Greshko wrote:
On 10/18/19 2:05 PM, Adam Williamson wrote:
I might need more logs from your case to be sure of what's going on - if you could put the dnf logs and system journals up somewhere it'd help. Also, did you re-run the download phase after updating the system-upgrade plugin? You do need to do that...
Yes, I ran "dnf system-upgrade clean" as well as "dnf clean packages" for good measure.
The change I put in last week fixes the case I diagnosed, but I mean it's still possible there's some other case where the transactions come up different for sure. Will need data to figure it out though.
OK....
journal is at https://drive.google.com/open?id=1qCUyZcC5-QjE83uh9p5wC10tIai1PCO2 dnf log is at https://drive.google.com/file/d/1K17NzRLf8e945kQ1gHKdlFqi2v87IpQb/view?usp=s...
And for the record I have added to https://bugzilla.redhat.com/show_bug.cgi?id=1758588
On Sun, 2019-10-20 at 06:56 +0800, Ed Greshko wrote:
On 10/18/19 2:31 PM, Ed Greshko wrote:
On 10/18/19 2:05 PM, Adam Williamson wrote:
I might need more logs from your case to be sure of what's going on - if you could put the dnf logs and system journals up somewhere it'd help. Also, did you re-run the download phase after updating the system-upgrade plugin? You do need to do that...
Yes, I ran "dnf system-upgrade clean" as well as "dnf clean packages" for good measure.
The change I put in last week fixes the case I diagnosed, but I mean it's still possible there's some other case where the transactions come up different for sure. Will need data to figure it out though.
OK....
journal is at https://drive.google.com/open?id=1qCUyZcC5-QjE83uh9p5wC10tIai1PCO2 dnf log is at https://drive.google.com/file/d/1K17NzRLf8e945kQ1gHKdlFqi2v87IpQb/view?usp=s...
And for the record I have added to https://bugzilla.redhat.com/show_bug.cgi?id=1758588
Sorry Ed, got sidelined by other stuff. But I need the dnf log from the download transaction as well, to compare the two. Can you find that one too? Thanks!
On 10/20/19 10:59 PM, Adam Williamson wrote:
On Sun, 2019-10-20 at 06:56 +0800, Ed Greshko wrote:
On 10/18/19 2:31 PM, Ed Greshko wrote:
On 10/18/19 2:05 PM, Adam Williamson wrote:
I might need more logs from your case to be sure of what's going on - if you could put the dnf logs and system journals up somewhere it'd help. Also, did you re-run the download phase after updating the system-upgrade plugin? You do need to do that...
Yes, I ran "dnf system-upgrade clean" as well as "dnf clean packages" for good measure.
The change I put in last week fixes the case I diagnosed, but I mean it's still possible there's some other case where the transactions come up different for sure. Will need data to figure it out though.
OK....
journal is at https://drive.google.com/open?id=1qCUyZcC5-QjE83uh9p5wC10tIai1PCO2 dnf log is at https://drive.google.com/file/d/1K17NzRLf8e945kQ1gHKdlFqi2v87IpQb/view?usp=s...
And for the record I have added to https://bugzilla.redhat.com/show_bug.cgi?id=1758588
Sorry Ed, got sidelined by other stuff. But I need the dnf log from the download transaction as well, to compare the two. Can you find that one too? Thanks!
OK....
I have redone the upgrade and added the logs to the bugzilla.
On 10/20/19 10:59 PM, Adam Williamson wrote:
On Sun, 2019-10-20 at 06:56 +0800, Ed Greshko wrote:
On 10/18/19 2:31 PM, Ed Greshko wrote:
On 10/18/19 2:05 PM, Adam Williamson wrote:
I might need more logs from your case to be sure of what's going on - if you could put the dnf logs and system journals up somewhere it'd help. Also, did you re-run the download phase after updating the system-upgrade plugin? You do need to do that...
Yes, I ran "dnf system-upgrade clean" as well as "dnf clean packages" for good measure.
The change I put in last week fixes the case I diagnosed, but I mean it's still possible there's some other case where the transactions come up different for sure. Will need data to figure it out though.
OK....
journal is at https://drive.google.com/open?id=1qCUyZcC5-QjE83uh9p5wC10tIai1PCO2 dnf log is at https://drive.google.com/file/d/1K17NzRLf8e945kQ1gHKdlFqi2v87IpQb/view?usp=s...
And for the record I have added to https://bugzilla.redhat.com/show_bug.cgi?id=1758588
Sorry Ed, got sidelined by other stuff. But I need the dnf log from the download transaction as well, to compare the two. Can you find that one too? Thanks!
As you know, I did supply the requested logs in the BZ.
The issue I reported seems either not to have been considered or is irrelevant to 178588.
So, I think others may encounter the same issue. Should a new BZ be created? Or, will there be an advisory to erase the offending packages and manually reinstall after the upgrade completes?
On Sat, 2019-10-26 at 08:15 +0800, Ed Greshko wrote:
On 10/20/19 10:59 PM, Adam Williamson wrote:
On Sun, 2019-10-20 at 06:56 +0800, Ed Greshko wrote:
On 10/18/19 2:31 PM, Ed Greshko wrote:
On 10/18/19 2:05 PM, Adam Williamson wrote:
I might need more logs from your case to be sure of what's going on - if you could put the dnf logs and system journals up somewhere it'd help. Also, did you re-run the download phase after updating the system-upgrade plugin? You do need to do that...
Yes, I ran "dnf system-upgrade clean" as well as "dnf clean packages" for good measure.
The change I put in last week fixes the case I diagnosed, but I mean it's still possible there's some other case where the transactions come up different for sure. Will need data to figure it out though.
OK....
journal is at https://drive.google.com/open?id=1qCUyZcC5-QjE83uh9p5wC10tIai1PCO2 dnf log is at https://drive.google.com/file/d/1K17NzRLf8e945kQ1gHKdlFqi2v87IpQb/view?usp=s...
And for the record I have added to https://bugzilla.redhat.com/show_bug.cgi?id=1758588
Sorry Ed, got sidelined by other stuff. But I need the dnf log from the download transaction as well, to compare the two. Can you find that one too? Thanks!
As you know, I did supply the requested logs in the BZ.
The issue I reported seems either not to have been considered or is irrelevant to 178588.
It's definitely not the *same* as that bug, because it involves a package that the download transaction omits but the upgrade transaction decides to 'reinstall'. To figure it out we'd need to figure out why the update transaction decides that package needs to be reinstalled, I guess, but I did not have time to do that last week; f31 blockers took higher priority.
So, I think others may encounter the same issue. Should a new BZ be created? Or, will there be an advisory to erase the offending packages and manually reinstall after the upgrade completes?
Filing a new bug wouldn't hurt, for sure. Thanks. Probably against dnf- plugins-extras .
On 10/27/19 1:26 AM, Adam Williamson wrote:
Filing a new bug wouldn't hurt, for sure. Thanks. Probably against dnf- plugins-extras .
Apparently it has already been done.
https://bugzilla.redhat.com/show_bug.cgi?id=1764169
On 10/18/19 7:49 AM, Samuel Sieb wrote:
One very odd thing here though is that it's looking for fc30 packages. Maybe there is an rpmfusion problem as well since there is no appstream data past 30 yet.
Oh, BTW, it is in the 31 repo of rpmfusion it is just not updated in name....
[root@f31bg ~]# cat /etc/fedora-release Fedora release 31 (Thirty One)
[root@f31bg ~]# rpm -q rpmfusion-nonfree-appstream-data rpmfusion-free-appstream-data rpmfusion-nonfree-appstream-data-30-1.20181021.fc30.noarch rpmfusion-free-appstream-data-30-1.20181021.fc30.noarch