Bazzite shows that terra-release is indeed installed
Assuming it is disabled (as happened in https://github.com/ublue-os/bazzite/issues/2580)
Interesting conflict; as these seem to be at odds with each other. I wonder what’s up. If it’s indeed disabled, then I would like to apologize for causing any confusion. FWIW, I may have been mislead by Terra’s own documentation. I suppose it might be outdated.
Anyhow, perhaps we can undertake the steps to uninstall terra-release (even if it’s not there) and (re)install it.
Uninstalling terra-release
If terra-release is layered[1], then we’d have to start with rpm-ostree uninstall terra-release. Afterwards, to delete the Terra repository, even if it’s not even there[2]: sudo rm -rf /etc/yum.repos.d/terra.repo
(Re)installing terra-release
To (re)install terra-release (as per its own instructions):
First evoke the following command:
curl -fsSL https://github.com/terrapkg/subatomic-repos/raw/main/terra.repo | pkexec tee /etc/yum.repos.d/terra.repo
And then, evoke this one: sudo rpm-ostree install terra-release . I’m unsure if sudo is required. Personally, first I’ll do is without sudo. Only after it fails due to permissions will I do it with sudo.
A reboot is probably required for it to take effect. Hence, try evoking rpm-ostree install throne only after performing a reboot.
You can check this with
rpm-ostree status. If it is, you will find it afterLayeredPackages:. If it’s not, you should not evokerpm-ostree uninstall terra-release, as it wouldn’t get through anyways. ↩︎If
ls /etc/yum.repos.d/ | grep "terra"doesn’t yield anything, then you may skip this. But evoking the command to delete something that’s not there, isn’t bad or anything. ↩︎


I’m glad to hear that you found the most egregious culprit. Hopefully you’ll be able to get it to work after your subscription list ‘functions’ (again). (I’m honestly completely oblivious of what this software is or how it works.)
Though, if you allow me, I would like to give some comments. So, without further ado.
Hmm…, curious. I would think that it shouldn’t even (necessarily) require anything like that. And, if it does, perhaps the maintainer/contributor should be addressed in hopes of resolving the issue; I’m sure they can figure out a workaround (or so).
😅. This is actually a very nuanced topic:
/usrcompared to its upstream; i.e. Fedora Atomic. So, there is a supported way of doing this in order to create an image with the desired changes to/usr. If you got any such needs, consider taking a look at this page of Bazzite’s documentation./usr/etc,/usr/shareet cetera; one could instead make changes to the content of folders like/etc~/.local/shareet cetera./usronce and would like for said changes to not persist after a reboot, then commands likerpm-ostree usroverlayandbootc usr-overlayare worth mentioning.So, to be clear: while it is true that Fedora Atomic does not like/support making changes to
/usrat runtime, it’s not like it’s necessarily limiting you if you really desire to make changes to/usr. Even if non of the methods 100% function like howsudo <input change> /usr/<some content>would on a traditional distro*.It has been my pleasure 😊!