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=0

The commands found above were used to change the kernel arguments through rpm-ostree. You can still find these back with rpm-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=0

sudo rpm-ostree initramfs --enable --arg=--add-drivers --arg=lz4

Unfortunately, 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 -a

Basically, the commands found literally above affect the contents of /var. As such, they’re outside of the ‘jurisdiction’ of rpm-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.

sudo sed -i '\|/var/swap/swapfile|d' /etc/fstab

I’ll be honest with ya. I don’t know what this one does 😅. I have used sed in 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.

echo "/var/swap/swapfile none swap defaults,nofail 0 0" | sudo tee -a /etc/fstab

This added some text to /etc/fstab. To revert it, go to /etc/fstab, and remove /var/swap/swapfile none swap defaults,nofail 0 0

echo "vm.swappiness=120" | sudo tee /etc/sysctl.d/99-swappiness.conf

This created a file named 99-swappiness.conf and placed it to /etc/sysctl.d/. As such, a simple sudo rm -rf /etc/sysctl.d/99-swappiness.conf suffices.

sudo rpm-ostree install policycoreutils-python-utils

This was an optional command. If you did have to invoke it, then you should find policycoreutils-python-utils when invoking rpm-ostree status. It should be mentioned as a layered package.

To undo it, simply invoke rpm-ostree uninstall policycoreutils-python-utils.

Bazzite’s messaging has merit, but we’d be making a mistake by regarding it as absolute. It makes more sense to take them as carefully written guide lines for a specific audience.

Furthermore. with all due respect, but OP’s writing doesn’t imply installing/managing software with rpm-ostree. Which, is actually the subject of the documentation entry you quoted. As such, I think you might have misunderstood them.

Youre breaking a core tenant of immutable distros by installing system level packages.

Finally, FWIW, I absolutely disagree with the above. The page you quoted from seems to agree with me on this: “Layering packages are mostly intended for system-level applications, libraries, and other dependencies.”

I made some changes using rpm-ostree related to zram and swap

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-ostree to 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.

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.

Basically, while rpm-ostree does 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:

• the changes applied to /etc; invoke ostree admin config-diff to see what files have been added or modified since installation
• layered packages; simply invoke rpm-ostree status

Keeping 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 on bootc^[1].)

Finally, the git-like structure ensures actual reversibility. On most other systems, installing A -> installing B -> uninstalling A will yield a different state than just installing B. With rpm-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 /usr and /etc (and maybe some other subdirectories of /). Crucially, the contents of /var are not part of the “base system”.

Aight. We seem to have found the culprit. Hopefully it will be fixed soon.|

I mean why would it say a stable image has a testing id and bootloader if its not testing

I’m not familiar with the Bazzite Update Tool. I tried to find it on GitHub, but failed 😅. But, if I’d have to guess, it looks at the same wrong place that fastfetch does.

A couple of issue trackers I found that may (or may not be) related:

• https://github.com/ublue-os/bazzite/issues/5255
• https://github.com/ublue-os/bazzite-dx/issues/209
• https://github.com/ublue-os/bazzite-dx/issues/198

Question: Could you paste the output of rpm-ostree status?

Yo OP, in case you couldn’t get GPU passthrough to work; vm-curator makes that a piece of cake, somehow even with a single GPU.

Thanks! Much appreciated 🙂!

Can someone please provide a TL;DW? Much appreciated!

Beyond none of its branches actually satisfying my preferences, I feel like the way it handles major version upgrades is way too involved. I suppose it makes sense; it’s paying back the accumulated debt of a couple years worth of bliss…

Having said that, my experience on Fedora Atomic is (almost) equally blissful without requiring any of that whenever a major version update strikes.

Don’t get me wrong; I definitely do believe Debian has its uses on desktop Linux. But I can’t shake off the feeling that they’re definitely more niche compared to say Fedora.

You’re right on malware finding its way onto the Snap Store. I find it hilarious to see that the employed tactics are basically identical 😜.

However, FYI, the hate on Snaps is a lot more broad than that.

You can’t however make it use other init system or other DE/WM.

You’re AFAIK correct on the bold part. But definitely not on the strike-through part. You’re probably only limited by your creativity and the effort you’re willing to put into it:

• Bazzite, but with Hyprland
• Bazzite, but with niri
• Bazzite, but Windows-themed | It’s basically KDE Plasma, but you get the point.

I have snapper and pika backing up, so in a few minutes all is back to normal, so the main selling point of atomic/immutable distro is kind of irrelevant to me

FWIW, openSUSE literally pioneered the above workflow with Tumbleweed. But that didn’t prevent them from developing openSUSE MicroOS (and its desktop-adjacent siblings). So, unless openSUSE has absolutely no clue on what they’re doing, there is more to it than that. Even if ‘that something’ isn’t relevant for you (yet).

OP, got some specs? It will make it easier for us to give good suggestions. Thanks in advance!

It has been my pleasure 😊.

Aight. Understood. Thank you!

In your case, I’d propose something like NixOS then. As your full system configuration can be contained within a (set of) config file(s), the very same ones you use to install/config stuff, a reinstall just becomes very easy. Heck, if you’re willing to embrace the “Erase your darlings”-lifestyle, then I don’t even think you’d ever feel the need for a reinstall. Because, frankly, the clean slate is just a reboot away.

EDIT: Perhaps Guix System is also worth considering as an alternative to NixOS*.

EDIT2: If you still want to explore other distros, then it’s worth noting that nix, i.e. NixOS’ package manager, is available on most distros and offers a lot of the benefits already. Like, you could configure your system using it, and then use that config on another distro to get your config back. Good stuff.

I frequently reinstall Linux.

Like, how many times in a year? And secondly, for what reason?

Could you please explain a little more on what X11 and wayland are?

Not the one you asked*.

But, to put it simply, there’s a piece/suite of software that’s actually responsible for displaying stuff. Even your Desktop Environment is contingent upon it. X11 and Wayland are the two most popular ‘options’ for that and (to be frank) the ones that are ‘actually’ in use. The former is the OG and was for the longest time pretty much your only option. But the latter has come a long way and is a superior option for most.

In the context of Cinnamon, its Wayland implementation is still relatively immature. Heck, only with its next release will it become non-experimental. But, even then, it is possible that switching will make a difference here.

How can I find out the information you are looking for?

Invoke echo $XDG_SESSION_TYPE within a terminal. It will return whichever you’re on.

OP, FYI: GPU passthrough isn’t riskless (OpSec-wise), unfortunately. This Hacker News thread contains pointers if you’d wish to read up on that.

I’d argue they’d have to answer (or at least think about) what their goldilocks is in terms of the following axis:

• No defaults^[1] <–:–|–:–> Highly opinionated^[2]
• Convenience <–:–|–:–> Security
• Rolling release <–:–|–:–> Frozen packages/repository
• Means to an end^[3] <–:–|–:–> End in itself^[4]