[Bug]: Can't install an application on void linux (Writing content object: Need more input). #5452
Comments
|
I'm having the same issues. Using risiOS(Fedora 38 based). I'll post a log and additional info later. |
|
I'm having the same problem right now, i just installed Fedora 38, i was following a tutorial and got the same error trying to install ExtensionManager. I can't install anything of the Software list using Flathub because of the same error "Writing content object: Need more input" |
|
Having the same issue with installing/updating apps. log with --verbose |
|
Same here. Also getting this error - I can access and download the installer files from the flathub website, but I am not able to install it. |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
|
To Fedora users here, until an official fix comes, you can downgrade flatpak via: To SilverBlue/Kinoite users here, just run that command in your fedora toolbox, and use flatpak from the toolbox, it will work just fine, until the fix comes. This way you don't have to change the version of your distro's flatpak :) This should work for others as well. |
|
(Also, pinging @amigadave to take a look here. I think flatpak broke for the latest version for all flatpak users) |
|
After the most recent update on my Fedora rpm-ostree system, I am also unable to download Flatpak apps :( The issue can be resolved by rolling back to the previous image (38.20230622.0 (2023-06-22T02:16:55Z)). The list of downgrade in I'm unsure which package update is causing this issue... |
|
@yuntaz0 Are you sure its not flatpak itself? Downgrading flatpak works fine, even if from toolbox. Look at the above comment #5452 (comment) |
|
Thank you for your suggestion, @VarLad Sorry I can't definitively say whether the issue originates from Flatpak itself or not. However, I can confirm that rolling back and downgrading the packages listed resolves the issue. This procedure is quite simple in the ostree system. |
|
On Fedora 38 it started after upgrading ostree packages to 2023.4-1, doesn't happen with 2023.3-3 |
|
I am having dependency issue with the command in Fedora 38.
|
This comment was marked as off-topic.
This comment was marked as off-topic.
|
install an rpm package is unrelated to flatpak. Looking into Fedora (since thats been reported to be affected and I have an insight into that), the last builds for a stable release where 3 months ago, so things should not suddenly break out of nowhere. This appears to be an issue with flathub triggering an edge case in flatpak. |
|
@Jan200101 I can confirm this is not an issue with Flathub specifically as this happens for other flatpak repos as well (like GNOME-nightly or kdeapps) I feel like its an issue with the updating of packages @yuntaz0 mentioned
|
Flatpak uses the libostree shared library (ostree-libs on Fedora), so if Fedora has recently updated ostree-libs from 2023.3 to 2023.4, that is a possible reason for Flatpak to stop working. If it's a new ostree-libs version that triggered this, then it's most likely to be an ostree-libs bug rather than a Flatpak bug. @NEsanya, did Void Linux also recently upgrade libostree? |
|
libostree ended up in Fedora stable about 12 hours ago Void had the package pushed yesterday but I don't know their update flow |
That's not true if the RPM package is something that Flatpak itself uses internally. Flatpak apps don't use the operating system's libraries, but the |
The timing is certainly suspicious, then. I've opened ostreedev/ostree#2900. |
|
For Silverblue (Fedora 38 specifically), you can fix this by downgrading the ostree package with an override to replace the shipped version of ostree: rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2023-cab8a89753When successful, it'll include a lot of info, notably: And you can revert to normal with: |
|
@SalahuddinAhammed The cause has been pinpointed to ostree-libs (and I can confirm that downgrading it works) |
|
@smcv yep, void updated libostree yesterday |
|
I've downgraded ostree and everything is working! git clone https://github.com/void-linux/void-packages/
cd void-packages
git reset --hard be92627
./xbps-src binary-bootstrap
./xbps-src pkg ostree
sudo xbps-remove flatpak
sudo xbps-remove ostree
sudo xbps-install --repository hostdir/binpkgs ostree
sudo xbps-install flatpak |
|
@VarLad Thanks, it works! |
|
This seems to be a libostree bug, not a Flatpak bug, so there is no Flatpak change that will fix it. Please do not comment here to say "me too": that's just drowning out the useful information here. We do not need any more reports that say that upgrading libostree to 2023.4 makes Flatpak regress in this way.
That's an ostree question, not a flatpak question. Please see ostreedev/ostree#2900 for the libostree side of this. Until that issue is closed, the answer is: there is no newer version fixing this. After that issue is closed, it will be possible to say what version it was (or is going to be) fixed in. |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
|
Before commenting on a noisy issue like this one, please consider whether your comment is genuinely adding information. The more comments there are here, the longer it is going to take anyone to wade through it and find the relevant parts. If you want an issue to be solved, slowing down developers who might be able to solve it is counterproductive! The first few comments from people on different distributions were useful information, but as soon as we had found the common pattern, "distros that already upgraded to libostree 2023.4", it became unnecessary for users of other distros to confirm that - and especially if someone has already said that a specific distro/version like Fedora 38 is affected, telling us that Fedora 38 is affected is no longer useful. Similarly, if someone has provided a workaround, replies that say "I tried your workaround and it was successful" are not giving us any new information after the first few. I've marked many of the "me too" replies as hidden (duplicate), to draw more attention to comments that add information. I would also like to remind commenters that this project has a code of conduct which includes "Exercise consideration and respect in your speech and actions". Please behave accordingly. |
|
another easy solution for Fedora kinoite 38 is to switch to 2023-06-19 update. which is: And of course don't update system until all of this is fixed. |
|
Guys, to finish the discussion for Fedora users, as the flatpak developers talked about, the problem is in libostree. Just run the libostree downgrade and use dnf-plugins-extras-versionlock to prevent libostree upgrade: sudo dnf downgrade ostree
sudo dnf install dnf-plugins-extras-versionlock
sudo dnf versionlock exclude ostree-2023.4-1.fc38.x86_64
sudo dnf versionlock exclude ostree-libs-2023.4-1.fc38.x86_64
# To remove versionlock exclusions, in future:
sudo dnf versionlock clearThis solution was mentioned here, by @RedBearAK I suggest to collaborators to close this issue. |
|
FYI, uBlue does the downgrades for you and other quality of life improvements in case you want to rebase. |
|
I also have this Issue on Arch Linux. |
|
On ArchLinux, updating ostree to the latest version ( |
|
Fedora has a staged update that supposedly fixes this bug. It corresponds to build ostree-2023.4-2.fc38, and I'm hoping to get advice on testing the staged package on Fedora Silverblue 38 (surely one of the most severely impacted distros). I get this error when I attempt to overlay the package: I suspect this means that it's required as a key, specific dependency of |
|
I have tried |
|
The temporary solution while we wait for a full fix is still here, earlier in the thread, if you are on Fedora 38: |
|
Patch has been deployed but the build is failing because of one test - https://openqa.fedoraproject.org/tests/1992040#step/_console_avc_crash/7 But everything else looks good to me after testing it for like 5 minutes lol. Here's a thread with some other people who have confirmed it works - https://bodhi.fedoraproject.org/updates/FEDORA-2023-464fae1680 So you guys can either wait for all the tests to pass or test what fails, your choice - Step - 1 $ that will upgrade to the patched version of this issue. Step - 2 $ that will reboot the system Step - 3 $ that will check if it's working or not. If you are still facing issues then comment with error logs. Else just give a thumbs up or whatever to this comment to show that it works for you. My config -
|
|
Seems to have been fixed in: ostreedev/ostree#2901 |
Please don't run this, partial upgrades are unsupported on arch, always do a full system update. https://wiki.archlinux.org/title/System_maintenance#Partial_upgrades_are_unsupported |
|
Can confirm that recent update on Fedora 38 fixed the issue for me, make sure to run |
|
Pleased to report that my strategy of using version lock exclusion (on Fedora 38) for the specific buggy version of ostree/ostree-libs has allowed the new version of the packages to appear in the update list and get installed via Upgrading:
bluez x86_64 5.66-6.fc38 updates 1.0 M
bluez-cups x86_64 5.66-6.fc38 updates 29 k
bluez-libs x86_64 5.66-6.fc38 updates 83 k
bluez-obexd x86_64 5.66-6.fc38 updates 229 k
ostree x86_64 2023.4-2.fc38 updates 247 k
ostree-libs x86_64 2023.4-2.fc38 updates 439 kI ran Also tried installing Planify, which I've never had installed before so there would be no chance of it being cached. That went fine too. If you followed my suggestion of using the |
By default, FUSE runs in cached I/O mode[1]. That means some I/O responses will be taken from the page cache instead of being handled by the FUSE process. For files opened for reading that's not a problem as all the requests are just passed through. However, that is problematic for files opened for writing since those requests need to be handled by the backend. It's particularly bad for a file opened `O_RDWR` since `read` responses from the page cache are likely to be wrong. Instruct FUSE to use `direct-io` for those files so that the page cache is bypassed. 1. https://docs.kernel.org/filesystems/fuse-io.html Fixes: flatpak#5452
|
After much debugging with When a file is opened for writing, |
By default, FUSE runs in cached I/O mode[1]. That means some I/O responses will be taken from the page cache instead of being handled by the FUSE process. For files opened for reading that's not a problem as all the requests are just passed through. However, that is problematic for files opened for writing since those requests need to be handled by the backend. It's particularly bad for a file opened `O_RDWR` since `read` responses from the page cache are likely to be wrong. Instruct FUSE to use `direct-io` for those files so that the page cache is bypassed. 1. https://docs.kernel.org/filesystems/fuse-io.html Fixes: #5452
|
Same, in Debian cant install anything. |
By default, FUSE runs in cached I/O mode[1]. That means some I/O responses will be taken from the page cache instead of being handled by the FUSE process. For files opened for reading that's not a problem as all the requests are just passed through. However, that is problematic for files opened for writing since those requests need to be handled by the backend. It's particularly bad for a file opened `O_RDWR` since `read` responses from the page cache are likely to be wrong. Instruct FUSE to use `direct-io` for those files so that the page cache is bypassed. 1. https://docs.kernel.org/filesystems/fuse-io.html Fixes: flatpak#5452 (cherry picked from commit c4738f8)
and others
Checklist
Flatpak version
1.15.4
What Linux distribution are you using?
Void Linux
Linux distribution version
Linux 6.1.34_1
What architecture are you using?
x86_64
How to reproduce
sudo xbps-install flatpakflatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepoflatpak install <any_application>Expected Behavior
An app will be installed without any problems.
Actual Behavior
Additional Information
I'm using void linux with glibc, gnome, pipewire and wayland.
This bug works with any app, not only the
discord-screenaudio(I've triedEpiphany,ExtensionManagerand etc.)Also I have tried to:
flatpak repairsudo flatpak repairflatpak repair --userflatpak unsinstall --unsuedflatpak updateflatpak update --appstreamsudo xbps-remove -R -O flatpak; sudo xbps-install flatpaksudo xbps-install -SuyThe text was updated successfully, but these errors were encountered: