@joefidler NOW you tell me!
On a slightly different tack, is it possible to rebase/downgrade to 31 if my old image has gone? Do I have to do a complete reinstall? Or is there an easier way?
@joefidler NOW you tell me!
Hi @mogplus8 - I’m just a community member and rely on reading other forum sections here or silverblue.fedoraproject.org for the project’s current status - I am not sure if Silverblue 32 is even out of rawhide yet or if it will release at the same time as Workstation 32.
Sorry @joefidler, the comment was meant to be tongue in cheek (is there an emoticon for that? There should be).
PS Turned out to be too easy. rpm-ostree rebase fedora:fedora/31/x86_64/silverblue
@mogplus8 Glad you got it resolved and all good. Cheers, Joe.
rpm-ostree admin pin 0
to keep e.g. the topmost install.
@tmstaedt I haven’t been able to find where this function is documented. I found one reference in the rpm-ostree man page, which talked about an install being “pinned”. By that, and your example, I’m guessing that a particular install can be set to never be deleted. Is this correct? If so I could “pin” every time I deploy a new install, and thus build up a list of many installs, and overcome my problem. Correct?
The actual command is:
ostree admin pin 0.
An example is found here (search for “How can I upgrade my system to the next major version”):
Sorry to hear you have been having such a time with F32SB. I had upgraded my system a bit ago from 31 to 32, and I too had rpmfusion repos enabled with the usual codec suspects installed. I found I had to remove the ref’s, and uninstall the repo rpm’s to be able to upgrade. The ref’s are enabled/disabled with
sudo ostree remote add/delete<ref><ref-url>. A quick way to remove ref’s is to delete their metadata files in
/etc/yum.repos.d then run
rpm-ostree cleanup -m then do
rpm-ostree update prior to rebasing to the new version. I did that approach, and had to uninstall the offending packages from rpm-fusion (free and non-free) after that I could do the rebase to the new version. Once the new version was booted into I re-enabled the repos and reinstalled the bits I wanted from them. I had this documented because of this topic you started here, so I could provide an outline in better detail of what the steps are and in what order. Would that be something of interest to you?
Does the rpm-ostree ex reset command accomplish the same thing as manually removing this layered packages and refs? What is the recommended approach?
This post describes how to use the reset command:
rpm-ostree reset command will remove any mutations of the base image that you have installed (layered packages) and return your system to the current base image as released from Fedora’s repo, no layered packages. It will not affect any user data or environment settings, aside from what removal of the layered packages would require. AFAIK this also means anything that the layered packages place in the user home dir. So when you re-install those layered packages usually preferences are still setup as you had them. I didn’t want to reset my system because of a few codecs, so I removed the ref’s (with ostree), deleted the metadata for the repos in /etc/yum.repos.d, did a cleanup on my image with
rpm-ostree cleanup -m then uninstalled the offending packages. I reboot at this point before I do the
rpm-ostree update, then follow that with another reboot and finally the rebase. I know there is a lot of talk around about the need to reboot or not but I apply this simple approach, if I make a change to rpm-ostree in some way, other than meta-data cleanup, I reboot.
As for the recommended approach, rpm-ostree is a variant of ostree, and ostree is the sysadmin command for Silverblue, when you need more control over your install than rpm-ostree gives. There is a lack of a clear documentation trail that I can point you to other than read the fedora system administrators guide for the release you are using, as this technology is becoming more relevant to the sysadmins so there is an increase of info there with each release.
In keeping with this topic’s thread, this link is to the administrators guide for rpm-ostree and this here is the link to the FAQ for Silverblue about upgrades/rollbacks/pinning commits. etc…
rpm-ostree ex is for the experimental commands and options, such as making your immutable OS mutable. I would strongly recommend against doing such unless you have specific need to, and understand the ramifications. You can just use
rpm-ostree reset <option> with the option of resetting layered, overrides, iniramfs, all. Or you can specify exactly what to remove with --uninstall, and you can even install overlayed packages with the same command.
Thanks for the info @jakfrost. I did not see the rpm-ostree reset in the man page, so I thought the ex option was needed. I am almost ready to pull the trigger on a rebase to 32 and wanted to make sure I did it the right way. Hopefully in the future this process can be improved to not need to remove the rpm-fusion packages and repos before a rebase. Are there significant technical reasons why this could not be automated?
I think the reasons are related to licensing from Fedora POV, plus the inevitable out-of-synch issue faced by contributing projects to the repo. Not all projects follow Fedora’s release cycle cadence. On the upside, Fedora contributors are regularly adding more FOSS versions of missing codecs for instance in the Fedora repo, this will eventually lead to better upgrade results for those of us forced to use the ‘non-compliant licensed’ bits in order to have a functioning DE.
rpm-ostree doesn’t just remove any layered packages, but also purges any overrides and even your generated initramfs!
I guess you didn’t read all of my comment. It can reset everything but it does have some granularity where you can specify only layered, overridden, initramfs, etc… Also you can install with the reset command if you desire.
You’re right, I must have missed that part.
I knew there must have been an option to specify particular targets, but I’m not on my Silverblue installation rn and didn’t bother looking up the manpages online.
Thanks for pointing it out.
I tend to try and get as much info into my comments, so they do get lengthy as a consequence. You are correct to point out that
rpm-ostree reset without options will reset everything except user data, which includes local initramfs.
They’re not particularly lengthy, especially considering the amount of info you pack into them, but they could probably use some formatting to be easier on the eyes.
Thanks for all these fantastic responses. They have certainly increased my level of knowledge, both about SB and where to look for more information. Just another result of what a great community provides, and what a pleasure it is to be part of it.