This is a discussion topic for the following Common Issue:
You can discuss the problem and its solutions here, but please note that debugging and technical feedback should primarily go to the issue trackers (e.g. Bugzilla) linked in the Common Issue, because that’s the place that developers watch, not here.
If there are any updates/changes/amendments for the Common Issue description, which you believe should be performed, please post it here.
Please see the Common Issue for solution/workarounds:
Yup, ran into this issue too this morning when running flatpak update it just rage quits and puts out a core dump error with no information like this:
[scott@fedora ~]$ flatpak update
Looking for updates…
New org.nickvision.tubeconverter permissions:
file access [1]
[1] xdg-download
ID Branch Op Remote Download
1. [|] org.gnome.Platform master u gnome-nightly 871.6 kB / 346.2 MB
2. [ ] org.nickvision.money stable u flathub < 46.2 MB
3. [ ] io.gitlab.adhami3310.Footage stable u flathub < 24.2 MB
4. [ ] org.nickvision.tubeconverter.Locale stable u flathub < 378.8 kB (partial)
5. [ ] org.nickvision.tubeconverter stable u flathub < 58.5 MB
Updating 1/5… ██ 10% 871.6 kB/sBus error (core dumped)
[scott@fedora ~]$
Does anyone really check this before updates? 
There are tests for ostree, but I guess they didn’t test flatpak enough. I’m hoping they’ll add a test. (It’s likely they will after this.)
There’s also gating for Fedora, which has additional tests, but I guess it slipped through… it’s likely people who don’t use flatpaks (or had flatpaks up to date before checking) checked that ostree worked for them? https://bodhi.fedoraproject.org/updates/FEDORA-2023-3ef0a90a6f
Hopefully this will be fixed quickly, but it is the weekend, so it might take a little bit longer to push a hotfix?
@garrett thanks for your post and solution. As of 2023-06-25, downgrading ostree-libs works on Workstation.
sudo dnf downgrade ostree-libs
Source: https://github.com/flatpak/flatpak/issues/5452#issuecomment-1605686112
Do you mind updating your post? The method you currently have requires uninstalling several packages unrelated to this issue.
That doesn’t work on my F38 workstation, resulting in
ostree-libs-2023.3-3.fc38.x86_64.rpm 531 kB/s | 437 kB 00:00
Error:
Problem: problem with installed package ostree-2023.4-1.fc38.x86_64
- package ostree-2023.4-1.fc38.x86_64 from @System requires libostree-1.so.1(LIBOSTREE_2023.4)(64bit), but none of the providers can be installed
- package ostree-2023.4-1.fc38.x86_64 from @System requires ostree-libs(x86-64) = 2023.4-1.fc38, but none of the providers can be installed
- package ostree-2023.4-1.fc38.x86_64 from updates requires libostree-1.so.1(LIBOSTREE_2023.4)(64bit), but none of the providers can be installed
- package ostree-2023.4-1.fc38.x86_64 from updates requires ostree-libs(x86-64) = 2023.4-1.fc38, but none of the providers can be installed
- package ostree-2023.1-2.fc38.x86_64 from fedora requires ostree-libs(x86-64) = 2023.1-2.fc38, but none of the providers can be installed
- cannot install both ostree-libs-2023.3-3.fc38.x86_64 from @commandline and ostree-libs-2023.4-1.fc38.x86_64 from @System
- cannot install both ostree-libs-2023.3-3.fc38.x86_64 from @commandline and ostree-libs-2023.1-2.fc38.x86_64 from fedora
- cannot install both ostree-libs-2023.3-3.fc38.x86_64 from @commandline and ostree-libs-2023.4-1.fc38.x86_64 from updates
- conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
downgrading as suggested by @william-cto works though
I rewrote the whole description, would appreciate finding issues or suggestions for better hints. I want to publish this today. Thanks a lot @garrett for starting this.
There’s a pull request (feature branch that’s suggest to merge into the project) that’s pending. Hopefully this will be merged in soon, and released as a hotfix; then distributions can pick up an official hotfix.
TL;DR: Progress is being made. It should hopefully be fixed and then deployed soon.
--user shouldn’t be suggested as a workaround here. Most users (who use flatpak with the default behaviour of system installation) won’t be able to update their existing flatpaks by adding --user.
You can of course install new flatpaks with --user but this adds complexity to using flatpak that wasn’t there before (now you have 2 different flatpak installations to manage). I think there are no remotes configured in --user either, so you’d also have to add flathub (or whatever remotes) again.
First, thanks. Downgrading ostree worked for me.
Second, How will we know when the version of ostree without conflicts is out and that it is safe to override the replace?
I see the update has been pushed to stable, when will it get into Kinoite? In fact the latest deployment available is from 24 June (3 days ago). Should I just be patient or is my system borked and not downloading the latest updates?
Silverblue and Kinoite composes are currently failiing: No update since 38.20230624.0 (was: Conflict installing Samba) · Issue #475 · fedora-silverblue/issue-tracker · GitHub
Once this is solved, the next update will get it.
It’s interesting to see that the buggy ostree package was pushed to updates based on 3x positive karma but apparently none of the testers did a flatpak update after they installed the package.
It’d be better not to leave karma instead of thumbs up without doing any actual testing!
https://bodhi.fedoraproject.org/updates/FEDORA-2023-3ef0a90a6f
There should be an additional criteria on bodhi for flatpak, something like "Karma: does updating flatpaks work?
The problem wasn’t universal. At least on my system, it only failed with large flatpaks. Smaller ones were installed/updated just fine.
I saw that the issue did not affect flatpaks that were installed on the system and updated from an administrator account (that is sudo flatpak update). And it also did not affect people installing flatpaks to the user account and updating via user.
It “only” affected system flatpaks being updated by the user (which is the case for almost everyone using flatpaks on Fedora), due to something that broke due to assumptions on how FUSE is used in this case. This includes using GNOME Software or KDE Discover to install and update flatpaks as well as the command line when you’re updating system flatpaks from your user account.
But that would explain why some people didn’t see a problem and it got in (even despite some tests and some QA), whereas most of us saw the issue.
I have one concrete example. When I tried to install org.flathub.flatpak-external-data-checker, it wanted to install this:
ID Branch Op Remote Download
1. org.flathub.flatpak_external_data_checker.Locale stable i flathub < 1,9 MB (partial)
2. org.freedesktop.Sdk.Locale 22.08 i flathub < 339,1 MB (partial)
3. org.freedesktop.Sdk 22.08 i flathub < 513,5 MB
4. org.flathub.flatpak-external-data-checker stable i flathub < 13,2 MB
It always failed on number 3, after about 40% progress. The locale flatpaks were installed just fine. When I tried to install just org.freedesktop.Sdk//22.08 separately, it again installed its locale just fine, and then failed again on that Sdk after about 40% progress.
Anyways, I argue that the bug would have been caught if Bodhi’s karma criteria would be based on a flatpak operation and not just the sucessful installation of the buggy package.
That’s a misunderstanding of karma. The default karma question available under all updates is Is the update generally functional? That doesn’t refer to installation. That really refers to testing general functionality (in this case, anything related to flatpak operations). The problem is that most people don’t write what they tested, they just give thumbs up. A second problem is that this is just a randomness approach - you hope that those people who first test it and supply karma would be the ones to trigger the bug and notice it. That hasn’t happened here.
One of the improvements is to add specific test cases for flatpak, and people can then perform those steps. Let’s be sincere - almost no one does that, even for packages which have these test cases. A better improvement is to create an automated test suite which is mandatory to pass - Fedora CI is then used to execute it. That would be a significant step forward. Another solution is to require the updates to be in testing for certain time (e.g. at least 3 days, at least 1 week, etc), even if they have enough positive karma. From my experience, that’s an unpopular approach for package maintainers.