I have a laptop (Lenovo W540) running Fedora 30. I have preped it for upgrade using dnf.
I get to the reboot step is where it gets interesting.
I reboot and enter the drive password. It goes into the install, says it is preparing and then before it installs anything, it reboots.
Any idea what log to check to figure out why? It passed all the transaction tests.
On Wed, Oct 2, 2019 at 3:02 PM Alan alan@clueserver.org wrote:
I have a laptop (Lenovo W540) running Fedora 30. I have preped it for upgrade using dnf.
I get to the reboot step is where it gets interesting.
I reboot and enter the drive password. It goes into the install, says it is preparing and then before it installs anything, it reboots.
Any idea what log to check to figure out why? It passed all the transaction tests.
Logging goes to the journal. So you'll find it with 'journalctl -b -1' assuming the (failed) update boot is the immediately prior boot. Can you confirm you've done
# dnf system-upgrade download --releasever=31 # dnf system-upgrade reboot
On Wed, 2019-10-02 at 15:23 -0600, Chris Murphy wrote:
On Wed, Oct 2, 2019 at 3:02 PM Alan alan@clueserver.org wrote:
I have a laptop (Lenovo W540) running Fedora 30. I have preped it for upgrade using dnf.
I get to the reboot step is where it gets interesting.
I reboot and enter the drive password. It goes into the install, says it is preparing and then before it installs anything, it reboots.
Any idea what log to check to figure out why? It passed all the transaction tests.
Logging goes to the journal. So you'll find it with 'journalctl -b -1' assuming the (failed) update boot is the immediately prior boot. Can you confirm you've done
# dnf system-upgrade download --releasever=31 # dnf system-upgrade reboot
Yes. I also had --allowerasing.
This is interesting... I am going to do a heavy clean of the packages and try again.
Oct 02 11:22:23 daimajin dnf[1390]: Transaction Summary Oct 02 11:22:23 daimajin dnf[1390]: ======================================================================= ========= Oct 02 11:22:23 daimajin dnf[1390]: Install 144 Packages Oct 02 11:22:23 daimajin dnf[1390]: Upgrade 4828 Packages Oct 02 11:22:23 daimajin dnf[1390]: Remove 12 Packages Oct 02 11:22:23 daimajin dnf[1390]: Downgrade 9 Packages Oct 02 11:22:23 daimajin dnf[1390]: Skip 3 Packages Oct 02 11:22:27 daimajin systemd[1]: systemd-hostnamed.service: Succeeded. Oct 02 11:22:27 daimajin kernel: audit: type=1131 audit(1570040547.732:91): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnam> Oct 02 11:22:27 daimajin audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/> Oct 02 11:23:01 daimajin dnf[1390]: Total size: 9.4 G Oct 02 11:23:01 daimajin dnf[1390]: Total download size: 19 M Oct 02 11:23:01 daimajin dnf[1390]: Downloading Packages: Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma- desktop-5.16.4-1.fc31.x86_64.rpm Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-5.16.4- 1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma- desktop-kimpanel-scim-5.16.4-1.fc31.x86_> Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-kimpanel- scim-5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma- integration-5.16.4-1.fc31.x86_64.rpm Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-integration-5.16.4- 1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma- lookandfeel-fedora-5.16.4-1.fc31.noarch.> Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-lookandfeel-fedora- 5.16.4-1.fc31.noarch" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma- workspace-5.16.4-1.fc31.x86_64.rpm Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-workspace-5.16.4- 1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma- workspace-wayland-5.16.4-1.fc31.x86_64.r> Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-workspace-wayland- 5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:20 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/sddm- breeze-5.16.4-1.fc31.noarch.rpm Oct 02 11:23:20 daimajin dnf[1390]: Package "sddm-breeze-5.16.4- 1.fc31.noarch" from repository "fedora" has incorrect checksum Oct 02 11:23:24 daimajin dnf[1390]: Error: Some packages have invalid cache, but cannot be downloaded due to "--cacheonly" option Oct 02 11:23:24 daimajin systemd[1]: dnf-system-upgrade.service: Main process exited, code=exited, status=1/FAILURE Oct 02 11:23:24 daimajin systemd[1]: dnf-system-upgrade.service: Failed with result 'exit-code'. Oct 02 11:23:24 daimajin systemd[1]: Failed to start System Upgrade using DNF.
On 10/2/19 2:31 PM, Alan wrote:
Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma- desktop-5.16.4-1.fc31.x86_64.rpm Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-5.16.4- 1.fc31.x86_64" from repository "fedora" has incorrect checksum
That's weird, can you check if those files actually exist?
On Wed, 2019-10-02 at 14:34 -0700, Samuel Sieb wrote:
On 10/2/19 2:31 PM, Alan wrote:
Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora- 3589ee8a7ee1691d/packages/plasma- desktop-5.16.4-1.fc31.x86_64.rpm Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-5.16.4- 1.fc31.x86_64" from repository "fedora" has incorrect checksum
That's weird, can you check if those files actually exist?
They don't!
I reran it after clearing all the packages and upgrade packages and data and reran it and got the same results. It passes all the transaction tests. Everything claims to be OK for the upgrade, but those files don't exists for some unknown reason.
Could it be some corruption in the rpm database?
Bugzilla Bug 1644439 looks identical, but was not investigated further as it seems the issue did not appear anymore and dnf has changed since reported.
This is what I have found so far.
dnf system-upgrade -v reboot fails with the following errors:
2019-10-03T11:28:47Z INFO Downloading Packages: 2019-10-03T11:28:51Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/updates-testing-9640951d8a5b54c9/packages/plasma-integration-5.16.5 -2.fc31.x86_64.rpm 2019-10-03T11:28:51Z CRITICAL Package "plasma-integration-5.16.5-2.fc31.x86_64" from repository "updates-testing" has incorrect checksum 2019-10-03T11:28:53Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/LabPlot-2.5.0-5.fc31.x86_64.rpm 2019-10-03T11:28:53Z CRITICAL Package "LabPlot-2.5.0-5.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-03T11:28:54Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/cantor-19.04.3-2.fc31.x86_64.rpm 2019-10-03T11:28:54Z CRITICAL Package "cantor-19.04.3-2.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-03T11:28:54Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/cantor-libs-19.04.3-2.fc31.x86_64. rpm 2019-10-03T11:28:54Z CRITICAL Package "cantor-libs-19.04.3-2.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-03T11:29:01Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-desktop-5.16.4-1.fc31.x86_6 4.rpm 2019-10-03T11:29:01Z CRITICAL Package "plasma-desktop-5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-03T11:29:01Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-lookandfeel-fedora-5.16.4-1 .fc31.noarch.rpm 2019-10-03T11:29:01Z CRITICAL Package "plasma-lookandfeel-fedora-5.16.4-1.fc31.noarch" from repository "fedora" has incorrect checksum 2019-10-03T11:29:01Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-workspace-5.16.4-1.fc31.x86 _64.rpm 2019-10-03T11:29:01Z CRITICAL Package "plasma-workspace-5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-03T11:29:01Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/sddm-breeze-5.16.4-1.fc31.noarch.rpm 2019-10-03T11:29:01Z CRITICAL Package "sddm-breeze-5.16.4-1.fc31.noarch" from repository "fedora" has incorrect checksum 2019-10-03T11:29:03Z DDEBUG Cleaning up. 2019-10-03T11:29:03Z SUBDEBUG Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 65, in main return _main(base, args, cli_class, option_parser_class) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 98, in _main return cli_run(cli, base) 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 166, in resolving base.do_transaction(display=displays) File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 224, in do_transaction self.download_packages(install_pkgs, self.output.progress, total_cb) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 1133, in download_packages remote_pkgs, local_repository_pkgs = self._select_remote_pkgs(pkglist) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 2474, in _select_remote_pkgs _('Some packages have invalid cache, but cannot be downloaded due to ' dnf.exceptions.Error: Some packages have invalid cache, but cannot be downloaded due to "--cacheonly" option 2019-10-03T11:29:03Z CRITICAL Error: Some packages have invalid cache, but cannot be downloaded due to "--cacheonly" option
As someone already suspected, the rpms were not downloaded and therefore produces the above error.
They are not downloaded because dnf system-upgrade download --refresh --allowerasing --releasever=31 does not list them as to be installed.
It only lists older versions to be removed:
Removing dependent packages: .... plasma-desktop 5.15.5-1.fc30 sddm-breeze 5.15.5-1.fc30 plasma-workspace 5.15.5-1.fc30 plasma-lookandfeel-fedora 5.15.5-1.fc30 cantor-libs 18.12.3-1.fc30 cantor 18.12.3-1.fc30 LibPlot 2.5.0-3.fc30 .....
But no new versions to be installed.
So there seems to be a mismatch between what dependencies --download resolves and what gets resolved after system-upgrade reboot.
Also interesting that Alan's failed packages are almost the same as mine. So may be it is related to some wrongly defined dependencies for them.
Before I dive deeper into what system-upgrade is exactly doing, is there a hint where to check next?
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, 3. October 2019 19:04, Alan alan@clueserver.org wrote:
On Wed, 2019-10-02 at 14:34 -0700, Samuel Sieb wrote:
On 10/2/19 2:31 PM, Alan wrote:
Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora- 3589ee8a7ee1691d/packages/plasma- desktop-5.16.4-1.fc31.x86_64.rpm Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-5.16.4- 1.fc31.x86_64" from repository "fedora" has incorrect checksum
That's weird, can you check if those files actually exist?
They don't!
I reran it after clearing all the packages and upgrade packages and data and reran it and got the same results. It passes all the transaction tests. Everything claims to be OK for the upgrade, but those files don't exists for some unknown reason.
Could it be some corruption in the rpm database?
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
In system-upgrade.pv there is a note in the run_upgrade function:
# NOTE: We *assume* that depsolving here will yield the same # transaction as it did during the download, but we aren't doing # anything to *ensure* that; if the metadata changed, or if depsolving # is non-deterministic in some way, we could end up with a different # transaction and then the upgrade will fail due to missing packages. # # One way to *guarantee* that we have the same transaction would be # to save & restore the Transaction object, but there's no documented # way to save a Transaction to disk. # # So far, though, the above assumption seems to hold. So... onward!
So it seems Alan and myself have got some rare dependency condition.
Still need to find out what exactly triggers it and how to solve it.
Will open a bug tomorrow, if nobody beats me to it.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, 3. October 2019 19:07, Rodger Etz reb@brownsen.net wrote:
Bugzilla Bug 1644439 looks identical, but was not investigated further as it seems the issue did not appear anymore and dnf has changed since reported.
This is what I have found so far.
dnf system-upgrade -v reboot fails with the following errors:
2019-10-03T11:28:47Z INFO Downloading Packages: 2019-10-03T11:28:51Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/updates-testing-9640951d8a5b54c9/packages/plasma-integration-5.16.5 -2.fc31.x86_64.rpm 2019-10-03T11:28:51Z CRITICAL Package "plasma-integration-5.16.5-2.fc31.x86_64" from repository "updates-testing" has incorrect checksum 2019-10-03T11:28:53Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/LabPlot-2.5.0-5.fc31.x86_64.rpm 2019-10-03T11:28:53Z CRITICAL Package "LabPlot-2.5.0-5.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-03T11:28:54Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/cantor-19.04.3-2.fc31.x86_64.rpm 2019-10-03T11:28:54Z CRITICAL Package "cantor-19.04.3-2.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-03T11:28:54Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/cantor-libs-19.04.3-2.fc31.x86_64. rpm 2019-10-03T11:28:54Z CRITICAL Package "cantor-libs-19.04.3-2.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-03T11:29:01Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-desktop-5.16.4-1.fc31.x86_6 4.rpm 2019-10-03T11:29:01Z CRITICAL Package "plasma-desktop-5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-03T11:29:01Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-lookandfeel-fedora-5.16.4-1 .fc31.noarch.rpm 2019-10-03T11:29:01Z CRITICAL Package "plasma-lookandfeel-fedora-5.16.4-1.fc31.noarch" from repository "fedora" has incorrect checksum 2019-10-03T11:29:01Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma-workspace-5.16.4-1.fc31.x86 _64.rpm 2019-10-03T11:29:01Z CRITICAL Package "plasma-workspace-5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect checksum 2019-10-03T11:29:01Z CRITICAL Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/sddm-breeze-5.16.4-1.fc31.noarch.rpm 2019-10-03T11:29:01Z CRITICAL Package "sddm-breeze-5.16.4-1.fc31.noarch" from repository "fedora" has incorrect checksum 2019-10-03T11:29:03Z DDEBUG Cleaning up. 2019-10-03T11:29:03Z SUBDEBUG Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 65, in main return _main(base, args, cli_class, option_parser_class) File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 98, in _main return cli_run(cli, base) 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 166, in resolving base.do_transaction(display=displays) File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 224, in do_transaction self.download_packages(install_pkgs, self.output.progress, total_cb) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 1133, in download_packages remote_pkgs, local_repository_pkgs = self._select_remote_pkgs(pkglist) File "/usr/lib/python3.7/site-packages/dnf/base.py", line 2474, in _select_remote_pkgs _('Some packages have invalid cache, but cannot be downloaded due to ' dnf.exceptions.Error: Some packages have invalid cache, but cannot be downloaded due to "--cacheonly" option 2019-10-03T11:29:03Z CRITICAL Error: Some packages have invalid cache, but cannot be downloaded due to "--cacheonly" option
As someone already suspected, the rpms were not downloaded and therefore produces the above error.
They are not downloaded because dnf system-upgrade download --refresh --allowerasing --releasever=31 does not list them as to be installed.
It only lists older versions to be removed:
Removing dependent packages: .... plasma-desktop 5.15.5-1.fc30 sddm-breeze 5.15.5-1.fc30 plasma-workspace 5.15.5-1.fc30 plasma-lookandfeel-fedora 5.15.5-1.fc30 cantor-libs 18.12.3-1.fc30 cantor 18.12.3-1.fc30 LibPlot 2.5.0-3.fc30 .....
But no new versions to be installed.
So there seems to be a mismatch between what dependencies --download resolves and what gets resolved after system-upgrade reboot.
Also interesting that Alan's failed packages are almost the same as mine. So may be it is related to some wrongly defined dependencies for them.
Before I dive deeper into what system-upgrade is exactly doing, is there a hint where to check next?
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, 3. October 2019 19:04, Alan alan@clueserver.org wrote:
On Wed, 2019-10-02 at 14:34 -0700, Samuel Sieb wrote:
On 10/2/19 2:31 PM, Alan wrote:
Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora- 3589ee8a7ee1691d/packages/plasma- desktop-5.16.4-1.fc31.x86_64.rpm Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-5.16.4- 1.fc31.x86_64" from repository "fedora" has incorrect checksum
That's weird, can you check if those files actually exist?
They don't! I reran it after clearing all the packages and upgrade packages and data and reran it and got the same results. It passes all the transaction tests. Everything claims to be OK for the upgrade, but those files don't exists for some unknown reason. Could it be some corruption in the rpm database? test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Rodger Etz composed on 2019-10-03 19:11 (UTC):
So it seems Alan and myself have got some rare dependency condition.
Still need to find out what exactly triggers it and how to solve it.
Will open a bug tomorrow, if nobody beats me to it.
Likely you can work around the problem via exclude= in dnf.conf for the checksum problem packages to get upgraded to f31, and deal with those skipped packages later.
Tried that, but it leads to dependency probs that cannot be solved by --allowerasing or --skip-broken.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, 3. October 2019 21:45, Felix Miata mrmazda@earthlink.net wrote:
Rodger Etz composed on 2019-10-03 19:11 (UTC):
So it seems Alan and myself have got some rare dependency condition.
Still need to find out what exactly triggers it and how to solve it.
Will open a bug tomorrow, if nobody beats me to it.
Likely you can work around the problem via exclude= in dnf.conf for the checksum problem packages to get upgraded to f31, and deal with those skipped packages later.
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Rodger Etz composed on 2019-10-03 20:15 (UTC):
Tried that, but it leads to dependency probs that cannot be solved by --allowerasing or --skip-broken.
Another thing I do when such problems arise is remove the offending packages, upgrade, then add them back afterward. Typically this means dnf remove kf5* kde* plasm* *breez*.
Yes, thanks.
As the pkgs are pretty fundamental I prefer to keep them. I had bad eyperiences in the past with this approach. Before I go through dependency hell, I'd rather quickly reinstall the whole box. And as it is just a system-upgrade test for me, it can wait. -------- Original-Nachricht -------- An 3. Okt. 2019, 22:35, Felix Miata schrieb:
Rodger Etz composed on 2019-10-03 20:15 (UTC):
Tried that, but it leads to dependency probs that cannot be solved by --allowerasing or --skip-broken.
Another thing I do when such problems arise is remove the offending packages, upgrade, then add them back afterward. Typically this means dnf remove kf5* kde* plasm* *breez*. -- Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #[211409](tel:211409) ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/ _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Yes, thanks.
As the pkgs are pretty fundamental I prefer to keep them. I had bad eyperiences in the past with this approach. Before I go through dependency hell, I'd rather quickly reinstall the whole box. And as it is just a system-upgrade test for me, it can wait.
It still needs to get fixed. A "normal" user would be VERY confused by this issue. Double-plus ungood.
-------- Original-Nachricht -------- An 3. Okt. 2019, 22:35, Felix Miata schrieb:
Rodger Etz composed on 2019-10-03 20:15 (UTC):
Tried that, but it leads to dependency probs that cannot be solved by --allowerasing or --skip-broken.
Another thing I do when such problems arise is remove the offending packages, upgrade, then add them back afterward. Typically this means dnf remove kf5* kde* plasm* *breez*. -- Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #[211409](tel:211409) ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/ _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org__...
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Q: Why do programmers confuse Halloween and Christmas? A: Because OCT 31 == DEC 25.
Does anyone know if --allow-erasing needs to be passed to both 'download' and 'reboot' subcommands for this to work correctly?
Or does the download subcommand track options and apply them in the rebooted offline/upgrade environment?
--- Chris Murphy
Anyone read python :P
https://github.com/rpm-software-management/dnf-plugins-extras/blob/master/pl...
lines 567 through 578 suggest that there is some kind of state saving, and allow erasing is one of them; so maybe the bug is that it's not actually saving state, and isn't actually getting used as it should in the upgrade environment?
--- Chris Murphy
Yes, basically, saving the state is not implemented yet for --reboot and would fix it.
And it should be fixed, I agree. Although the conditon seems very rare and existing for quite some time, system-upgrade should behave in a deterministic way.
-------- Original-Nachricht -------- An 4. Okt. 2019, 04:13, Chris Murphy schrieb:
Anyone read python :P
https://github.com/rpm-software-management/dnf-plugins-extras/blob/master/pl...
lines [567](tel:567) through [578](tel:578) suggest that there is some kind of state saving, and allow erasing is one of them; so maybe the bug is that it's not actually saving state, and isn't actually getting used as it should in the upgrade environment?
Chris Murphy _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
On 10/3/19 11:30 PM, Rodger Etz wrote:
Yes, basically, saving the state is not implemented yet for --reboot and would fix it.
And it should be fixed, I agree. Although the conditon seems very rare and existing for quite some time, system-upgrade should behave in a deterministic way.
You should file a bug on dnf in bugzilla. I wonder if it should be a blocker, but it's not clear what the conditions are that trigger it.
Filed against dnf as suggested: 1758588
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, 4. October 2019 09:31, Samuel Sieb samuel@sieb.net wrote:
On 10/3/19 11:30 PM, Rodger Etz wrote:
Yes, basically, saving the state is not implemented yet for --reboot and would fix it. And it should be fixed, I agree. Although the conditon seems very rare and existing for quite some time, system-upgrade should behave in a deterministic way.
You should file a bug on dnf in bugzilla. I wonder if it should be a blocker, but it's not clear what the conditions are that trigger it.
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
On Fri, 2019-10-04 at 00:31 -0700, Samuel Sieb wrote:
On 10/3/19 11:30 PM, Rodger Etz wrote:
Yes, basically, saving the state is not implemented yet for --reboot and would fix it.
And it should be fixed, I agree. Although the conditon seems very rare and existing for quite some time, system-upgrade should behave in a deterministic way.
You should file a bug on dnf in bugzilla. I wonder if it should be a blocker, but it's not clear what the conditions are that trigger it.
Yeah, so far we have a lot of discussion but not (AFAICS) a clear reproducer or a clear indication of exactly where the bug is. Please do file a bug, with as much context as you can, including all the logs and the exact commands you ran. Thanks!
I suggest trying --debugsolver with both the download and reboot subcommands. 'man dnf system-upgrade' suggests --debugsolver should work. I recommend taring the debugdata dir that will create, and setting the filename and attachment description so it's clear whether the tarball is for reboot or download.
The debugdata dir will be located in the current dir. So that'll be easy to find for the download command. But I have no idea where it'll be located for reboot so you'll probably have to use find.
Sometimes these are bigger than the 20MB attachment size, so you might have to stick it in a dropbox/googledrive like thing and post the URLs for them in the bug report.
--- Chris Murphy
Thanks, Chris! I did so, but reboot did not create a debugdata dir. Therefore I have uploaded the dnf logs.
From what I have seen so far, it still seems the best option to modify system-upgrade so it safes the transaction before reboot and reboot reruns it ... or something similar.
Trying to figure out what obscure dependency constellation this is causing, will be painful and most likely fail, because we do not have enough information and the state of dependencies changes so quickly, the issue might not occur after the next update of those packages. And even if we find this particular one, it might be there are others as well.
Is it worth it to start a discussion on devel@ ?
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, 4. October 2019 20:44, Chris Murphy lists@colorremedies.com wrote:
I suggest trying --debugsolver with both the download and reboot subcommands. 'man dnf system-upgrade' suggests --debugsolver should work. I recommend taring the debugdata dir that will create, and setting the filename and attachment description so it's clear whether the tarball is for reboot or download.
The debugdata dir will be located in the current dir. So that'll be easy to find for the download command. But I have no idea where it'll be located for reboot so you'll probably have to use find.
Sometimes these are bigger than the 20MB attachment size, so you might have to stick it in a dropbox/googledrive like thing and post the URLs for them in the bug report.
Chris Murphy
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
On Sat, Oct 5, 2019 at 7:37 AM Rodger Etz reb@brownsen.net wrote:
Thanks, Chris! I did so, but reboot did not create a debugdata dir. Therefore I have uploaded the dnf logs.
From what I have seen so far, it still seems the best option to modify system-upgrade so it safes the transaction before reboot and reboot reruns it ... or something similar.
Trying to figure out what obscure dependency constellation this is causing, will be painful and most likely fail, because we do not have enough information and the state of dependencies changes so quickly, the issue might not occur after the next update of those packages. And even if we find this particular one, it might be there are others as well.
Is it worth it to start a discussion on devel@ ?
Yes. The questions are, is it working as intended and is there a way to make it work better?
Also I'm curious if the behavior of 'dnf system-upgrade' differs from gnome-software/PackageKit method. I don't think this problem can be release blocking for two reasons: the Beta criterion for upgrades is narrowly written to exclude anything that makes it "not clean" and 3rd party stuff definitely isn't covered.
"For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed."
Further, a note for that says: "This criterion applies to the recommended upgrade mechanisms only."
And per: https://docs.fedoraproject.org/en-US/quick-docs/upgrading/
Only Gnome Software is "recommended" for Workstation. All other Fedora editions and variants, dnf is recommended. Practically I think we'd probably block on dnf system-upgrade bugs because chances are any breakage on Workstation will affect other Fedora products. But if it were true that a bug only affected Workstation and no other Fedora product; and also the bug didn't happen with Gnome Software, would we block? Hmmm. Entertaining.
On Sat, 2019-10-05 at 13:37 +0000, Rodger Etz wrote:
Thanks, Chris! I did so, but reboot did not create a debugdata dir. Therefore I have uploaded the dnf logs.
From what I have seen so far, it still seems the best option to modify system-upgrade so it safes the transaction before reboot and reboot reruns it ... or something similar.
Trying to figure out what obscure dependency constellation this is causing, will be painful and most likely fail, because we do not have enough information and the state of dependencies changes so quickly, the issue might not occur after the next update of those packages. And even if we find this particular one, it might be there are others as well.
This is what I get if I don't use the --allowdelete option. The "does not belong to a distupgrade repository" is the part that concerns me.
Error: Problem 1: package gnome-shell-extension-fedmsg-0.1.9-19.fc29.noarch requires fedmsg-notify, but none of the providers can be installed - fedmsg-notify-0.5.9-1.fc29.noarch does not belong to a distupgrade repository - problem with installed package gnome-shell-extension-fedmsg-0.1.9- 19.fc29.noarch Problem 2: package plasma-discover-snap-5.15.5-1.fc30.x86_64 requires plasma-discover = 5.15.5-1.fc30, but none of the providers can be installed - plasma-discover-5.15.5-1.fc30.x86_64 does not belong to a distupgrade repository - problem with installed package plasma-discover-snap-5.15.5- 1.fc30.x86_64 Problem 3: 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 Problem 4: problem with installed package qt5-qtwebengine-freeworld- 5.12.4-2.fc30.x86_64 - package qt5-qtwebengine-freeworld-5.12.4-3.fc31.x86_64 requires qt5-qtbase(x86-64) = 5.12.4, but none of the providers can be installed - qt5-qtwebengine-freeworld-5.12.4-2.fc30.x86_64 does not belong to a distupgrade repository - qt5-qtbase-5.12.4-4.fc30.x86_64 does not belong to a distupgrade repository Problem 5: problem with installed package scribus-generator-2.8.1- 1.fc30.noarch - package scribus-generator-2.8.1-2.fc31.noarch requires tkinter, but none of the providers can be installed - scribus-generator-2.8.1-1.fc30.noarch does not belong to a distupgrade repository - python2-tkinter-2.7.16-2.fc30.x86_64 does not belong to a distupgrade repository Problem 6: package kf5-ktexteditor-devel-5.61.0-1.fc31.x86_64 requires kf5-ktexteditor(x86-64) = 5.61.0-1.fc31, but none of the providers can be installed - problem with installed package kf5-ktexteditor-devel-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-devel-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 (try to add '--skip-broken' to skip uninstallable packages)
Is it worth it to start a discussion on devel@ ?
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, 4. October 2019 20:44, Chris Murphy < lists@colorremedies.com> wrote:
I suggest trying --debugsolver with both the download and reboot subcommands. 'man dnf system-upgrade' suggests --debugsolver should work. I recommend taring the debugdata dir that will create, and setting the filename and attachment description so it's clear whether the tarball is for reboot or download.
The debugdata dir will be located in the current dir. So that'll be easy to find for the download command. But I have no idea where it'll be located for reboot so you'll probably have to use find.
Sometimes these are bigger than the 20MB attachment size, so you might have to stick it in a dropbox/googledrive like thing and post the URLs for them in the bug report.
Chris Murphy
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
On 10/7/19 10:51 AM, Alan wrote:
On Sat, 2019-10-05 at 13:37 +0000, Rodger Etz wrote:
Thanks, Chris! I did so, but reboot did not create a debugdata dir. Therefore I have uploaded the dnf logs.
From what I have seen so far, it still seems the best option to modify system-upgrade so it safes the transaction before reboot and reboot reruns it ... or something similar.
Trying to figure out what obscure dependency constellation this is causing, will be painful and most likely fail, because we do not have enough information and the state of dependencies changes so quickly, the issue might not occur after the next update of those packages. And even if we find this particular one, it might be there are others as well.
This is what I get if I don't use the --allowdelete option. The "does not belong to a distupgrade repository" is the part that concerns me.
I assume you mean --allowerasing? Why don't you want to use that?
The libgit2 module problem is a known issue that is currently being hotly discussed. The "does not belong to a distupgrade repository" message is bit confusing. Usually what it seems to mean is that some package that is getting upgraded was a dependency for something that isn't. The original version which is still required is not available in any of the repos being used for the upgrade. It would be a lot more helpful if dnf would provide some more useful information, like which package is getting upgraded to cause the problem. Maybe that info is further up in the list of packages getting upgraded?
Error: Problem 1: package gnome-shell-extension-fedmsg-0.1.9-19.fc29.noarch requires fedmsg-notify, but none of the providers can be installed
- fedmsg-notify-0.5.9-1.fc29.noarch does not belong to a distupgrade
repository
I don't know what's happening here. Neither one is getting upgraded because they are both retired. Maybe it's a python 2 thing.
Problem 2: package plasma-discover-snap-5.15.5-1.fc30.x86_64 requires plasma-discover = 5.15.5-1.fc30, but none of the providers can be installed
- plasma-discover-5.15.5-1.fc30.x86_64 does not belong to a
distupgrade repository
Not sure here either, although there appears to have been a build problem. A build of an older version was done after a newer one, so something could be confused.
Problem 3: 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
This is the libgit2 issue. It can't upgrade libgit2, so it can't upgrade kf5-ktexteditor. It's telling you that the old version is not available in F31.
Problem 4: problem with installed package qt5-qtwebengine-freeworld- 5.12.4-2.fc30.x86_64
- package qt5-qtwebengine-freeworld-5.12.4-3.fc31.x86_64 requires
qt5-qtbase(x86-64) = 5.12.4, but none of the providers can be installed
qt5-qtbase was updated in Fedora, but qt5-qtwebengine-freeworld which depends on it is in rpmfusion. I see there is a new build today, so this issue should be fixed soon.
- qt5-qtwebengine-freeworld-5.12.4-2.fc30.x86_64 does not belong to a
distupgrade repository
- qt5-qtbase-5.12.4-4.fc30.x86_64 does not belong to a distupgrade
repository
Just telling you that the packages are no longer available.
Problem 5: problem with installed package scribus-generator-2.8.1- 1.fc30.noarch
- package scribus-generator-2.8.1-2.fc31.noarch requires tkinter, but
none of the providers can be installed
"tkinter" used to be provided by the python2-tkinter package, but the provide has been dropped. scribus-generator needs to change the depend to python2-tkinter now, although it should really move to python3 instead.
- scribus-generator-2.8.1-1.fc30.noarch does not belong to a
distupgrade repository
- python2-tkinter-2.7.16-2.fc30.x86_64 does not belong to a
distupgrade repository
Again, the old packages are no longer available.
Problem 6: package kf5-ktexteditor-devel-5.61.0-1.fc31.x86_64 requires kf5-ktexteditor(x86-64) = 5.61.0-1.fc31, but none of the providers can be installed
- problem with installed package kf5-ktexteditor-devel-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-devel-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
libgit2 again.
On 10/7/19 10:51 AM, Alan wrote:
On Sat, 2019-10-05 at 13:37 +0000, Rodger Etz wrote:
Thanks, Chris! I did so, but reboot did not create a debugdata dir. Therefore I have uploaded the dnf logs.
From what I have seen so far, it still seems the best option to modify system-upgrade so it safes the transaction before reboot and reboot reruns it ... or something similar.
Trying to figure out what obscure dependency constellation this is causing, will be painful and most likely fail, because we do not have enough information and the state of dependencies changes so quickly, the issue might not occur after the next update of those packages. And even if we find this particular one, it might be there are others as well.
This is what I get if I don't use the --allowdelete option. The "does not belong to a distupgrade repository" is the part that concerns me.
I assume you mean --allowerasing? Why don't you want to use that?
Yes. (My sinus headache is not helping.) Because it causes the upgrade to fail after the reboot.
The libgit2 module problem is a known issue that is currently being hotly discussed. The "does not belong to a distupgrade repository" message is bit confusing. Usually what it seems to mean is that some package that is getting upgraded was a dependency for something that isn't. The original version which is still required is not available in any of the repos being used for the upgrade. It would be a lot more helpful if dnf would provide some more useful information, like which package is getting upgraded to cause the problem. Maybe that info is further up in the list of packages getting upgraded?
Error: Problem 1: package gnome-shell-extension-fedmsg-0.1.9-19.fc29.noarch requires fedmsg-notify, but none of the providers can be installed
- fedmsg-notify-0.5.9-1.fc29.noarch does not belong to a distupgrade
repository
I don't know what's happening here. Neither one is getting upgraded because they are both retired. Maybe it's a python 2 thing.
Problem 2: package plasma-discover-snap-5.15.5-1.fc30.x86_64 requires plasma-discover = 5.15.5-1.fc30, but none of the providers can be installed
- plasma-discover-5.15.5-1.fc30.x86_64 does not belong to a
distupgrade repository
Not sure here either, although there appears to have been a build problem. A build of an older version was done after a newer one, so something could be confused.
Problem 3: 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
This is the libgit2 issue. It can't upgrade libgit2, so it can't upgrade kf5-ktexteditor. It's telling you that the old version is not available in F31.
Problem 4: problem with installed package qt5-qtwebengine-freeworld- 5.12.4-2.fc30.x86_64
- package qt5-qtwebengine-freeworld-5.12.4-3.fc31.x86_64 requires
qt5-qtbase(x86-64) = 5.12.4, but none of the providers can be installed
qt5-qtbase was updated in Fedora, but qt5-qtwebengine-freeworld which depends on it is in rpmfusion. I see there is a new build today, so this issue should be fixed soon.
- qt5-qtwebengine-freeworld-5.12.4-2.fc30.x86_64 does not belong to
a distupgrade repository
- qt5-qtbase-5.12.4-4.fc30.x86_64 does not belong to a distupgrade
repository
Just telling you that the packages are no longer available.
Problem 5: problem with installed package scribus-generator-2.8.1- 1.fc30.noarch
- package scribus-generator-2.8.1-2.fc31.noarch requires tkinter,
but none of the providers can be installed
"tkinter" used to be provided by the python2-tkinter package, but the provide has been dropped. scribus-generator needs to change the depend to python2-tkinter now, although it should really move to python3 instead.
- scribus-generator-2.8.1-1.fc30.noarch does not belong to a
distupgrade repository
- python2-tkinter-2.7.16-2.fc30.x86_64 does not belong to a
distupgrade repository
Again, the old packages are no longer available.
Problem 6: package kf5-ktexteditor-devel-5.61.0-1.fc31.x86_64 requires kf5-ktexteditor(x86-64) = 5.61.0-1.fc31, but none of the providers can be installed
- problem with installed package kf5-ktexteditor-devel-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-devel-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
libgit2 again.
If you use --allowerasing, the upgrade transaction works, but since that flag does not get passed to the upgrade after the reboot, the process fails because it tries to upgrade those packages and they were never downloaded.
This is going to confuse an unknown number of people.
Q: Why do programmers confuse Halloween and Christmas? A: Because OCT 31 == DEC 25.
On 10/7/19 12:33 PM, alan@clueserver.org wrote:
If you use --allowerasing, the upgrade transaction works, but since that flag does not get passed to the upgrade after the reboot, the process fails because it tries to upgrade those packages and they were never downloaded.
That is certainly not true, because I have had to use that on most upgrades. The problem is somewhere else and it's hard to tell why dnf is coming up with a different transaction on the reboot phase. I wonder if a temporary workaround would be for you to manually download those missing packages and put them in the sysupgrade directory before rebooting.
On Mon, Oct 7, 2019 at 3:38 PM Samuel Sieb samuel@sieb.net wrote:
On 10/7/19 12:33 PM, alan@clueserver.org wrote:
If you use --allowerasing, the upgrade transaction works, but since that flag does not get passed to the upgrade after the reboot, the process fails because it tries to upgrade those packages and they were never downloaded.
That is certainly not true, because I have had to use that on most upgrades. The problem is somewhere else and it's hard to tell why dnf is coming up with a different transaction on the reboot phase. I wonder if a temporary workaround would be for you to manually download those missing packages and put them in the sysupgrade directory before rebooting.
Do they exist? I'd expect if they exist, then --allow-erasing wouldn't be needed in the first place?
Anyway, gnome-software does use --allow-erasing. I don't know how that gets passed off to /usr/lib/systemd/system/packagekit-offline-update.service
But that's an interesting distinction between dnf and gnome-software, they're using different offline update services to perform the upgrade, where dnf uses /usr/lib/systemd/system/dnf-system-upgrade.service
What happens if the dnf upgrade utility always called --allow-erasing? That doesn't seem bad does it?
On 10/7/19 12:33 PM, alan@clueserver.org wrote:
If you use --allowerasing, the upgrade transaction works, but since that flag does not get passed to the upgrade after the reboot, the process fails because it tries to upgrade those packages and they were never downloaded.
That is certainly not true, because I have had to use that on most upgrades. The problem is somewhere else and it's hard to tell why dnf is coming up with a different transaction on the reboot phase. I wonder if a temporary workaround would be for you to manually download those missing packages and put them in the sysupgrade directory before rebooting.
As have I. Something has changed in how this gets resolved. Hopefully it will get identified before the non-beta version gets released.
Q: Why do programmers confuse Halloween and Christmas? A: Because OCT 31 == DEC 25.
On Mon, Oct 7, 2019 at 4:43 PM alan@clueserver.org wrote:
On 10/7/19 12:33 PM, alan@clueserver.org wrote:
If you use --allowerasing, the upgrade transaction works, but since that flag does not get passed to the upgrade after the reboot, the process fails because it tries to upgrade those packages and they were never downloaded.
That is certainly not true, because I have had to use that on most upgrades. The problem is somewhere else and it's hard to tell why dnf is coming up with a different transaction on the reboot phase. I wonder if a temporary workaround would be for you to manually download those missing packages and put them in the sysupgrade directory before rebooting.
As have I. Something has changed in how this gets resolved. Hopefully it will get identified before the non-beta version gets released.
It's not going to get fixed magically. Needs a bug report and probably should be proposed as a blocker. Final freeze starts in just over 1 hour so any fix will at least need to be granted freeze exception but that too requires a bug report.
1758588 has been opened by me 4th Oct as mentioned earlier. Bug is still in New state!?
-------- Original-Nachricht -------- An 7. Okt. 2019, 23:53, Chris Murphy schrieb:
On Mon, Oct 7, [2019](tel:2019) at 4:43 PM alan@clueserver.org wrote:
On 10/7/19 12:33 PM, alan@clueserver.org wrote:
If you use --allowerasing, the upgrade transaction works, but since that flag does not get passed to the upgrade after the reboot, the process fails because it tries to upgrade those packages and they were never downloaded.
That is certainly not true, because I have had to use that on most upgrades. The problem is somewhere else and it's hard to tell why dnf is coming up with a different transaction on the reboot phase. I wonder if a temporary workaround would be for you to manually download those missing packages and put them in the sysupgrade directory before rebooting.
As have I. Something has changed in how this gets resolved. Hopefully it will get identified before the non-beta version gets released.
It's not going to get fixed magically. Needs a bug report and probably should be proposed as a blocker. Final freeze starts in just over 1 hour so any fix will at least need to be granted freeze exception but that too requires a bug report.
-- Chris Murphy _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Marek looked at it and confirmed my analysis. He also stated the issue will be solved.
So IMHO there is no point discussing dep issues of certain packages, because the issue is simply that options from download are not carried over to reboot. If this is tixed, all will be fine.
If it is not fixed by end of the week, I'll work on it when back from hols.
I also don't see this as a blocker, as a workaround is available and so far the issue only hit very few installations. -------- Original-Nachricht -------- An 8. Okt. 2019, 07:53, Rodger Etz schrieb:
1758588 has been opened by me 4th Oct as mentioned earlier. Bug is still in New state!?
-------- Original-Nachricht -------- An 7. Okt. 2019, 23:53, Chris Murphy schrieb:
On Mon, Oct 7, [2019](tel:2019) at 4:43 PM alan@clueserver.org wrote:
On 10/7/19 12:33 PM, alan@clueserver.org wrote:
If you use --allowerasing, the upgrade transaction works, but since that flag does not get passed to the upgrade after the reboot, the process fails because it tries to upgrade those packages and they were never downloaded.
That is certainly not true, because I have had to use that on most upgrades. The problem is somewhere else and it's hard to tell why dnf is coming up with a different transaction on the reboot phase. I wonder if a temporary workaround would be for you to manually download those missing packages and put them in the sysupgrade directory before rebooting.
As have I. Something has changed in how this gets resolved. Hopefully it will get identified before the non-beta version gets released.
It's not going to get fixed magically. Needs a bug report and probably should be proposed as a blocker. Final freeze starts in just over 1 hour so any fix will at least need to be granted freeze exception but that too requires a bug report.
-- Chris Murphy _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
On Tue, 2019-10-08 at 12:08 +0000, Rodger Etz wrote:
Marek looked at it and confirmed my analysis. He also stated the issue will be solved.
I'm not sure either of you figured it out entirely, I'm digging into it more ATM. But...
So IMHO there is no point discussing dep issues of certain packages,
Well, there are at least several genuine issues here, one of which is quite bad: for some reason, there is a much newer dnf version in F30 updates-testing (4.2.11) than there is in any F31 repo (4.2.9 is the latest there). F31 package 'yum' is set to obsolete F30 package 'dnf- yum'...but only for *older versions*, so if you have the current F30 updates-testing dnf-yum package installed, when you try to upgrade to F31, nothing replaces dnf-yum. With --allowerasing, dnf will remove it and update dnf. Without --allowerasing, dnf will keep the old dnf in order to keep the old dnf-yum.
That one definitely needs reporting, and I will do it.
Wow, yes, I did not see this. The dnf version mismatch is a biggie, I totally agree.
-------- Original-Nachricht -------- An 9. Okt. 2019, 00:53, Adam Williamson schrieb:
On Tue, [2019-10-08](tel:20191008) at 12:08 +0000, Rodger Etz wrote:
Marek looked at it and confirmed my analysis. He also stated the issue will be solved.
I'm not sure either of you figured it out entirely, I'm digging into it more ATM. But...
So IMHO there is no point discussing dep issues of certain packages,
Well, there are at least several genuine issues here, one of which is quite bad: for some reason, there is a much newer dnf version in F30 updates-testing [(4.2.11](tel:4211)) than there is in any F31 repo [(4.2.9](tel:429) is the latest there). F31 package 'yum' is set to obsolete F30 package 'dnf- yum'...but only for *older versions*, so if you have the current F30 updates-testing dnf-yum package installed, when you try to upgrade to F31, nothing replaces dnf-yum. With --allowerasing, dnf will remove it and update dnf. Without --allowerasing, dnf will keep the old dnf in order to keep the old dnf-yum.
That one definitely needs reporting, and I will do it.
Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
On 10/3/19 7:08 PM, Chris Murphy wrote:
Does anyone know if --allow-erasing needs to be passed to both 'download' and 'reboot' subcommands for this to work correctly?
Or does the download subcommand track options and apply them in the rebooted offline/upgrade environment?
The options must get saved somewhere because I use that often. You don't need to give it to the reboot subcommand.
On Thu, Oct 3, 2019 at 11:08 AM Rodger Etz reb@brownsen.net wrote:
Bugzilla Bug 1644439 looks identical, but was not investigated further as it seems the issue did not appear anymore and dnf has changed since reported.
I suggest reopening that bug and providing your updated information: call trace, any logs, and in particular debugsolver.
Or alternatively feel free to start a new bug report and add a link to the Links section (after filing the bug) to this old closed bug so it's available as a reference. I also suggest proposing it as a blocker bug. Ask if you don't know how to do that with your FAS account or don't have one.
https://qa.fedoraproject.org/blockerbugs/propose_bug
One possible justification to use for the blocking proposal: https://fedoraproject.org/wiki/Fedora_31_Beta_Release_Criteria#Basic_criteri... For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed.
And also if you can test the same setup with GNOME Software and see if it also fails and collect logs, that's really helpful also since that's the Workstation recommended upgrade tool. That would even more likely be a blocking bug. Gotch is you'll have to file a separate bug report since it's a separate component and upgrade method.
On Wed, Oct 2, 2019 at 3:32 PM Alan alan@clueserver.org wrote:
This is interesting... I am going to do a heavy clean of the packages and try again.
Oct 02 11:22:23 daimajin dnf[1390]: Transaction Summary Oct 02 11:22:23 daimajin dnf[1390]: ======================================================================= ========= Oct 02 11:22:23 daimajin dnf[1390]: Install 144 Packages Oct 02 11:22:23 daimajin dnf[1390]: Upgrade 4828 Packages Oct 02 11:22:23 daimajin dnf[1390]: Remove 12 Packages Oct 02 11:22:23 daimajin dnf[1390]: Downgrade 9 Packages Oct 02 11:22:23 daimajin dnf[1390]: Skip 3 Packages Oct 02 11:22:27 daimajin systemd[1]: systemd-hostnamed.service: Succeeded. Oct 02 11:22:27 daimajin kernel: audit: type=1131 audit(1570040547.732:91): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnam> Oct 02 11:22:27 daimajin audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/> Oct 02 11:23:01 daimajin dnf[1390]: Total size: 9.4 G Oct 02 11:23:01 daimajin dnf[1390]: Total download size: 19 M
I'm confused right off the bat, if this is the reboot that's supposed to do the offline upgrade. There shouldn't be anything to download, it should already have everything downloaded.
Oct 02 11:23:01 daimajin dnf[1390]: Downloading Packages: Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma- desktop-5.16.4-1.fc31.x86_64.rpm Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-5.16.4- 1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma- desktop-kimpanel-scim-5.16.4-1.fc31.x86_> Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-kimpanel- scim-5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma- integration-5.16.4-1.fc31.x86_64.rpm Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-integration-5.16.4- 1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma- lookandfeel-fedora-5.16.4-1.fc31.noarch.> Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-lookandfeel-fedora- 5.16.4-1.fc31.noarch" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma- workspace-5.16.4-1.fc31.x86_64.rpm Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-workspace-5.16.4- 1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/plasma- workspace-wayland-5.16.4-1.fc31.x86_64.r> Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-workspace-wayland- 5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:20 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/sddm- breeze-5.16.4-1.fc31.noarch.rpm Oct 02 11:23:20 daimajin dnf[1390]: Package "sddm-breeze-5.16.4- 1.fc31.noarch" from repository "fedora" has incorrect checksum Oct 02 11:23:24 daimajin dnf[1390]: Error: Some packages have invalid cache, but cannot be downloaded due to "--cacheonly" option Oct 02 11:23:24 daimajin systemd[1]: dnf-system-upgrade.service: Main process exited, code=exited, status=1/FAILURE Oct 02 11:23:24 daimajin systemd[1]: dnf-system-upgrade.service: Failed with result 'exit-code'. Oct 02 11:23:24 daimajin systemd[1]: Failed to start System Upgrade using DNF.
Somehow those rpms have been corrupted. I suggest deleting them and rerunning the download command, it should efficiently download only rpms not already downloaded.
On 10/2/19 5:03 PM, Chris Murphy wrote:
On Wed, Oct 2, 2019 at 3:32 PM Alan alan@clueserver.org wrote:
This is interesting... I am going to do a heavy clean of the packages and try again.
Oct 02 11:22:23 daimajin dnf[1390]: Transaction Summary Oct 02 11:22:23 daimajin dnf[1390]: ======================================================================= ========= Oct 02 11:22:23 daimajin dnf[1390]: Install 144 Packages Oct 02 11:22:23 daimajin dnf[1390]: Upgrade 4828 Packages Oct 02 11:22:23 daimajin dnf[1390]: Remove 12 Packages Oct 02 11:22:23 daimajin dnf[1390]: Downgrade 9 Packages Oct 02 11:22:23 daimajin dnf[1390]: Skip 3 Packages Oct 02 11:22:27 daimajin systemd[1]: systemd-hostnamed.service: Succeeded. Oct 02 11:22:27 daimajin kernel: audit: type=1131 audit(1570040547.732:91): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnam> Oct 02 11:22:27 daimajin audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/> Oct 02 11:23:01 daimajin dnf[1390]: Total size: 9.4 G Oct 02 11:23:01 daimajin dnf[1390]: Total download size: 19 M
I'm confused right off the bat, if this is the reboot that's supposed to do the offline upgrade. There shouldn't be anything to download, it should already have everything downloaded.
dnf runs builds the whole transaction again using cached data. There's a mention of that at the bottom. It shouldn't have to download, but that's the problem here. Somehow there are some missing packages (maybe damaged, but it looks more like missing) and it can't download them because it's in cache-only mode.
On Wed, Oct 2, 2019 at 6:14 PM Samuel Sieb samuel@sieb.net wrote:
On 10/2/19 5:03 PM, Chris Murphy wrote:
On Wed, Oct 2, 2019 at 3:32 PM Alan alan@clueserver.org wrote:
This is interesting... I am going to do a heavy clean of the packages and try again.
Oct 02 11:22:23 daimajin dnf[1390]: Transaction Summary Oct 02 11:22:23 daimajin dnf[1390]: ======================================================================= ========= Oct 02 11:22:23 daimajin dnf[1390]: Install 144 Packages Oct 02 11:22:23 daimajin dnf[1390]: Upgrade 4828 Packages Oct 02 11:22:23 daimajin dnf[1390]: Remove 12 Packages Oct 02 11:22:23 daimajin dnf[1390]: Downgrade 9 Packages Oct 02 11:22:23 daimajin dnf[1390]: Skip 3 Packages Oct 02 11:22:27 daimajin systemd[1]: systemd-hostnamed.service: Succeeded. Oct 02 11:22:27 daimajin kernel: audit: type=1131 audit(1570040547.732:91): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnam> Oct 02 11:22:27 daimajin audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/> Oct 02 11:23:01 daimajin dnf[1390]: Total size: 9.4 G Oct 02 11:23:01 daimajin dnf[1390]: Total download size: 19 M
I'm confused right off the bat, if this is the reboot that's supposed to do the offline upgrade. There shouldn't be anything to download, it should already have everything downloaded.
dnf runs builds the whole transaction again using cached data. There's a mention of that at the bottom. It shouldn't have to download, but that's the problem here. Somehow there are some missing packages (maybe damaged, but it looks more like missing) and it can't download them because it's in cache-only mode.
I'm thinking both missing and corrupt. The early message "download size: 19 M" is consistent with missing, but then why are they missing when the download process includes a transaction check? Ostensibly, the transaction check is the same as what happens in the offline/cache mode. I'm not sure how 'download --allow-erasing' gets passed onto the reboot and subsequent upgrade. Does it need to be passed twice? And then also I wonder if -v can be passed to 'dnf system-upgrade reboot' to get verbose messages for the offline/upgrade boot dumped into the journal.
"Error opening file for checksum" taken literally, to me, means the file is there but fails RPM checksum. Similar to the above question I wonder if '--rpmverbosity debug' can be passed to dnf for the reboot. But if so, it should reveal if this really is an RPM checksum fail.
On 10/2/19 6:13 PM, Chris Murphy wrote:
"Error opening file for checksum" taken literally, to me, means the file is there but fails RPM checksum. Similar to the above question I wonder if '--rpmverbosity debug' can be passed to dnf for the reboot. But if so, it should reveal if this really is an RPM checksum fail.
Taken literally, I would take that to mean it can't open the file. The next line says the checksum doesn't match. But yes, I also wonder why it didn't get downloaded the first time since it should be the same data that it made the original transaction out of.
I am having the same issue but with different rpms. Cleaned the cache and downloaded everything again several times but always identical issue.
Will post log entries and further analysis later when I am back at my desk.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, 3. October 2019 04:59, Samuel Sieb samuel@sieb.net wrote:
On 10/2/19 6:13 PM, Chris Murphy wrote:
"Error opening file for checksum" taken literally, to me, means the file is there but fails RPM checksum. Similar to the above question I wonder if '--rpmverbosity debug' can be passed to dnf for the reboot. But if so, it should reveal if this really is an RPM checksum fail.
Taken literally, I would take that to mean it can't open the file. The next line says the checksum doesn't match. But yes, I also wonder why it didn't get downloaded the first time since it should be the same data that it made the original transaction out of.
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org
On Wed, 2019-10-02 at 19:13 -0600, Chris Murphy wrote:
On Wed, Oct 2, 2019 at 6:14 PM Samuel Sieb samuel@sieb.net wrote:
On 10/2/19 5:03 PM, Chris Murphy wrote:
On Wed, Oct 2, 2019 at 3:32 PM Alan alan@clueserver.org wrote:
This is interesting... I am going to do a heavy clean of the packages and try again.
Oct 02 11:22:23 daimajin dnf[1390]: Transaction Summary Oct 02 11:22:23 daimajin dnf[1390]: =============================================================== ======== ========= Oct 02 11:22:23 daimajin dnf[1390]: Install 144 Packages Oct 02 11:22:23 daimajin dnf[1390]: Upgrade 4828 Packages Oct 02 11:22:23 daimajin dnf[1390]: Remove 12 Packages Oct 02 11:22:23 daimajin dnf[1390]: Downgrade 9 Packages Oct 02 11:22:23 daimajin dnf[1390]: Skip 3 Packages Oct 02 11:22:27 daimajin systemd[1]: systemd-hostnamed.service: Succeeded. Oct 02 11:22:27 daimajin kernel: audit: type=1131 audit(1570040547.732:91): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnam> Oct 02 11:22:27 daimajin audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/> Oct 02 11:23:01 daimajin dnf[1390]: Total size: 9.4 G Oct 02 11:23:01 daimajin dnf[1390]: Total download size: 19 M
I'm confused right off the bat, if this is the reboot that's supposed to do the offline upgrade. There shouldn't be anything to download, it should already have everything downloaded.
dnf runs builds the whole transaction again using cached data. There's a mention of that at the bottom. It shouldn't have to download, but that's the problem here. Somehow there are some missing packages (maybe damaged, but it looks more like missing) and it can't download them because it's in cache-only mode.
I'm thinking both missing and corrupt. The early message "download size: 19 M" is consistent with missing, but then why are they missing when the download process includes a transaction check? Ostensibly, the transaction check is the same as what happens in the offline/cache mode. I'm not sure how 'download --allow-erasing' gets passed onto the reboot and subsequent upgrade. Does it need to be passed twice? And then also I wonder if -v can be passed to 'dnf system-upgrade reboot' to get verbose messages for the offline/upgrade boot dumped into the journal.
"Error opening file for checksum" taken literally, to me, means the file is there but fails RPM checksum. Similar to the above question I wonder if '--rpmverbosity debug' can be passed to dnf for the reboot. But if so, it should reveal if this really is an RPM checksum fail.
The file does not exist. Not there. I checked.
On Wed, 2019-10-02 at 18:03 -0600, Chris Murphy wrote:
On Wed, Oct 2, 2019 at 3:32 PM Alan alan@clueserver.org wrote:
This is interesting... I am going to do a heavy clean of the packages and try again.
Oct 02 11:22:23 daimajin dnf[1390]: Transaction Summary Oct 02 11:22:23 daimajin dnf[1390]: =================================================================== ==== ========= Oct 02 11:22:23 daimajin dnf[1390]: Install 144 Packages Oct 02 11:22:23 daimajin dnf[1390]: Upgrade 4828 Packages Oct 02 11:22:23 daimajin dnf[1390]: Remove 12 Packages Oct 02 11:22:23 daimajin dnf[1390]: Downgrade 9 Packages Oct 02 11:22:23 daimajin dnf[1390]: Skip 3 Packages Oct 02 11:22:27 daimajin systemd[1]: systemd-hostnamed.service: Succeeded. Oct 02 11:22:27 daimajin kernel: audit: type=1131 audit(1570040547.732:91): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnam> Oct 02 11:22:27 daimajin audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/> Oct 02 11:23:01 daimajin dnf[1390]: Total size: 9.4 G Oct 02 11:23:01 daimajin dnf[1390]: Total download size: 19 M
I'm confused right off the bat, if this is the reboot that's supposed to do the offline upgrade. There shouldn't be anything to download, it should already have everything downloaded.
It should, but it doesn't. I cleaned everything I could think of and reran the system upgrade and redownloaded everything and still get the same problem. Those packages exist on the F30 system, but something goes wrong in the update. There is only about 220Gigs free, so it is not drive space.
Oct 02 11:23:01 daimajin dnf[1390]: Downloading Packages: Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora- 3589ee8a7ee1691d/packages/plasma- desktop-5.16.4-1.fc31.x86_64.rpm Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-5.16.4- 1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora- 3589ee8a7ee1691d/packages/plasma- desktop-kimpanel-scim-5.16.4-1.fc31.x86_> Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-desktop- kimpanel- scim-5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora- 3589ee8a7ee1691d/packages/plasma- integration-5.16.4-1.fc31.x86_64.rpm Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-integration- 5.16.4- 1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora- 3589ee8a7ee1691d/packages/plasma- lookandfeel-fedora-5.16.4-1.fc31.noarch.> Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-lookandfeel- fedora- 5.16.4-1.fc31.noarch" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora- 3589ee8a7ee1691d/packages/plasma- workspace-5.16.4-1.fc31.x86_64.rpm Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-workspace- 5.16.4- 1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora- 3589ee8a7ee1691d/packages/plasma- workspace-wayland-5.16.4-1.fc31.x86_64.r> Oct 02 11:23:19 daimajin dnf[1390]: Package "plasma-workspace- wayland- 5.16.4-1.fc31.x86_64" from repository "fedora" has incorrect checksum Oct 02 11:23:20 daimajin dnf[1390]: Error opening file for checksum: /var/lib/dnf/system-upgrade/fedora-3589ee8a7ee1691d/packages/sddm- breeze-5.16.4-1.fc31.noarch.rpm Oct 02 11:23:20 daimajin dnf[1390]: Package "sddm-breeze-5.16.4- 1.fc31.noarch" from repository "fedora" has incorrect checksum Oct 02 11:23:24 daimajin dnf[1390]: Error: Some packages have invalid cache, but cannot be downloaded due to "--cacheonly" option Oct 02 11:23:24 daimajin systemd[1]: dnf-system-upgrade.service: Main process exited, code=exited, status=1/FAILURE Oct 02 11:23:24 daimajin systemd[1]: dnf-system-upgrade.service: Failed with result 'exit-code'. Oct 02 11:23:24 daimajin systemd[1]: Failed to start System Upgrade using DNF.
Somehow those rpms have been corrupted. I suggest deleting them and rerunning the download command, it should efficiently download only rpms not already downloaded.
They don't exist, yet it passed the transaction test.
On 10/2/19 2:01 PM, Alan wrote:
I have a laptop (Lenovo W540) running Fedora 30. I have preped it for upgrade using dnf.
I get to the reboot step is where it gets interesting.
I reboot and enter the drive password. It goes into the install, says it is preparing and then before it installs anything, it reboots.
Any idea what log to check to figure out why? It passed all the transaction tests.
"dnf system-upgrade log" should give you a list of logs from upgrade attempts. "dnf system-upgrade log --number=<number>" will give you the log from one of those.
-
Adam Williamson -
Alan -
alan＠clueserver.org
-
Chris Murphy -
Felix Miata -
Rodger Etz -
Samuel Sieb