Created attachment 1821782 [details] The picture of Software with an error Description of problem: Fully upgraded Fedora 34 cannot be upgraded via Software to F35 which reports an error (see screenshot). When clicked on the Install button, the machine reboots but no upgrade process is started and the machine boots into F34 as no upgrade process was started. Version-Release number of selected component (if applicable): Fully upgraded F34 How reproducible: Always (SElinux both on and off) Steps to Reproduce: 1. Install F34 Workstation. 2. Use `dnf update --refresh` to update to the latest packages. 3. Use `gsettings set org.gnome.software show-upgrade-prerelease` to allow Software to display newer versions and log out and in again. 4. Wait until Software offers the upgrade automatically, or go to Software and navigate to the Updates panel. 5. Click Download and wait until the new version downloads. 6. Click on Install -> this will produce the error. 7. The computer then gets restarted (automatically or press Restart) 8. F34 will be booted up again. Actual results: Fedora 34 cannot be upgraded on EFI based VM. Expected results: Fedora 34 should be able to upgrade Additional info: This is the related error: Sep 09 12:18:30 fedora PackageKit[1113]: upgrade-system transaction /68_badcddaa from uid 1000 finished with success after 54761ms Sep 09 12:18:54 fedora gnome-software[2113]: not GsPlugin error pk-engine-error-quark:0: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_2dengine_2derror_2dquark.Code0: failed to obtain auth Sep 09 12:18:54 fedora gnome-shell[1577]: endSessionDialog: No XDG_SESSION_ID, fetched from logind: 2 Sep 09 12:19:09 fedora gnome-shell[1577]: Source ID 1671 was not found when attempting to remove it Sep 09 12:19:09 fedora systemd-logind[751]: System is rebooting.
I am testing whether BIOS based VM also has this problem and will report when it is done.
Proposed as a Blocker for 35-beta by Fedora user lruzicka using the blocker tracking app because: Proposing as a blocker because it violates the following criterion: **Upgrade requirements** 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.
Thanks for a bug report. The gnome-software itself doesn't do the update/upgrade, it's managed by the PackageKit. How that does it I do not know, maybe it uses dnf or something in the background. In any case, I'm moving this to the PackageKit package for further investigation. By the way, does `dnf upgrade --releasever=35` succeed, please?
The behaviour is the same on EFI and BIOS based VMs. The upgrade is possible with DNF.
When I try it here, after I click the "Install" button on the upgrade banner I'm asked whether I want to restart and at the same time there is an error shown in the GUI of the Software claiming: Sorry, something went wrong: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_2dengine_2derror_2dquark.Code0: failed to obtain auth It comes from the PackageKit and means the polkit "did not receive/provide the required privileges".
man, we really need to figure out how to automate this test.
+3 in https://pagure.io/fedora-qa/blocker-review/issue/440 , marking accepted blocker.
When I revert this [1] commit, then I'm properly asked for the root credentials. The [1] is related to [2], which references gnome-software bug [3]. Unfortunately the commit message of the [2] also claims the changes being untested. The gnome-software does set the interactive flag, but the pk_offline_trigger_upgrade() does not have any flag for the interactivity. I believe the PackageKit patch should be partly reverted, the "trigger-offline-*" calls should all ask the user for the credentials in [1]. I do not see any problem with the [2], or I've just not face it. I filled it upstream as [4]. [1] https://github.com/PackageKit/PackageKit/commit/9b7e083cf849c4ed4d66fe32250f1615ab577d94 [2] https://github.com/PackageKit/PackageKit/commit/86f4a2fbf5fcb1230c68a57c4a7bc066aa3f7ef4 [3] https://gitlab.gnome.org/GNOME/gnome-software/-/issues/582#note_1095101 [4] https://github.com/PackageKit/PackageKit/issues/504
Here: https://koji.fedoraproject.org/koji/taskinfo?taskID=75451432 is a scratch build with the proposed (not yet accepted) patch: https://github.com/PackageKit/PackageKit/pull/505 I do not have commit rights to the PackageKit package (that's for good), thus I cannot create updates for the f34/f35/rawhide.
I can confirm that the scratch build works in terms that it offers an authentication dialogue, takes the password and after the reboot, system upgrade starts. I will also report the result of the upgrade (which is still going on) but I suppose that the issue has been mitigated by reversing the above mentioned.
For the record: upstream doesn't like the revert, they'd like to get much larger change (including changing affected PackageKit API), but I'd say for the time being and for the Fedora specifically it's fine to revert it.
I agree. Waiting for the thorough "correct" change might hold the release for a longer time than doing an easy fix (that has proven to be working) for the time's being. What do you think, @awilliam ? Btw, the upgrade mentioned above ended up successfully.
Yes, let's revert the change in our package for now and work with upstream to get a better long-term fix.
yeah, looking at it I'm okay with that. The other bug that upstream is trying to fix is actually a bug which openQA hits quite often, and which I reported - the one where we get an authentication dialog pop up when we switch back to the Shell from the console sometimes (it's apparently happening if GNOME tries to do a background refresh while we're at the console). So I wouldn't want to break that fix. But the change looks properly restricted, even if technically not the best way to do it. I can do the builds/updates if necessary, but if I do it, I can't karma them. Richard, if you agree with this approach, could you do it? Thanks!
> Richard, if you agree with this approach, could you do it I'm fine with the downstream revert but I can't do it until Monday as I'm about to become a builder for the weekend!
Haha, OK, I'll do it then. Just someone else will have to test/karma.
(In reply to Milan Crha from comment #5) > > Sorry, something went wrong: > > GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_2dengine_2derror_2dquark. > Code0: failed to obtain auth That error message is pretty intense. Can we please also rework the error handling so that quark IDs don't ever get included in error messages?
FEDORA-2021-ed95149b77 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ed95149b77
FEDORA-2021-17bea44a49 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-17bea44a49` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-17bea44a49 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-ed95149b77 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ed95149b77` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ed95149b77 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Michael Catanzaro from comment #17) > (In reply to Milan Crha from comment #5) > > > > Sorry, something went wrong: > > > > GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._pk_2dengine_2derror_2dquark. > > Code0: failed to obtain auth > > > That error message is pretty intense. Can we please also rework the error > handling so that quark IDs don't ever get included in error messages? While I agree they look bad in the user interface, they helped (me) here to recognize where the error comes from. Otherwise it would be just "failed to obtain auth", which can come from anywhere. In any case, it's unrelated to this particular bug report. Feel free to file one upstream, if there's none yet.
Tested today on a F34 work VM UEFI, with the https://bodhi.fedoraproject.org/updates/FEDORA-2021-ed95149b77 update, and the upgrade via gnome software runs without erros. Congrats.
FEDORA-2021-ed95149b77 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-17bea44a49 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.