Re: Upgrading from F30 to F31 beta reboot issue
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 +, 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___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
On Tue, 2019-10-08 at 12:08 +, 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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 wrote: >>> >>> >>> >>> > On 10/7/19 12:33 PM, a...@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-le...@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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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 wrote: >> >> >> >> > On 10/7/19 12:33 PM, a...@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-le...@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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
On Mon, Oct 7, 2019 at 4:43 PM wrote: > > > > > On 10/7/19 12:33 PM, a...@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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
> On 10/7/19 12:33 PM, a...@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. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
On Mon, Oct 7, 2019 at 3:38 PM Samuel Sieb wrote: > > On 10/7/19 12:33 PM, a...@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? -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
On 10/7/19 12:33 PM, a...@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. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
On Thu, Oct 3, 2019 at 11:08 AM Rodger Etz 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_criteria_met 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. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
> On 10/7/19 10:51 AM, Alan wrote: >> On Sat, 2019-10-05 at 13:37 +, 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
Re: Upgrading from F30 to F31 beta reboot issue
On 10/7/19 10:51 AM, Alan wrote: On Sat, 2019-10-05 at 13:37 +, 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. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of
Re: Upgrading from F30 to F31 beta reboot issue
On Sat, 2019-10-05 at 13:37 +, 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 < > li...@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 > >
Re: Upgrading from F30 to F31 beta reboot issue
On Sat, Oct 5, 2019 at 7:37 AM 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. > > 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. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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 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-le...@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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
Filed against dnf as suggested: 1758588 ‐‐‐ Original Message ‐‐‐ On Friday, 4. October 2019 09:31, 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. > > test mailing list -- test@lists.fedoraproject.org > To unsubscribe send an email to test-le...@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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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/plugins/system_upgrade.py > > 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-le...@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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
Anyone read python :P https://github.com/rpm-software-management/dnf-plugins-extras/blob/master/plugins/system_upgrade.py 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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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 ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
> 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-le...@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-le...@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. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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-le...@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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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 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-le...@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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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 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
Re: Upgrading from F30 to F31 beta reboot issue
On Wed, 2019-10-02 at 19:13 -0600, Chris Murphy wrote: > On Wed, Oct 2, 2019 at 6:14 PM Samuel Sieb wrote: > > On 10/2/19 5:03 PM, Chris Murphy wrote: > > > On Wed, Oct 2, 2019 at 3:32 PM Alan 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]: Upgrade4828 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. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
On Wed, 2019-10-02 at 18:03 -0600, Chris Murphy wrote: > On Wed, Oct 2, 2019 at 3:32 PM Alan 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]: Upgrade4828 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.
Re: Upgrading from F30 to F31 beta reboot issue
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 wrote:
> On Wed, 2019-10-02
Re: Upgrading from F30 to F31 beta reboot issue
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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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 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-le...@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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
On Wed, Oct 2, 2019 at 6:14 PM Samuel Sieb wrote: > > On 10/2/19 5:03 PM, Chris Murphy wrote: > > On Wed, Oct 2, 2019 at 3:32 PM Alan 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]: Upgrade4828 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. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
On 10/2/19 5:03 PM, Chris Murphy wrote: On Wed, Oct 2, 2019 at 3:32 PM Alan 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]: Upgrade4828 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. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
On Wed, Oct 2, 2019 at 3:32 PM Alan 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]: Upgrade4828 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. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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? ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
On Wed, 2019-10-02 at 15:23 -0600, Chris Murphy wrote: > On Wed, Oct 2, 2019 at 3:02 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. > > 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]: Upgrade4828 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. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
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=" will give you the log from one of those. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
Re: Upgrading from F30 to F31 beta reboot issue
On Wed, Oct 2, 2019 at 3:02 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. 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 -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@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
