rpm-ostree upgrade error: File "ac/859321dfe787f24d016e20e585da522713d84edbf0f6fb4e021543ece37264.file to __init__.cpython-312.opt-1.pyc" exists already (stuck on 40.20240822.0) #590
Comments
|
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) |
|
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 |
|
Same issue here with Silverblue. The GNOME system update claims to have worked, but it did not actually succeed. |
|
Same issue here with Kinoite. No update is currently possible with discover or in console. |
|
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 |
|
That's what worked for me, but i'm using Silverblue. |
|
rpm-ostree reset -l -o -r This is well known, I didn't actually want to do this. Thanks anyway. |
|
I can confirm that I had the same issue on Sericea in fixed it by removing @architectlin maybe in your case it is still pulled as a dependency of other packages? |
|
yes just testing after rpm-ostree reset -l -o -r The problem also seems to occur when trying to install Steam. |
|
Oh yeah, I checked again and indeed I am still on |
rugk
changed the title
|
So if |
|
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 |
|
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. |
|
I solved by moving to the full rpmfusion ffmpeg with the following command: |
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. |
|
Same issue here. Not sure what package is even causing it as the system I have is pretty much a base install. |
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.
@RobotRoss You can run |
|
This is a significant issue that could be addressed if Fedora established an official or semi-official repository for Nvidia drivers and codecs. These components are essential for many users, and even Debian has managed to include them in their offerings. |
|
Why |
travier
added
f40
|
I had the very same issue and was also stuck with an inactive request with ffmpeg-free. |
@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 |
|
Thank you for your question! 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. 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. |
|
I wasted a lot of time on this last weekend. Here's what I found out:
|
|
I solve this issue by manually installing This is my step to be able to install steam:
Notes: all step above are started from clean slate rpm-ostree (reset using 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! |
|
I got new errors now when trying to upgrade: Resolving dependencies… done package libavcodec-freeworld-6.1.1-8.fc40.i686 from rpmfusion-free requires libva.so.2, but none of the providers can be installed |
|
So it looks like the root cause of the issue is that both x86_64 & i686 libstdc++ packages ship the same Python bits: This 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
added
upstream
|
Could folks here give us the output of |
|
Never mind, I can reproduce it locally with: |
|
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. |
😅 It was only available in the container images and that does not impact layering in containers 🙂 so this slipped under the radar. |
|
This would be fixed with coreos/rpm-ostree#5019 (both ways - we wouldn't be doing it separately in each base image, and it would fix client side layering ensuring that the |
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. |
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. |
|
I suspect I could have just remove steam and the upgrade might have completed, keeping the full ffmpeg layered. |
|
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. |
|
Thank you, please remember to test future changes on Silverblue as well |
Can confirm it's now propagated. |
|
This can be marked as solved. Installing steam from fresh base is now works. |
…atch" This is causing issues when layering packages from different architectures that include Python scripts. See: fedora-silverblue/issue-tracker#590 See: https://bugzilla.redhat.com/show_bug.cgi?id=2308663 See: https://gitlab.com/fedora/bootc/tracker/-/issues/3 See: https://gitlab.com/fedora/ostree/sig/-/issues/52 This reverts commit 36c70e0.
|
I can confirm libavcodec-freeworld can now be installed without issues |
|
Thanks for the confirmation! |
|
Also |
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.
The text was updated successfully, but these errors were encountered: