I have Bazzite running on a BC-250 machine. A few weeks ago, I made some changes using rpm-ostree related to zram and swap. I had assumed that, because I used rpm-ostree, the changes would become part of the “tree” and I could rollback to the original settings. But when I went to look at Bazzite’s rollback tools, it seemed solely focused on rolling back to previous official releases, and I couldn’t find any reference to the specific changes I made.


Could you be more transparent and/or elaborate in this regard? Like, what did you actually do?
FWIW, I’ve been on Fedora Atomic since before Bazzite’s existence, but I’ve never once considered using
rpm-ostreeto make changes to zram and swap. So, I’m a bit confused. To be clear, it’s perfectly possible that what you did is 100% legit, but that it just happened to expose a gap in my knowledge.Basically, while
rpm-ostreedoes offer git-like control on your base system; hence, why it’s so powerful to begin with. It does not keep more than two deployments around; at least, by default.If you would like to keep around a specific deployment (for whatever reason), you can do so with the
ostree admin pin <insert number>command. The git-like control also enables you to keep track of:/etc; invokeostree admin config-diffto see what files have been added or modified since installationrpm-ostree statusKeeping track is cool and all, but its usefulness is in full display with powerful applications such as:
rpm-ostree reset; this basically removes all permutations. That is, two people on the same image, will have the identical base system after this. (Note that this still isn’t as powerful as a factory reset. For that, refer to this issue tracker onbootc[1].)Finally, the git-like structure ensures actual reversibility. On most other systems,
installing A -> installing B -> uninstalling Awill yield a different state than justinstalling B. Withrpm-ostree, the base system between the two will be identical.For completeness’ sake, I’ve used “base system” above to just mean the contents of
/usrand/etc(and maybe some other subdirectories of/). Crucially, the contents of/varare not part of the “base system”.On that note,
bootc’s model is arguably better suited if you’re just interested in finding back references to changes you made in the past. Granted,bootcoffers a hefty amount of freedom in how you’d approach this and might be overwhelming for now. FWIW, both Bazzite and this are products of this. ↩︎The instructions I followed are in the description of the following video. A lot of what happens with this project is hidden away on Discord servers and I suspect what makes it out to the web has gone through the slop filter.
https://m.youtube.com/watch?v=A6juAoY70aU
The bottom line is that I thought this might help with random crashes I’d been having with a particular emulator. Unfortunately it had the opposite effect and the same emulator now consistently hard-locks the system after this “fix”.
Thank you! This is actually very helpful! And we can definitely reverse some of their doing 😉. Below I will repeat the invoked commands and provide some context/explanation. So, without further ado.
sudo rpm-ostree kargs --append-if-missing=zswap.enabled=1 sudo rpm-ostree kargs --append-if-missing=zswap.max_pool_percent=25 sudo rpm-ostree kargs --append-if-missing=zswap.compressor=lz4 sudo rpm-ostree kargs --append-if-missing=systemd.zram=0The commands found above were used to change the kernel arguments through
rpm-ostree. You can still find these back withrpm-ostree kargs --editor. You can even outright remove them, then and there. It’s also possible to literally revert those commands by invoking the following:sudo rpm-ostree kargs --delete-if-present=zswap.enabled=1 sudo rpm-ostree kargs --delete-if-present=zswap.max_pool_percent=25 sudo rpm-ostree kargs --delete-if-present=zswap.compressor=lz4 sudo rpm-ostree kargs --delete-if-present=systemd.zram=0Unfortunately, I don’t have any experience with this.
sudo swapoff -a sudo rm -rf /var/swap sudo semanage fcontext -a -t var_t "/var/swap(/.*)?" sudo restorecon -Rv /var/swap sudo btrfs filesystem mkswapfile --size 32G /var/swap/swapfile sudo semanage fcontext -a -t swapfile_t "/var/swap/swapfile" sudo restorecon -v /var/swap/swapfile sudo swapon -aBasically, the commands found literally above affect the contents of
/var. As such, they’re outside of the ‘jurisdiction’ ofrpm-ostree. Reverting these is the same as on any other Linux system.The following commands change the contents of
/etc. As such, they’re being tracked and can be reverted to their original states. Though, I’m not sure if it’s possible to revert them back to their respective versions without those changes.I’ll be honest with ya. I don’t know what this one does 😅. I have used
sedin the past but wasn’t able to decipher this one. FWIW, it tries to make some changes to/etc/fstab. And, if I’d have to make a guess, I think it deletes any lines that contain/var/swap/swapfile.This added some text to
/etc/fstab. To revert it, go to/etc/fstab, and remove/var/swap/swapfile none swap defaults,nofail 0 0This created a file named
99-swappiness.confand placed it to/etc/sysctl.d/. As such, a simplesudo rm -rf /etc/sysctl.d/99-swappiness.confsuffices.This was an optional command. If you did have to invoke it, then you should find
policycoreutils-python-utilswhen invokingrpm-ostree status. It should be mentioned as a layered package.To undo it, simply invoke
rpm-ostree uninstall policycoreutils-python-utils.