Closed rugk closed 2 weeks ago
rugk
commented
3 weeks ago Okay strange, the update via GNOME Software worked, afterwards. Log: https://gitlab.gnome.org/-/project/558/uploads/124f1c487dbd0d92029df86e22d60da4/gnome-software.log (used in a actually-not-so-related issue)
jkrogers9862
commented
3 weeks ago I am encountering this same issue. I have attempted the same update that @rugk mentions from the Discover app on KDE and it does not change anything. I cannot update my system at all currently. Due to this issue, i have removed all packages i have recently installed and still no success. This seems to be a real issue as I am using kinoite not silverblue in this case. I have also noted that ublue-os also experiences this issue as it derives from upstream silverblue. RPM OSTree Failure When Layering Steam Atop Vauxite
dradice
commented
3 weeks ago Same issue here with Silverblue. The GNOME system update claims to have worked, but it did not actually succeed.
architectlin
commented
3 weeks ago Same issue here with Kinoite. No update is currently possible with discover or in console.
TugaCoder
commented
3 weeks ago The issue lies in the libavcodec-freeworld package. Remove it and you'll be able to run updates again.
rpm-ostree remove libavcodec-freeworld && systemctl reboot
architectlin
commented
3 weeks ago rpm-ostree remove libavcodec-freeworld && systemctl reboot error: Package/capability 'libavcodec-freeworld' is not currently requested
TugaCoder
commented
3 weeks ago That's what worked for me, but i'm using Silverblue.
You can always try the nuclear option
rpm-ostree reset -l -o -r
That will nuke all the stuff you've layered, maybe then you'll be able to update.
architectlin
commented
3 weeks ago rpm-ostree reset -l -o -r
This is well known, I didn't actually want to do this. It should be the last resort.
Thanks anyway.
Fale
commented
3 weeks ago I can confirm that I had the same issue on Sericea in fixed it by removing libavcodec-freeworld.
@architectlin maybe in your case it is still pulled as a dependency of other packages?
architectlin
commented
3 weeks ago yes just testing after rpm-ostree reset -l -o -r the system will install the updates
The problem also seems to occur when trying to install Steam.
rugk
commented
3 weeks ago Oh yeah, I checked again and indeed I am still on 40.20240822.0 despite what GNOME Software claims.
rugk
commented
3 weeks ago So if libavcodec-freeworld 6.1.1-15.fc40 -> 6.1.2-2.fc40 is really the issue, rpm-ostree upgrade --uninstall libavcodec-freeworld should do the upgrade in one step (only one reboot required). This also seems to work for me.
rugk
commented
3 weeks ago Indeed, this works, and trying to reinstall it afterwards, causes the error:
rpm-ostree install libavcodec-freeworld
Checking out tree 7ea3754... done
Enabled rpm-md repositories: fedora rpmfusion-free fedora-cisco-openh264 updates rpmfusion-free-updates updates-archive
Importing rpm-md... done
rpm-md repo 'fedora' (cached); generated: 2024-04-14T18:51:11Z solvables: 74881
rpm-md repo 'rpmfusion-free' (cached); generated: 2024-04-20T12:11:51Z solvables: 422
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2024-03-12T11:45:42Z solvables: 3
rpm-md repo 'updates' (cached); generated: 2024-08-24T01:44:57Z solvables: 25300
rpm-md repo 'rpmfusion-free-updates' (cached); generated: 2024-08-22T08:59:43Z solvables: 149
rpm-md repo 'updates-archive' (cached); generated: 2024-08-21T03:52:59Z solvables: 36142
Resolving dependencies... done
Will download: 96 packages (101,6 MB)
Downloading from 'rpmfusion-free-updates'... done
Downloading from 'updates'... done
Downloading from 'fedora'... done
Downloading from 'rpmfusion-free'... done
Importing packages... done
Applying 1 override and 371 overlays
Processing packages... done
error: Checkout libstdc++-14.2.1-1.fc40.i686: Hardlinking ac/859321dfe787f24d016e20e585da522713d84edbf0f6fb4e021543ece37264.file to __init__.cpython-312.opt-1.pyc: Die Datei existiert bereitsAlso reported it to rpm-fusion now in https://bugzilla.rpmfusion.org/show_bug.cgi?id=7037
jkrogers9862
commented
3 weeks ago The proposed solution does not work for me as libavcodec-freeworld is not currently installed.
I am still unable to install wine. I have converted to using Bottles for what I can but some things don't work in the container.
Fale
commented
3 weeks ago I solved by moving to the full rpmfusion ffmpeg with the following command:
sudo rpm-ostree override remove ffmpeg-free libavcodec-free libavfilter-free libavformat-free libavdevice-free libavutil-free libswscale-free libpostproc-free libswresample-free --install ffmpeg --install ffmpegthumbnailerI solved by moving to the full rpmfusion ffmpeg with the following command:
sudo rpm-ostree override remove ffmpeg-free libavcodec-free libavfilter-free libavformat-free libavdevice-free libavutil-free libswscale-free libpostproc-free libswresample-free --install ffmpeg --install ffmpegthumbnailer
We shouldn't be having to remove packages we rely on to be able to update our systems. I also had to remove almost all of those packages to update. This seems to be a recurring problem creeps back up once in a while. I have found previously closed issues noting the exact same error from around Fedora Silverblue 32 and 34.
This probably has a lot to do with RPMFusion not syncing builds with Fedora upstream if I am not mistaken. The broken rpm builders probably need to rebuild against a new build of gcc-c++ which includes the library in question. Fedora probably pushed the updated dependency and RPMFusion which is still built against the older library breaks because of the read-only file system. This isn't a problem on non-immutable systems because under normal circumstances it would just overwrite the hardlink after checking a version.
I am more curious why package maintainers are creating hardlinks this way though? It seems like a bad practice, unless I am misunderstanding something about Silverblue.
RobotRoss
commented
3 weeks ago Same issue here. Not sure what package is even causing it as the system I have is pretty much a base install.
rugk
commented
3 weeks ago I am more curious why package maintainers are creating hardlinks this way though?
Well ask them. if you want to ask the RPMFusion people maybe do it in this ticket. They closed it as it's rpm-ostree's/Silverblue's fault.
Not sure what package is even causing it as the system I have is pretty much a base install.
@RobotRoss You can run rpm-ostree status -v to find the currently layered packages (or rpm-ostree status -v -b for the current boot directly).
tsilvs
commented
3 weeks ago Why ostree & rpn-ostree can't handle such hardlinks? Is there a particular reason behind this design?
bruhmich
commented
3 weeks ago I had the very same issue and was also stuck with an inactive request with ffmpeg-free. I did rpm-ostree uninstall ffmpeg-free and after rebooting I could finally update. Fact is that right now I haven't anymore neither ffmpeg nor libavcodec, but I still can play .mkv and .mt2s and listen to .wav, .flac and .mp3 files so I think I can live with that. For ready reference this is the output of rpm-ostree status:
● fedora:fedora/40/x86_64/kinoite
Version: 40.20240826.0 (2024-08-26T00:47:40Z)
BaseCommit: c392f55636340188e68eb51984d47eca5c54bc0ed0a5546df67adfc67ab00ae5
GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
RemovedBasePackages: firefox firefox-langpacks 129.0.2-1.fc40
LayeredPackages: beets beets-doc beets-plugins cdparanoia gwenview java libva-utils libxcrypt-compat mp3gain msitools
perl-Image-ExifTool powertop pycdio qt-heif-image-plugin rpmfusion-free-release rpmfusion-nonfree-release solaar
sox stacer tuned-utils whipper
fedora:fedora/40/x86_64/kinoite
Version: 40.20240821.0 (2024-08-21T01:01:38Z)
BaseCommit: 319076423a90a3de2cd75e9e439359218f3a5bd056dc9bbca6e5d98b8001c679
GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
RemovedBasePackages: firefox firefox-langpacks 129.0-1.fc40
LayeredPackages: beets beets-doc beets-plugins cdparanoia gwenview java libva-utils libxcrypt-compat mp3gain msitools
perl-Image-ExifTool powertop pycdio qt-heif-image-plugin rpmfusion-free-release rpmfusion-nonfree-release solaar
sox stacer tuned-utils whipper
fedora:fedora/36/x86_64/kinoite
Version: 36.20221121.0 (2022-11-21T00:50:18Z)
BaseCommit: 1716f0898607259aa8a3763fa5ced8a23aa136750177ceb8ad8d97a3a05d349b
GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
LayeredPackages: kshisen solaar stacer unrar yacreader
LocalPackages: rpmfusion-free-release-36-1.noarch rpmfusion-nonfree-release-36-1.noarch
Pinned: yesRight now I don't have anymore neither ffmpeg nor libavcodec, but I still can play
.mkvand.mt2sand listen to.wav,.flacand.mp3
@bruhmich Do you by any chance know why you are still able to play this media? Are any of your layered packages media-related?
And could you test playing videos in Firefox (even though I see you have it removed) or Librewolf? For example, on x.com (Twitter) and YouTube (not all videos don't work without RPM Fusion codecs though)
bruhmich
commented
3 weeks ago Thank you for your question! You led me to discover that I wrote a misguiding comment... duh! I apologize. Actually I DO have ffmpeg-free installed. I just ran the command to uninstall it in order to get rid of an inactive request, but further to reading your question I re-ran rpm -q for the sake of checking and this is the output I got:
bruno@Host-002:/var/home/bruno$ rpm -q ffmpeg-free
ffmpeg-free-6.1.1-19.fc40.x86_64
bruno@Host-002:/var/home/bruno$ rpm -q libavcodec-freeworld
package libavcodec-freeworld is not installed
bruno@Host-002:/var/home/bruno$Apart from that, I do have Firefox. I just have removed the original base system version to replace it with the flathub package which has less issues and therefore can watch videos on youtube, vimeo and the alike.
I watch video files with vlc which has the appropriate codecs licensed for free distribution and use and therefore should get me covered anyway.
As for audio, .flac is an open source format so no problem here whilst .mp3 however being a proprietary format can be used without licensing fees since the patents related to encoding and decoding expired in 2017. As for .wav I'm covered by either vlc and, now obviously, ffmpeg.
By the way, it seems that in my very personal case getting rid of the ffmpeg-free inactive request somehow fixed the update-locking issue, but it might just be a coincidence. Maybe in the meantime the maintainers at Fedora and RPMFusion might have solved the issue.
mpolden
commented
2 weeks ago I wasted a lot of time on this last weekend. Here's what I found out:
libavcodec-freeworld from RPMFusion can cause version conflicts at any time it becomes out of sync with the ffmpeg-free version provided by Fedoraffmpeg-free is preinstalled on Atomic variants, at least Silverblue and Kinoite. RPMFusion recommends installing ffmpeg to avoid potential incompatiblities, but this requires adding an ugly override that removes ffmpeg-free and its libraries (I did rpm-ostree override remove ffmpeg-free $(rpm -qR ffmpeg-free | xargs rpm -q --whatprovides | grep -o '^lib.*-free' | sort -u) --install ffmpeg)On upgrade/install, rpm-ostree helpfully tries to resolve the version conflict in 1 by installing the i686 variant of libavcodec-freeworld instead. This then pulls in a number of 32-bit dependencies, where one them fails with a hardlinking error, as described in https://github.com/fedora-silverblue/issue-tracker/issues/590#issue-2481555920.
I suppose layering libavcodec-freeworld.x86_64 (with explict arch) could force rpm-ostree upgrade to fail with the expected error (version incompatibility with ffmpeg-free), but I haven't tested this. This would be slightly better, upgrades would still be broken, but the reason would at least make sense
arutama
commented
2 weeks ago I solve this issue by manually installing libstdc++.i686. I suspect this is caused by both architecture package (x64 and i686) setting up the exact same hardlink and silverblue blocking this. Silverblue has hard rule to block package touching other package file.
This is my step to be able to install steam:
/updates/40/Everything/x86_64/Packages/l/ and download libstdc++ i686 package. For example, here I use kernel.org mirror. Try several mirror as some mirror has limited bandwidth or have bad routing connection to your ISP.
wget https://mirrors.kernel.org/fedora/updates/40/Everything/x86_64/Packages/l/libstdc%2B%2B-14.2.1-1.fc40.i686.rpm--force-replacefiles
rpm-ostree install --force-replacefiles libstdc++-14.2.1-1.fc40.i686.rpmNotes: all step above are started from clean slate rpm-ostree (reset using rpm-ostree reset -ol).
Hope this help.
jkrogers9862
commented
2 weeks ago I solve this issue by manually installing
libstdc++.i686. I suspect this is caused by both architecture package (x64 and i686) setting up the exact same hardlink and silverblue blocking this. Silverblue has hard rule to block package touching other package file.This is my step to be able to install steam:
1. Find a fedora mirror nearby. Look here: https://mirrormanager.fedoraproject.org/ - Choose your version. For me, I go to version 40 x64 mirror list https://mirrormanager.fedoraproject.org/mirrors/Fedora/40/x86_64 2. Go to `/updates/40/Everything/x86_64/Packages/l/` and download `libstdc++` i686 package. For example, here I use kernel.org mirror. Try several mirror as some mirror has limited bandwidth or have bad routing connection to your ISP.wget https://mirrors.kernel.org/fedora/updates/40/Everything/x86_64/Packages/l/libstdc%2B%2B-14.2.1-1.fc40.i686.rpm3. Install it manually from local file with `--force-replacefiles`rpm-ostree install --force-replacefiles libstdc++-14.2.1-1.fc40.i686.rpm4. Once installed, go ahead and install steam.Notes: all step above are started from clean slate rpm-ostree (reset using
rpm-ostree reset -ol).Hope this help.
This worked like a charm, I can now reinstall wine. I don't like that I will now have to keep up with updates on this package until a proper fix is implemented. I hope this gets resolved quickly
Thanks!
travier
commented
2 weeks ago So it looks like the root cause of the issue is that both x86_64 & i686 libstdc++ packages ship the same Python bits:
$ rpm -ql libstdc++-14.2.1-1.fc40.x86_64
/usr/lib/.build-id
/usr/lib/.build-id/79
/usr/lib/.build-id/79/db3efd5f1273ca8c42abd22d1d9fd63cffe57c
/usr/lib64/libstdc++.so.6
/usr/lib64/libstdc++.so.6.0.33
/usr/share/gcc-14
/usr/share/gcc-14/python
/usr/share/gcc-14/python/libstdcxx
/usr/share/gcc-14/python/libstdcxx/__init__.py
/usr/share/gcc-14/python/libstdcxx/__pycache__
/usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.opt-1.pyc
/usr/share/gcc-14/python/libstdcxx/__pycache__/__init__.cpython-312.pyc
/usr/share/gcc-14/python/libstdcxx/v6
/usr/share/gcc-14/python/libstdcxx/v6/__init__.py
/usr/share/gcc-14/python/libstdcxx/v6/__pycache__
/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/__init__.cpython-312.opt-1.pyc
/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/__init__.cpython-312.pyc
/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-312.opt-1.pyc
/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/printers.cpython-312.pyc
/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-312.opt-1.pyc
/usr/share/gcc-14/python/libstdcxx/v6/__pycache__/xmethods.cpython-312.pyc
/usr/share/gcc-14/python/libstdcxx/v6/printers.py
/usr/share/gcc-14/python/libstdcxx/v6/xmethods.py
/usr/share/gdb
/usr/share/gdb/auto-load
/usr/share/gdb/auto-load/usr
/usr/share/gdb/auto-load/usr/lib64
/usr/share/gdb/auto-load/usr/lib64/__pycache__
/usr/share/gdb/auto-load/usr/lib64/__pycache__/libstdc++.so.6.0.33-gdb.cpython-312.opt-1.pyc
/usr/share/gdb/auto-load/usr/lib64/__pycache__/libstdc++.so.6.0.33-gdb.cpython-312.pyc
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.33-gdb.pyThis was likely triggered here by:
One option would be to split the architecture independent Python bits in a noarch subpackage that both arch dependent packages can depend on.
Specfile https://src.fedoraproject.org/rpms/gcc/blob/rawhide/f/gcc.spec#_2888.
travier
commented
2 weeks ago travier
commented
2 weeks ago Could folks here give us the output of rpm -qi libstdc++.x86_64 and the version of the i686 one in the rpm-ostree error output?
travier
commented
2 weeks ago Never mind, I can reproduce it locally with:
$ rpm -qi libstdc++.x86_64
Name : libstdc++
Version : 14.2.1
Release : 1.fc40
...
error: Checkout libstdc++-14.2.1-1.fc40.i686: Hardlinking ac/859321dfe787f24d016e20e585da522713d84edbf0f6fb4e021543ece37264.file to __init__.cpython-312.opt-1.pyc: File existsOK, the "real" source of the issue is https://pagure.io/workstation-ostree-config/pull-request/556. I'll revert that asap.
travier
commented
2 weeks ago jkrogers9862
commented
2 weeks ago OK, the "real" source of the issue is https://pagure.io/workstation-ostree-config/pull-request/556. I'll revert that asap.
Anyone else see the irony behind the comment made in that "It has been available for a month and no one has complained"?
Anyway, reverting it is fine but it was made for a reason. Is there a course of action on splitting the python out as a separate dependency? I'm not a maintainer of those packages but we live in an age of reducing duplicate code, though I guess it isn't a discussion for this thread. I still think an action needs to be made.
travier
commented
2 weeks ago OK, the "real" source of the issue is pagure.io/workstation-ostree-config/pull-request/556. I'll revert that asap.
Anyone else see the irony behind the comment made in that "It has been available for a month and no one has complained"?
😅 It was only available in the container images and that does not impact layering in containers 🙂 so this slipped under the radar.
cgwalters
commented
2 weeks ago This would be fixed with https://github.com/coreos/rpm-ostree/pull/5019 (both ways - we wouldn't be doing it separately in each base image, and it would fix client side layering ensuring that the .pyc files both have canonicalized timestamps)
travier
commented
2 weeks ago Anyway, reverting it is fine but it was made for a reason. Is there a course of action on splitting the python out as a separate dependency? I'm not a maintainer of those packages but we live in an age of reducing duplicate code, though I guess it isn't a discussion for this thread. I still think an action needs to be made.
The long term fix for ostree archive's mtime modification results in slower python execution is to move to pure composefs checkouts. The first step for that is the Enabling composefs by default for Atomic Desktops change, tracked in atomic/sig#35.
jkemp814
commented
2 weeks ago I solved by moving to the full rpmfusion ffmpeg with the following command:
sudo rpm-ostree override remove ffmpeg-free libavcodec-free libavfilter-free libavformat-free libavdevice-free libavutil-free libswscale-free libpostproc-free libswresample-free --install ffmpeg --install ffmpegthumbnailer
I am already using the full ffmpeg package and still get the exact error message. I have to remove all overrides to upgrade the system. This had happened over the last two years. I also have posted to bugzilla over a year also and nothing has changed to fix it. I prefer the full ffmpeg package. It plays high profile videos file much better, than the ffmpeg-free. ffmpeg-free skips and sputters on high-profile, large video files.
I have to remove overrides and steam, then do upgrades, but steam will not re-install. I can perform the overrides to get ffmpeg and ffmpegthumbnailer re-installed.
jkemp814
commented
2 weeks ago I suspect I could have just remove steam and the upgrade might have completed, keeping the full ffmpeg layered.
travier
commented
2 weeks ago Everything is now merged and should land in tomorrow's update. A "normal" update should work but I haven't had the time to test that.
arutama
commented
2 weeks ago $ rpm-ostree update
⠂ Receiving metadata objects: 1/(estimating) 65 bytes/s 196 bytes... 2 metadata, 0 content objects fetched; 788 B transferred in 4 seconds; 0 bytes content written
Receiving metadata objects: 1/(estimating) 65 bytes/s 196 bytes... done
Checking out tree 6c1a2b1... done
Enabled rpm-md repositories: fedora-cisco-openh264 rpmfusion-free-updates rpmfusion-free rpmfusion-nonfree-updates rpmfusion-nonfree fedora rpmfusion-nonfree-nvidia-driver updates tailscale-stable nvidia-container-toolkit updates-archive
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2024-03-12T11:45:42Z solvables: 3
rpm-md repo 'rpmfusion-free-updates' (cached); generated: 2024-08-28T18:10:06Z solvables: 154
rpm-md repo 'rpmfusion-free' (cached); generated: 2024-04-20T12:11:51Z solvables: 422
rpm-md repo 'rpmfusion-nonfree-updates' (cached); generated: 2024-08-28T18:37:47Z solvables: 82
rpm-md repo 'rpmfusion-nonfree' (cached); generated: 2024-04-20T12:18:23Z solvables: 194
rpm-md repo 'fedora' (cached); generated: 2024-04-14T18:51:11Z solvables: 74881
rpm-md repo 'rpmfusion-nonfree-nvidia-driver' (cached); generated: 2024-08-30T10:24:56Z solvables: 16
rpm-md repo 'updates' (cached); generated: 2024-08-30T02:02:24Z solvables: 25733
rpm-md repo 'tailscale-stable' (cached); generated: 2024-08-29T19:19:24Z solvables: 108
rpm-md repo 'nvidia-container-toolkit' (cached); generated: 2024-07-30T08:32:14Z solvables: 75
rpm-md repo 'updates-archive' (cached); generated: 2024-08-21T03:52:59Z solvables: 36142
Resolving dependencies... done
Applying 9 overrides and 174 overlays
Processing packages... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Upgraded:
buildah 1.37.0-1.fc40 -> 1.37.1-1.fc40
microcode_ctl 2:2.1-61.1.fc40 -> 2:2.1-61.2.fc40
Removed:
add-determinism-0.3.5-1.fc40.x86_64
Run "systemctl reboot" to start a rebootCan confirm it's now propagated.
arutama
commented
2 weeks ago This can be marked as solved. Installing steam from fresh base is now works.
TugaCoder
commented
2 weeks ago I can confirm libavcodec-freeworld can now be installed without issues
travier
commented
2 weeks ago Thanks for the confirmation!
rugk
commented
2 weeks ago Also rpm-ostree upgrade --install libavcodec-freeworld seems to work for me as a shortcut, so you don't need two restarts, if you've previously uninstalled.
To Reproduce
Started update with GNOME SOftware, as usual it takes endlessly… (I have let it run for several minutes!) So I started
rpm-ostree upgradevia the console, which usually fails with either that rpm-ostree is already running (then I need to kill GNOME Software) or well... it's already done:The update to be installed is this:
Expected behavior No unclear errors, please.
Screenshots N/A
OS version:
Additional context Seeing the rpm-ostree error, maybe GNOME Software did actually work and it's layered already? Though,
I can close and re-open GNOME Software and all I see is it loading, as usual:
Also note I am currently in a quite unstable/bad network.