Flatpak of Google Chrome? Where?
The Flatpak version
is unable to handle has some issues handling U2F USB keys (Yubikey, etc.).
I’ve now tested that and it works great.
Whenever I run
rpm-ostree status and see those versioned rpm fusion packages - I always wondered what would happen to them when i upgrade to SB 35 sometime in the future. I was expecting I might need to do some manual fix up…
I’m glad you’ve answered that for me ahead of time!
I’m curious though, what happens if we don’t “unpin” those packages before doing the SB 34 to 35 upgrade?
From memory, you get an error during the rebase.
It was necessary to replace the local package of rpmfusion in the same commit to avoid errors with rpm-ostree being unable to find the next releases (still-requested) rpmfusion-provided overlay packages.
The longer alternative was to reset overrides, rebase, add the new local packages and re-overlay packages.
Until now I was using:
rpm-ostree rebase fedora:fedora/34/x86_64/silverblue \ --uninstall rpmfusion-free-release-33-1.noarch \ --install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-34.noarch.rpm \ --uninstall rpmfusion-nonfree-release-33-1.noarch \ --install https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-34.noarch.rpm
Can confirm the tip by @siosm works beautifully. Tested on a SB34->SB35 upgrade. Thanks!
This looks sensible as a correct fix for this process. (rebasing layered rpm along the baseos).
But then you will have to reproduce on any rpmfusion packages that is installed via rpm-ostree (specially thoses that have any deps changes from the base fedora distribution).
So to me it sounds like the rpmfusion-*release rebase issue is the tree hiding the whole forest (you have a bigger problem behind). The google-chrome are not good example as they are distro agnostic.
If any ostree/Silverblue involved developer are kind enough to escalate to bugzilla.rpmfusion.org I’m sure we can draft a barely usable solution that can work as expected everywhere.
Thanks in advance.
I’m not sure I follow the issue here. Other packages installed from the rpm-fusion repos via
rpm-ostree install will be updated if needed during each system update as their versions are not pinned.
This workaround is only needed here as the initial installation from RPM packages is pinning the version of the packages.
$ sudo rpm-ostree update
Didn’t work for me somehow. Had done the above command with fedora 33. But after rebase to 36, the upgrade complained about rpmfusion-free-release-…36 not being found or something. Had to do a
and then add the version-numbered again.
Please always include the output of
rpm-ostree status and exact error logs, error messages and commands when you have issues.
Sorry, I did this and it worked, but I dont understand how.
1) How does ostree know what to do first? Doesnt it parse the command from the beginning to end? Does it know that it has to first install the new packages, then remove the the old .noarch ones, if so, how is it that “intelligent”?
2) Most important question: Another user asked this but the answer wasnt quite satisfactory - where do the versionless packages come from? They are NOT available on rpmfusion!
There are three packages available for each version (free/non-free) and here they are:
rpmfusion-nonfree-release.noarch : RPM Fusion (nonfree) Repository Configuration rpmfusion-nonfree-release-rawhide.noarch : RPM Fusion Rawhide nonfree repo definitions rpmfusion-nonfree-release-tainted.noarch : RPM Fusion nonfree Tainted repo definition
Thats it. No “rpmfusion-nonfree-release” with nothing else coming after the name, so let me repeat: Where do these packages come from? I googled too, but all I was getting for “versionless rpmfusion packages” was this forum post … I dont understand
Sorry for the bump in the old thread, but Id really like to understand, could you have a look at my last post? Thanks!
I will try to explain.
If you are referring to the step below, yes, rpm-ostree will parse it top to bottom.
Not sure what you are referring to when you say “first install the new packages”. But yes, before running the code above, you need to follow the instructions as mentioned:
As for your second question…
At first you have a fresh system - never had RPM Fusion installed before. You have no
rpmfusion-*.repo files installed in
/etc/yum.repos.d. Fedora does not host any rpmfusion .rpm packages in their repositories, therefore you need to fetch those directly from rpmfusion.org running:
sudo rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
So that fetches the .rpm file from the mirror and installs the contents; which are basically the
rpmfusion-*.repo files in
rpm-ostree tracks that there are overlays installed (of the rpmfusion rpms) - you can see them if you run
rpm-ostree status - it will say:
LayeredPackages: rpmfusion-free-release-34.0.3.noarch rpmfusion-nonfree-release-34.0.2.noarch
To understand the problem, let’s look at a completely different example: say you want to overlay
emacs. You would simply execute
rpm-ostree install emacs. The
emacs packages is sourced from the fedora-updates repo. The
fedora-updates.repo file in
/etc/yum.repos.d already accounts for the release (f34) and architecture (x86_64), so it will fetch from the repo mirrors the file
emacs-27.2-11.fc36.src.rpm. Notice now that if you run
rpm-ostree status to query the LayeredPackages it lists “emacs”, not “emacs-27.2-11.fc36.src.rpm”. When an upgrade is performed to the BaseCommit, the Layered Packages are queried again against the known repos, fetched, and upgraded.
Now going back to the RPM Fusion overlays. Why do those overlays have the “*-34.03.noarch” suffix? Because they weren’t queried against a repo using the base name (e.g. - “emacs” or “rpmfusion-free-release”), but rather we had to give it the explicit rpm source address and filename (https://mirrors.rpmfusion.org…noarch.rpm). We couldn’t query the base name because “rpmfusion-free-release” didn’t exist in any known/installed repos yet. And
rpm-ostree status lists the complete filename because it doesn’t know any better.
But once we installed it the first time, we now have the
rpmfusion-*.repo files installed in
/etc/yum.repos.d. And so we run the
rpm-ostree uninstall rpmfusion-free-release-34.0.3.noarch. This removes the Layered Package, but remember in ostree, changes aren’t committed until reboot! So the
rpmfusion-*.repo files still exist in
/etc/yum.repos.d. This lets us do the second part, which is the
rpm-ostree install rpmfusion-free-release. Now we are querying the repos using the base name, just like we did with “emacs”. And the repo that has that base name is the previously installed, and not-yet-uninstalled, rpmfusion-*.repo.
Now that all the pieces are in place: since the Layered Package is listed under the base name, not the explicit rpm file name, when an upgrade in performed, it will query the repos using the base name and correctly return the latest version appropriate for the system’s version and architecture.
Thank you for that very in-depth answer and that you took the time to write it - I understood now.
I tried to explain this myself, but failed, since I missed an important detail.
All layered packages are “versionless”, while the local one has a version number. If I didnt miss this, I wouldnt have scratched my head for two weeks
This solution works with a couple of modifications for Fedora Silverblue 36 users who upgraded from 35. Note that there’s a dash where a dot used to be, as well as the updated version number:
rpm-ostree update \ --uninstall rpmfusion-free-release-36-0.2.noarch \ --uninstall rpmfusion-nonfree-release-36-0.2.noarch \ --install rpmfusion-free-release \ --install rpmfusion-nonfree-release
Note: Check your RPM Fusion repo versions and adjust this command if needed before running it.
All this said, upgrading from 35 to 36 Beta with RPM Fusion repos required a lot more manual intervention than I like.
If I’m still on Silverblue when 37 comes out, I will be waiting until maybe a couple of weeks after the release before upgrading.
Can we have a version that verify which rpm NVRA are installed (layered ?) and
That so I can copy a “stable” version in the RPM Fusion wiki ? (referencing this post for credits).
Thanks in advance.
I’ve verified that the following suggestion works in a fresh Fedora Silverblue virtual machine:
# Install RPM Fusion repos $ sudo rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm $ reboot # Replace the versioned local packages by overlayed packages from the repo $ sudo rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release $ reboot
Note that this applies to all rpm-ostree variants of Fedora: Fedora Kinoite, Fedora IoT and Fedora CoreOS.
However, it’s more likely to be used on Fedora Silverblue and Kinoite thus listing those two would be great.
(post deleted by author)